From noreply@sourceforge.net Sun Jun 1 00:27:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 16:27:25 -0700 Subject: [Patches] [ python-Patches-746801 ] FreeBSD 4 port of python-2.2.3... Message-ID: Patches item #746801, was opened at 2003-05-31 23:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 Category: Tests Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Charles Swiger (cws3) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 4 port of python-2.2.3... Initial Comment: Add list of tests expected to be skipped for the 'freebsd4' platform. Diff applies okay to current CVS sources as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 From noreply@sourceforge.net Sun Jun 1 03:03:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 19:03:35 -0700 Subject: [Patches] [ python-Patches-746801 ] FreeBSD 4 port of python-2.2.3... Message-ID: Patches item #746801, was opened at 2003-05-31 23:27 Message generated for change (Comment added) made by cws3 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 Category: Tests Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Charles Swiger (cws3) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 4 port of python-2.2.3... Initial Comment: Add list of tests expected to be skipped for the 'freebsd4' platform. Diff applies okay to current CVS sources as well. ---------------------------------------------------------------------- >Comment By: Charles Swiger (cws3) Date: 2003-06-01 02:03 Message: Logged In: YES user_id=789947 Submitted port as http://www.freebsd.org/cgi/query-pr.cgi?pr=52830. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 From noreply@sourceforge.net Sun Jun 1 22:18:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 01 Jun 2003 14:18:41 -0700 Subject: [Patches] [ python-Patches-731701 ] SpawnedGenerator class for threading module Message-ID: Patches item #731701, was opened at 2003-05-02 19:38 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731701&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Mathieu Fenniak (laotzu0) Assigned to: Nobody/Anonymous (nobody) Summary: SpawnedGenerator class for threading module Initial Comment: The attached patch adds a new class, threading.SpawnedGenerator, written by Garth T Kidd in his weblog. (http:// www.deadlybloodyserious.com/Python/2003/04/22.html) The class wraps a given generator as a new generator that runs in a seperate thread by retrieving the generator values and storing them in a Queue object. It's a very nice high-level threading interface. A basic functionality test has also been added to test_threading.py. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-01 14:18 Message: Logged In: YES user_id=357491 Since Mathieu said he would open another patch if he got permission from Mr. Kidd I am going to close this patch as rejected. ---------------------------------------------------------------------- Comment By: Mathieu Fenniak (laotzu0) Date: 2003-05-08 20:43 Message: Logged In: YES user_id=442694 I neglected to think about the copyright issue. I've contacted Mr. Kidd and requested permission to distribute this. I hope to receive a response soon. Sorry for forgetting such an important thing. (if my head weren't securely fastened...) If permission is granted, I'll submit another patch with documentation and the other mentioned issues dealt with. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-08 20:04 Message: Logged In: YES user_id=31435 This desperately needs a doc patch too -- it's not at all obvious what this code does, how to use it, or why someone would want to. There's a more serious problem of a different kind: you didn't write the code, and apparently lifted it off a web page. There's a clear copyright notice on that page, and no license in sight there. So, apologies in advance, but unless you have permission from Mr. Kidd to distribute his work, we have to delete this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 16:56 Message: Logged In: YES user_id=357491 First off, I think if this patch belongs anywhere it is in itertools and definitely not in 'threading'. Raymond? Second, I don't like overriding __call__ to return the generator. It would be better to just put the body of __call__ into __iter__; the idiom of making __iter__ a generator is great by preventing someone from having to specify a separate 'next' method and by making __iter__ create a *new* iterator with fresh values without having to do some fancy class stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731701&group_id=5470 From noreply@sourceforge.net Sun Jun 1 22:21:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 01 Jun 2003 14:21:12 -0700 Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor Message-ID: Patches item #608182, was opened at 2002-09-11 20:45 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Taral (taral) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced file constructor Initial Comment: This patch allows the file constructor to take a file descriptor, allowing for much easier extension of its functionality. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-01 14:21 Message: Logged In: YES user_id=357491 Has a discussion comp.lang.python occured to judge the demand for this feature? ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2003-05-09 09:37 Message: Logged In: YES user_id=25129 Okay, you have a good point. I could convert it to this format: file(filename[, mode[, buffering[, fd]]]) or file(filename[,mode[, buffering]][, fd=fd]) That should satisfy the type requirement. I kind of prefer the keyword version, but that's just me. I know about the containment solution, but I can't pass containers to functions that expect isinstance(arg, file). (As for os.popen, that's happens to be why I made this patch in the first case. I needed to extend popen functionality, and this was the minimum way to do it without violating the above isinstance requirement.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-08 20:53 Message: Logged In: YES user_id=31435 You do need to convince people it's a good idea. I cringe for two reasons: it mixes up a higher-level facility with a lower-level one; and, in a language with dynamic typing, it's *helpful* that file(xyz, 'w') raises TypeError today when the runtime type of xyz is an integer. This catches a serious error before it can harm files. I'd dislike losing that error detection more than I'd like the new facility this offers. Perhaps I'm in a small minority, though, in which case a discussion on comp.lang.python could reveal that. Someone there will point out that while you can't get what you want directly via subclassing file today, you can get the effect via containment and a __getattr__ hook (to delegate the file methods you don't want to intercept to the contained file object). That covers cases this patch doesn't, too, such as file objects returned by os.popen() (i.e., even with this patch, there are still "file objects that CANNOT be subclassed"). ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2003-05-08 19:32 Message: Logged In: YES user_id=25129 I have a very good reason! Without it, there are file objects that CANNOT be subclassed, specifically those created via os.fdopen. Yes, I am _still_ waiting for this to go in. Do I need to do something else on some mailing list to get people to notice it? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 18:09 Message: Logged In: YES user_id=357491 This functionality has still not made it into 2.3b1 . If no one speaks up and comes up with a good argument to apply this by May 15 I am going to reject this patch. ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2003-01-31 12:12 Message: Logged In: YES user_id=25129 Didn't make it into 2.3alpha? ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-12 11:39 Message: Logged In: YES user_id=25129 class some_class(file): def __init__(self, arg): fd = do_some_os_stuff_with_forks_and_pipes_or_sockets return file.__init__(self, fd, 'r') def close(self): do_some_cleanup_stuff return file.close(self) and so on. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 23:59 Message: Logged In: YES user_id=21627 What's wrong with os.fdopen? Why is f = file(10, "r") much easier than f = os.fdopen(10, "r") ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-11 22:31 Message: Logged In: YES user_id=25129 Okay, fixed it all. Passes 'make test' on linux/x86 with default configure (does not test dbm/gdbm/mpz/bsddb). (btw, old versions can be deleted) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-11 21:10 Message: Logged In: YES user_id=33168 fp's and fd's are not interchangable. The variable should be called fd, since it's an int. fill_file_fields() 2nd arg is a FILE*, not an int. So you would need to do file = fdopen(fd, mode), then pass file as the 2nd arg. In order for this patch to be accepted, a test would also need to be added (see Lib/test/test_file.py) and doc should be updated (see Doc/lib/libfuncs.tex). ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-11 20:47 Message: Logged In: YES user_id=25129 Bah, forgot the variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 From noreply@sourceforge.net Mon Jun 2 08:40:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 02 Jun 2003 00:40:48 -0700 Subject: [Patches] [ python-Patches-747364 ] BaseHTTPServer doesn't need StringIO intermediary Message-ID: Patches item #747364, was opened at 2003-06-02 01:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: BaseHTTPServer doesn't need StringIO intermediary Initial Comment: This is Python2.3b1, from CVS I looked at the implementation of the BaseHTTPServer.py code where it does the actual parsing. I see that it has # Deal with pipelining bytes = "" while 1: line = self.rfile.readline() bytes = bytes + line if line == '\r\n' or line == '\n' or line == '': break # Examine the headers and look for a Connection directive hfile = cStringIO.StringIO(bytes) self.headers = self.MessageClass(hfile) The MessageClass is mimetools.Message, which uses rfc822.Message to parse the headers. The Message reads the input stream up to and including the end-of-header blank line, but no further, using while 1: ... line = self.fp.readline() ... elif self.islast(line): # Note! No pushback here! The delimiter line gets eaten break def islast(self, line): """Determine whether a line is a legal end of RFC 2822 headers. and checks for '\r\n' or '\n' so it seems the temporary copy into a StringIO isn't needed since the Message can deal with it correctly. Plus, Message takes a 'seekable' parameter which can turn off seeking on the input stream, and has for a long time (since well before Martin's "Deal with pipelining code"). The proof, as they say, is in the pudding. Thought I don't know why. Anyway, I replaced the "bytes ... " code and used self.rfile rather than the temporary StringIO hfile, as in self.headers = self.MessageClass(self.rfile) print "Does it work?", repr(self.rfile.readline()) (I added the print to make sure the data wasn't eaten) I tested it with the module's mainline self-test, and it seems to work just fine. Attached patch does the same, only without the debugging print statement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 From noreply@sourceforge.net Mon Jun 2 13:32:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 02 Jun 2003 05:32:14 -0700 Subject: [Patches] [ python-Patches-719359 ] fix test_long failure on OSF/1 Message-ID: Patches item #719359, was opened at 2003-04-11 01:15 Message generated for change (Comment added) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=719359&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: fix test_long failure on OSF/1 Initial Comment: When using cc on OSF/1 V5.1, test_long fails because PyFloat_FromString() returns a ValueError instead of an OverflowError when the string is too long. The library appears to work a bit different. This patch fixes the problem. test test_long crashed -- exceptions.ValueError: invalid literal for float(): 12345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345 ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-02 14:32 Message: Logged In: YES user_id=696559 OK, I managed to download cvs module named python: ./configure --prefix=/software/@sys/usr [...] checking whether pthreads are available without options... no checking whether cc accepts -Kpthread... no checking whether cc accepts -Kthread... no checking whether cc accepts -pthread... yes [...] checking for --with-libs... no checking for --with-signal-module... yes checking for --with-dec-threads... no checking for --with-threads... yes checking if PTHREAD_SCOPE_SYSTEM is supported... yes checking for pthread_sigmask... yes checking if --enable-ipv6 is specified... yes configure:3774: checking whether pthreads are available without options configure:3800: cc -o conftest -O2 -arch ev56 -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include conftest.c -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib >&5 cc: Error: /usr/include/pthread.h, line 312: #error "Please compile the module including pthread.h with -pthread" (errormessage) # error "Please compile the module including pthread.h with -pthread" ---^ configure:3803: $? = 1 configure: program exited with status 1 configure: failed program was: #line 3782 "configure" #include "confdefs.h" #include void* routine(void* p){return NULL;} int main(){ pthread_t p; if(pthread_create(&p,NULL,routine,NULL)!=0) return 1; (void)pthread_detach(p); return 0; } configure:3823: result: no configure:3836: checking whether cc accepts -Kpthread configure:3864: cc -Kpthread -o conftest -O2 -arch ev56 -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include conftest.c -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib >&5 cc: Error: /usr/include/pthread.h, line 312: #error "Please compile the module including pthread.h with -pthread" (errormessage) # error "Please compile the module including pthread.h with -pthread" ---^ configure:3867: $? = 1 configure: program exited with status 1 configure: failed program was: #line 3846 "configure" #include "confdefs.h" #include void* routine(void* p){return NULL;} int main(){ pthread_t p; if(pthread_create(&p,NULL,routine,NULL)!=0) return 1; (void)pthread_detach(p); return 0; } configure:3887: result: no configure:3898: checking whether cc accepts -Kthread configure:3926: cc -Kthread -o conftest -O2 -arch ev56 -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include c onftest.c -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib >&5 cc: Error: /usr/include/pthread.h, line 312: #error "Please compile the module including pthread.h with -pthread" (errormessage) # error "Please compile the module including pthread.h with -pthread" ---^ configure:3929: $? = 1 configure: program exited with status 1 configure: failed program was: #line 3908 "configure" #include "confdefs.h" #include void* routine(void* p){return NULL;} int main(){ pthread_t p; if(pthread_create(&p,NULL,routine,NULL)!=0) return 1; (void)pthread_detach(p); return 0; } configure:3949: result: no configure:3960: checking whether cc accepts -pthread configure:3988: cc -pthread -o conftest -O2 -arch ev56 -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include c onftest.c -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib >&5 configure:3991: $? = 0 configure:3993: ./conftest configure:3996: $? = 0 configure:4011: result: yes configure:4214: checking pthread.h usability configure:4223: cc -c -O2 -arch ev56 -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include conftest.c >&5 cc: Error: /usr/include/pthread.h, line 312: #error "Please compile the module including pthread.h with -pthread" (errormessage) # error "Please compile the module including pthread.h with -pthread" ---^ configure:4226: $? = 1 [...] configure:4241: result: no configure:4245: checking pthread.h presence configure:4252: cc -E -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include conftest.c cc: Error: /usr/include/pthread.h, line 312: #error "Please compile the module including pthread.h with -pthread" (errormessage) # error "Please compile the module including pthread.h with -pthread" ---^ configure:4258: $? = 1 configure: failed program was: #line 4247 "configure" #include "confdefs.h" #include configure:4276: result: no configure:4294: checking for pthread.h configure:4301: result: no So, I have set -pthread manully: CC="cc -pthread -g2" CXX="cxx -pthread -g2" ./configure --prefix=/software/@sys/usr during make I see: building 'readline' extension cc -pthread -g2 -DNDEBUG -O -ieee -std -Olimit 1500 -I. -I/mnt/python/dist/src/./Include -I/software/@sys/usr/include -I/usr/local/include -I/mnt/python/dist/src/Include -I/mnt/python/dist/src -c /mnt/python/dist/src/Modules/readline.c -o build/temp.osf1-V5.1-alpha-2.3/readline.o cc: Info: File not optimized; use -g3 if both optimization and debug wanted. (suppressoptlvl) cc: Warning: /mnt/python/dist/src/Modules/readline.c, line 100: In this declaration, "history_length" is declared with both internal and external linkage. The previous declaration is at line number 224 in file /software/@sys/usr/include/readline/history.h. (mixlinkage) static int history_length = -1; /* do not truncate history by default */ -----------^ [...] building 'bsddb185' extension cc -pthread -g2 -DNDEBUG -O -ieee -std -Olimit 1500 -I. -I/mnt/python/dist/src/./Include -I/software/@sys/usr/include -I/usr/local/include -I/mnt/python/dist/src/Include -I/mnt/python/dist/src -c /mnt/python/dist/src/Modules/bsddbmodule.c -o build/temp.osf1-V5.1-alpha-2.3/bsddbmodule.o cc: Info: File not optimized; use -g3 if both optimization and debug wanted. (suppressoptlvl) cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 58: In this declaration, "HASHINFO" must specify a type. (badparsedecl) HASHINFO info; --------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 106: In this declaration, "BTREEINFO" must specify a type. (badparsedecl) BTREEINFO info; --------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 156: In this declaration, "RECNOINFO" must specify a type. (badparsedecl) RECNOINFO info; --------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 276: In this declaration, "recno_t" must specify a type. (badparsedecl) recno_t recno; --------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 327: In this declaration, "recno_t" must specify a type. (badparsedecl) recno_t recno; --------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 470: In this declaration, "recno_t" must specify a type. (badparsedecl) recno_t recno; --------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 509: In this declaration, "recno_t" must specify a type. (badparsedecl) recno_t recno; --------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 63: In this statement, "info" is not declared. (undeclared) info.bsize = bsize; --------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 111: In this statement, "info" is not declared. (undeclared) info.flags = btflags; --------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 162: In this statement, "info" is not declared. (undeclared) info.flags = rnflags; --------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 223: In this statement, "(dp->di_bsddb->close)" expects 2 arguments, but 1 are supplied. (toofewargs) status = (dp->di_bsddb->close)(dp->di_bsddb); -------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 252: In this statement, "seq" is not a member of "dp->di_bsddb". (needmember) for (status = (dp->di_bsddb->seq)(dp->di_bsddb, -------------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 255: In this statement, "seq" is not a member of "dp->di_bsddb". (needmember) status = (dp->di_bsddb->seq)(dp->di_bsddb, -------------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 279: In this statement, "recno" is not declared. (undeclared) if (!PyArg_Parse(key, "i", &recno)) { --------------------------------------------^ cc: Warning: /mnt/python/dist/src/Modules/bsddbmodule.c, line 299: In this statement, the referenced type of the pointer value "&krec" is "struct __db_dbt", which is not compatible with "struct __db_txn". (ptrmismatch) status = (dp->di_bsddb->get)(dp->di_bsddb, &krec, &drec, 0); ---------------------------------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 299: In this statement, "(dp->di_bsddb->get)" expects 5 arguments, but 4 are supplied. (toofewargs) status = (dp->di_bsddb->get)(dp->di_bsddb, &krec, &drec, 0); -----------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 330: In this statement, "recno" is not declared. (undeclared) if (!PyArg_Parse(key, "i", &recno)) { --------------------------------------------^ cc: Warning: /mnt/python/dist/src/Modules/bsddbmodule.c, line 351: In this statement, the referenced type of the pointer value "&krec" is "struct __db_dbt", which is not compatible with "struct __db_txn". (ptrmismatch) status = (dp->di_bsddb->del)(dp->di_bsddb, &krec, 0); -----------------------------------------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 351: In this statement, "(dp->di_bsddb->del)" expects 4 arguments, but 3 are supplied. (toofewargs) status = (dp->di_bsddb->del)(dp->di_bsddb, &krec, 0); -------------------------^ cc: Warning: /mnt/python/dist/src/Modules/bsddbmodule.c, line 363: In this statement, the referenced type of the pointer value "&krec" is "struct __db_dbt", which is not compatible with "struct __db_txn". (ptrmismatch) status = (dp->di_bsddb->put)(dp->di_bsddb, &krec, &drec, 0); -----------------------------------------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 363: In this statement, "(dp->di_bsddb->put)" expects 5 arguments, but 4 are supplied. (toofewargs) status = (dp->di_bsddb->put)(dp->di_bsddb, &krec, &drec, 0); -------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 388: In this statement, "(dp->di_bsddb->close)" expects 2 arguments, but 1 are supplied. (toofewargs) status = (dp->di_bsddb->close)(dp->di_bsddb); -------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 415: In this statement, "seq" is not a member of "dp->di_bsddb". (needmember) status = (dp->di_bsddb->seq)(dp->di_bsddb, &krec, &drec, R_FIRST); ------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 441: In this statement, "seq" is not a member of "dp->di_bsddb". (needmember) status = (dp->di_bsddb->seq) --------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 474: In this statement, "recno" is not declared. (undeclared) &recno)) { ---------------------------------------^ cc: Warning: /mnt/python/dist/src/Modules/bsddbmodule.c, line 491: In this statement, the referenced type of the pointer value "&krec" is "struct __db_dbt", which is not compatible with "struct __db_txn". (ptrmismatch) status = (dp->di_bsddb->get)(dp->di_bsddb, &krec, &drec, 0); ---------------------------------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 491: In this statement, "(dp->di_bsddb->get)" expects 5 arguments, but 4 are supplied. (toofewargs) status = (dp->di_bsddb->get)(dp->di_bsddb, &krec, &drec, 0); -----------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 513: In this statement, "recno" is not declared. (undeclared) &recno)) { ---------------------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 530: In this statement, "seq" is not a member of "dp->di_bsddb". (needmember) status = (dp->di_bsddb->seq)(dp->di_bsddb, &krec, &drec, R_CURSOR); ------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 570: In this statement, "seq" is not a member of "dp->di_bsddb". (needmember) status = (dp->di_bsddb->seq)(dp->di_bsddb, &krec, ------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 608: In this statement, "R_NEXT" is not declared. (undeclared) return bsddb_seq(dp, R_NEXT); -----------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 613: In this statement, "R_PREV" is not declared. (undeclared) return bsddb_seq(dp, R_PREV); -----------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 618: In this statement, "R_FIRST" is not declared. (undeclared) return bsddb_seq(dp, R_FIRST); -----------------------------^ cc: Error: /mnt/python/dist/src/Modules/bsddbmodule.c, line 623: In this statement, "R_LAST" is not declared. (undeclared) return bsddb_seq(dp, R_LAST); -----------------------------^ building 'dbm' extension [...] ld -shared -expect_unresolved * build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o -L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o build/lib.osf1-V5.1-alpha-2.3/_curses.so *** WARNING: renaming "_curses" since importing it failed: dlopen: build/lib.osf1-V5.1-alpha-2.3/_curses.so: symbol "_acs_map" unresolved building '_curses_panel' extension cc -pthread -g2 -DNDEBUG -O -ieee -std -Olimit 1500 -I. -I/mnt/python/dist/src/./Include -I/software/@sys/usr/include -I/usr/local/include -I/mnt/python/dist/src/Include -I/mnt/python/dist/src -c /mnt/python/dist/src/Modules/_curses_panel.c -o build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o cc: Info: File not optimized; use -g3 if both optimization and debug wanted. (suppressoptlvl) cc: Severe: /mnt/python/dist/src/Modules/_curses_panel.c, line 17: Cannot find file specified in #include directive. (noinclfilef) #include -^ building 'zlib' extension [...] It seems the test_long bug is fixed already in cvs: $ ./python -E -tt ./Lib/test/test_long.py long / * % divmod Karatsuba long bit-operation identities long str/hex/oct/atol long miscellaneous operations auto-convert int->long on overflow long->float overflow log and log10 $ ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 16:12 Message: Logged In: YES user_id=33168 Checked in as: * configure 1.402 * configure.in 1.413 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-26 07:40 Message: Logged In: YES user_id=21627 I see. The patch is fine, please apply it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 01:49 Message: Logged In: YES user_id=33168 It shouldn't break gcc support. There is an outer case $GCC, the case which OSF* is in only is tested when $GCC != yes. It appears there are more issues associated with -pthread, I think that should be dropped from this patch. So the line would be: BASECFLAGS="$BASECFLAGS -ieee -std" I'd also like to see if this fixes the other people's problem. I don't get a SIGFPE, but the test_long problem is fixed with this patch (specifically -ieee). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-25 22:40 Message: Logged In: YES user_id=21627 I'm pretty sure that this will break gcc support on that system. You could add a if not-gcc test; see other systems for examples. As for -pthread, please see 742741. I think configure should detect presence of -pthread, and stop checking for libraries to link. I assume that with -pthread, no additional -D/-l flags need to be passed for threads? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 18:40 Message: Logged In: YES user_id=33168 You're right. I've attached a patch which fixes the compiler options. No code changes were necessary. This new patch seems to fix a number of problems. It adds 3 options to pass to cc: -ieee to fix test_long and SIGFPEs, -std to get a reasonable assert on some versions of Tru64/OSF, -pthread to support threads. The options are only added for cc. I do not have access to gcc. Hopefully others can test that everything works with gcc (it's unchanged in this patch). Martin, could you please review this. I will try to get all the original bug submitters to test this patch. Related issues: * http://python.org/sf/693094 * http://python.org/sf/738066 * http://python.org/sf/741307 * http://python.org/sf/741806 * http://python.org/sf/719359 (this patch) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 17:19 Message: Logged In: YES user_id=31435 Sorry, this isn't the right fix. There is no case before this patch in which PyFloat_FromString() can raise OverflowError. As the comments say, /* We don't care about overflow or underflow. If the platform supports * them, infinities and signed zeroes (on underflow) are fine. If this platform is returning DBL_MAX, no problem, lots of platforms do. I don't know why this platform goes on to raise ValueError, but the intent is that it return DBL_MAX and not raise any exception. Assuming that the test failing is float(shuge) == int(shuge) we don't expect the float(shuge) part to raise anything, we expect the int(shuge) part to raise OverflowError. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 16:33 Message: Logged In: YES user_id=33168 Tim, could you take a quick look at this patch (or unassign)? It's pretty simple and we could close a bug and a patch. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=719359&group_id=5470 From noreply@sourceforge.net Mon Jun 2 20:33:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 02 Jun 2003 12:33:04 -0700 Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor Message-ID: Patches item #608182, was opened at 2002-09-11 22:45 Message generated for change (Comment added) made by taral You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Taral (taral) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced file constructor Initial Comment: This patch allows the file constructor to take a file descriptor, allowing for much easier extension of its functionality. ---------------------------------------------------------------------- >Comment By: Taral (taral) Date: 2003-06-02 14:33 Message: Logged In: YES user_id=25129 No, I don't have usenet access. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-01 16:21 Message: Logged In: YES user_id=357491 Has a discussion comp.lang.python occured to judge the demand for this feature? ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2003-05-09 11:37 Message: Logged In: YES user_id=25129 Okay, you have a good point. I could convert it to this format: file(filename[, mode[, buffering[, fd]]]) or file(filename[,mode[, buffering]][, fd=fd]) That should satisfy the type requirement. I kind of prefer the keyword version, but that's just me. I know about the containment solution, but I can't pass containers to functions that expect isinstance(arg, file). (As for os.popen, that's happens to be why I made this patch in the first case. I needed to extend popen functionality, and this was the minimum way to do it without violating the above isinstance requirement.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-08 22:53 Message: Logged In: YES user_id=31435 You do need to convince people it's a good idea. I cringe for two reasons: it mixes up a higher-level facility with a lower-level one; and, in a language with dynamic typing, it's *helpful* that file(xyz, 'w') raises TypeError today when the runtime type of xyz is an integer. This catches a serious error before it can harm files. I'd dislike losing that error detection more than I'd like the new facility this offers. Perhaps I'm in a small minority, though, in which case a discussion on comp.lang.python could reveal that. Someone there will point out that while you can't get what you want directly via subclassing file today, you can get the effect via containment and a __getattr__ hook (to delegate the file methods you don't want to intercept to the contained file object). That covers cases this patch doesn't, too, such as file objects returned by os.popen() (i.e., even with this patch, there are still "file objects that CANNOT be subclassed"). ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2003-05-08 21:32 Message: Logged In: YES user_id=25129 I have a very good reason! Without it, there are file objects that CANNOT be subclassed, specifically those created via os.fdopen. Yes, I am _still_ waiting for this to go in. Do I need to do something else on some mailing list to get people to notice it? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 20:09 Message: Logged In: YES user_id=357491 This functionality has still not made it into 2.3b1 . If no one speaks up and comes up with a good argument to apply this by May 15 I am going to reject this patch. ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2003-01-31 14:12 Message: Logged In: YES user_id=25129 Didn't make it into 2.3alpha? ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-12 13:39 Message: Logged In: YES user_id=25129 class some_class(file): def __init__(self, arg): fd = do_some_os_stuff_with_forks_and_pipes_or_sockets return file.__init__(self, fd, 'r') def close(self): do_some_cleanup_stuff return file.close(self) and so on. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-12 01:59 Message: Logged In: YES user_id=21627 What's wrong with os.fdopen? Why is f = file(10, "r") much easier than f = os.fdopen(10, "r") ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-12 00:31 Message: Logged In: YES user_id=25129 Okay, fixed it all. Passes 'make test' on linux/x86 with default configure (does not test dbm/gdbm/mpz/bsddb). (btw, old versions can be deleted) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-11 23:10 Message: Logged In: YES user_id=33168 fp's and fd's are not interchangable. The variable should be called fd, since it's an int. fill_file_fields() 2nd arg is a FILE*, not an int. So you would need to do file = fdopen(fd, mode), then pass file as the 2nd arg. In order for this patch to be accepted, a test would also need to be added (see Lib/test/test_file.py) and doc should be updated (see Doc/lib/libfuncs.tex). ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-11 22:47 Message: Logged In: YES user_id=25129 Bah, forgot the variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 From noreply@sourceforge.net Tue Jun 3 05:47:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 02 Jun 2003 21:47:22 -0700 Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor Message-ID: Patches item #608182, was opened at 2002-09-11 20:45 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Taral (taral) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced file constructor Initial Comment: This patch allows the file constructor to take a file descriptor, allowing for much easier extension of its functionality. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-02 21:47 Message: Logged In: YES user_id=357491 You can use groups.google.com or python-list@python.org. ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2003-06-02 12:33 Message: Logged In: YES user_id=25129 No, I don't have usenet access. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-01 14:21 Message: Logged In: YES user_id=357491 Has a discussion comp.lang.python occured to judge the demand for this feature? ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2003-05-09 09:37 Message: Logged In: YES user_id=25129 Okay, you have a good point. I could convert it to this format: file(filename[, mode[, buffering[, fd]]]) or file(filename[,mode[, buffering]][, fd=fd]) That should satisfy the type requirement. I kind of prefer the keyword version, but that's just me. I know about the containment solution, but I can't pass containers to functions that expect isinstance(arg, file). (As for os.popen, that's happens to be why I made this patch in the first case. I needed to extend popen functionality, and this was the minimum way to do it without violating the above isinstance requirement.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-08 20:53 Message: Logged In: YES user_id=31435 You do need to convince people it's a good idea. I cringe for two reasons: it mixes up a higher-level facility with a lower-level one; and, in a language with dynamic typing, it's *helpful* that file(xyz, 'w') raises TypeError today when the runtime type of xyz is an integer. This catches a serious error before it can harm files. I'd dislike losing that error detection more than I'd like the new facility this offers. Perhaps I'm in a small minority, though, in which case a discussion on comp.lang.python could reveal that. Someone there will point out that while you can't get what you want directly via subclassing file today, you can get the effect via containment and a __getattr__ hook (to delegate the file methods you don't want to intercept to the contained file object). That covers cases this patch doesn't, too, such as file objects returned by os.popen() (i.e., even with this patch, there are still "file objects that CANNOT be subclassed"). ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2003-05-08 19:32 Message: Logged In: YES user_id=25129 I have a very good reason! Without it, there are file objects that CANNOT be subclassed, specifically those created via os.fdopen. Yes, I am _still_ waiting for this to go in. Do I need to do something else on some mailing list to get people to notice it? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 18:09 Message: Logged In: YES user_id=357491 This functionality has still not made it into 2.3b1 . If no one speaks up and comes up with a good argument to apply this by May 15 I am going to reject this patch. ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2003-01-31 12:12 Message: Logged In: YES user_id=25129 Didn't make it into 2.3alpha? ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-12 11:39 Message: Logged In: YES user_id=25129 class some_class(file): def __init__(self, arg): fd = do_some_os_stuff_with_forks_and_pipes_or_sockets return file.__init__(self, fd, 'r') def close(self): do_some_cleanup_stuff return file.close(self) and so on. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 23:59 Message: Logged In: YES user_id=21627 What's wrong with os.fdopen? Why is f = file(10, "r") much easier than f = os.fdopen(10, "r") ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-11 22:31 Message: Logged In: YES user_id=25129 Okay, fixed it all. Passes 'make test' on linux/x86 with default configure (does not test dbm/gdbm/mpz/bsddb). (btw, old versions can be deleted) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-11 21:10 Message: Logged In: YES user_id=33168 fp's and fd's are not interchangable. The variable should be called fd, since it's an int. fill_file_fields() 2nd arg is a FILE*, not an int. So you would need to do file = fdopen(fd, mode), then pass file as the 2nd arg. In order for this patch to be accepted, a test would also need to be added (see Lib/test/test_file.py) and doc should be updated (see Doc/lib/libfuncs.tex). ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-11 20:47 Message: Logged In: YES user_id=25129 Bah, forgot the variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 From noreply@sourceforge.net Tue Jun 3 12:58:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 03 Jun 2003 04:58:22 -0700 Subject: [Patches] [ python-Patches-748126 ] Nails down the semantics of dict setitem Message-ID: Patches item #748126, was opened at 2003-06-03 06:57 Message generated for change (Settings changed) made by david_abrahams You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Nails down the semantics of dict setitem Initial Comment: You could consider accomplishing the same thing in the footnotes area, but I didn't see any reason to make the reader jump around for this info. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470 From noreply@sourceforge.net Tue Jun 3 12:57:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 03 Jun 2003 04:57:24 -0700 Subject: [Patches] [ python-Patches-748126 ] Nails down the semantics of dict setitem Message-ID: Patches item #748126, was opened at 2003-06-03 06:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&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: Nails down the semantics of dict setitem Initial Comment: You could consider accomplishing the same thing in the footnotes area, but I didn't see any reason to make the reader jump around for this info. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470 From gerrit@nl.linux.org Wed Jun 4 12:45:33 2003 From: gerrit@nl.linux.org (Gerrit Holl) Date: Wed, 4 Jun 2003 13:45:33 +0200 Subject: [Patches] SF down for maintenance: here 3 patches Message-ID: <20030604114533.GA12014@nl.linux.org> --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, since SF is down for maintanaince, and I don't know for how long, I'm putting my patches here: parsedate.diff parsedate correctly uses last 3 items of tuple demo_dates.diff Demo/classes/Dates.py tells about DateTime tools_README.diff Updates {Demo,Tools}/scripts/README yours, Gerrit. -- 14. If any one steal the minor son of another, he shall be put to death. -- 1780 BC, Hammurabi, Code of Law -- Asperger Syndroom - een persoonlijke benadering: http://people.nl.linux.org/~gerrit/ Het zijn tijden om je zelf met politiek te bemoeien: http://www.sp.nl/ --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tools_README.diff" Index: Demo/scripts/README =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/scripts/README,v retrieving revision 1.19 diff -u -r1.19 README --- Demo/scripts/README 1 Jan 2003 20:27:13 -0000 1.19 +++ Demo/scripts/README 4 Jun 2003 11:38:45 -0000 @@ -2,18 +2,23 @@ See also the Tools/scripts directory! +beer.py Print the classic 'bottles of beer' list. +eqfix.py Fix .py files to use the correct equality test operator fact.py Factorize numbers find-uname.py Search for Unicode characters using regexps. from.py Summarize mailbox ftpstats.py Summarize ftp daemon log file lpwatch.py Watch BSD line printer queues +makedir.py Like mkdir -p markov.py Markov chain simulation of words or characters mboxconvvert.py Convert MH or MMDF mailboxes to unix mailbox format +mkrcs.py Fix symlinks named RCS into parallel tree morse.py Produce morse code (audible or on AIFF file) mpzpi.py test mpz -- print digits of pi (compare pi.py) pi.py Print all digits of pi -- given enough time and memory pp.py Emulate some Perl command line options primes.py Print prime numbers +queens.py Dijkstra's solution to Wirth's "N Queens problem" script.py Equivalent to BSD script(1) -- by Steen Lumholt unbirthday.py Print unbirthday count update.py Update a bunch of files according to a script. Index: Tools/scripts/README =================================================================== RCS file: /cvsroot/python/python/dist/src/Tools/scripts/README,v retrieving revision 1.11 diff -u -r1.11 README --- Tools/scripts/README 10 May 2003 03:30:13 -0000 1.11 +++ Tools/scripts/README 4 Jun 2003 11:38:45 -0000 @@ -6,21 +6,28 @@ byext.py Print lines/words/chars stats of files by extension byteyears.py Print product of a file's size and age +checkappend.py Search for multi-argument .append() calls checkpyc.py Check presence and validity of ".pyc" files classfix.py Convert old class syntax to new +cleanfuture.py Fix reduntant Python __future__ statements +combinerefs.py A helper for analyzing PYTHONDUMPREFS output. copytime.py Copy one file's atime and mtime to another crlf.py Change CRLF line endings to LF (Windows to Unix) cvsfiles.py Print a list of files that are under CVS db2pickle.py Dump a database file to a pickle dutree.py Format du(1) output as a tree sorted by size eptags.py Create Emacs TAGS file for Python modules +finddiv.py A grep-like tool that looks for division operators. findlinksto.py Recursively find symbolic links to a given path prefix fixcid.py Massive identifier substitution on C source files +fixdiv.py Tool to fix division operators. fixheader.py Add some cpp magic to a C include file fixnotice.py Fix the copyright notice in source files fixps.py Fix Python scripts' first line (if #!) ftpmirror.py FTP mirror script gencodec.py Create Python codecs from Unicode mapping files +google.py Open a webbrowser with Google. +gprof2html.py Transform gprof(1) output into useful HTML. h2py.py Translate #define's into Python assignments ifdef.py Remove #if(n)def groups from C sources lfcr.py Change LF line endings to CRLF (Unix to Windows) @@ -28,23 +35,27 @@ lll.py Find and list symbolic links in current directory logmerge.py Consolidate CVS/RCS logs read from stdin mailerdaemon.py parse error messages from mailer daemons (Sjoerd&Jack) +md5sum.py Python utility to print MD5 checksums of argument files. methfix.py Fix old method syntax def f(self, (a1, ..., aN)): mkreal.py Turn a symbolic link into a real file or directory ndiff.py Intelligent diff between text files (Tim Peters) nm2def.py Create a template for PC/python_nt.def (Marc Lemburg) objgraph.py Print object graph from nm output on a library +parseentities.py Utility for parsing HTML entity definitions pathfix.py Change #!/usr/local/bin/python into something else pdeps.py Print dependencies between Python modules pickle2db.py Load a pickle generated by db2pickle.py to a database pindent.py Indent Python code, giving block-closing comments ptags.py Create vi tags file for Python modules +pydoc Python documentation browser. +redemo.py Basic regular expression demostration facility +reindent.py Change .py files to use 4-space indents. rgrep.py Reverse grep through a file (useful for big logfiles) +setup.py Install all scripts listed here. suff.py Sort a list of files by suffix -sum5.py Print md5 checksums of files -tabnanny.py Check for ambiguous indentation (Tim Peters) -tabpolice.py Check for ambiguous indentation (GvR) texcheck.py Validate Python LaTeX formatting (Raymond Hettinger) texi2html.py Convert GNU texinfo files into HTML +trace.py Trace Python program or function execution treesync.py Synchronize source trees (very ideosyncratic) untabify.py Replace tabs with spaces in argument files which.py Find a program in $PATH --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="demo_dates.diff" Index: Dates.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/classes/Dates.py,v retrieving revision 1.3 diff -u -r1.3 Dates.py --- Dates.py 14 Sep 1998 15:34:45 -0000 1.3 +++ Dates.py 4 Jun 2003 09:48:31 -0000 @@ -8,7 +8,7 @@ # the date `int' days from `date'; date+date raises an exception; # date-int returns the date `int' days before `date'; date2-date1 returns # an integer, the number of days from date1 to date2; int-date raises an -# exception; date1 < date2 is true iff date1 occurs before date2 (& +# exception; date1 < date2 is true if date1 occurs before date2 (& # similarly for other comparisons); min(date1,date2) is the earlier of # the two dates and max(date1,date2) the later; and date objects can be # used as dictionary keys. @@ -35,6 +35,9 @@ # Adapted to Python 1.1 (where some hacks to overcome coercion are unnecessary) # by Guido van Rossum + +# Note that as of Python 2.3, a datetime module is included in the stardard +# library. # vi:set tabsize=8: --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="parsedate.diff" Index: dist/src/Doc/lib/emailutil.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/emailutil.tex,v retrieving revision 1.8 diff -u -r1.8 emailutil.tex --- dist/src/Doc/lib/emailutil.tex 1 Oct 2002 04:33:16 -0000 1.8 +++ dist/src/Doc/lib/emailutil.tex 3 Jun 2003 18:48:16 -0000 @@ -56,8 +56,7 @@ \code{"Mon, 20 Nov 1995 19:12:08 -0500"}. If it succeeds in parsing the date, \function{parsedate()} returns a 9-tuple that can be passed directly to \function{time.mktime()}; otherwise \code{None} will be -returned. Note that fields 6, 7, and 8 of the result tuple are not -usable. +returned. \end{funcdesc} \begin{funcdesc}{parsedate_tz}{date} Index: dist/src/Lib/email/_parseaddr.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/email/_parseaddr.py,v retrieving revision 1.6 diff -u -r1.6 _parseaddr.py --- dist/src/Lib/email/_parseaddr.py 8 May 2003 03:33:15 -0000 1.6 +++ dist/src/Lib/email/_parseaddr.py 3 Jun 2003 18:48:20 -0000 @@ -131,7 +131,7 @@ """Convert a time string to a time tuple.""" t = parsedate_tz(data) if isinstance(t, TupleType): - return t[:9] + return time.localtime(time.mktime(t[:9])) else: return t --jRHKVT23PllUwdXP-- From noreply@sourceforge.net Wed Jun 4 14:24:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2003 06:24:30 -0700 Subject: [Patches] [ python-Patches-748846 ] Let Demo/classes/Date.py mention DateTime module Message-ID: Patches item #748846, was opened at 2003-06-04 13:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748846&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let Demo/classes/Date.py mention DateTime module Initial Comment: Hi, this patch changes the comments in Demo/classes/Date.py. It fixes a typo and explains that the DateTime module, introduced in Python 2.3, is included in the standard library. I also sent this patch to patches@python.org when SF was down. Gerrit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748846&group_id=5470 From noreply@sourceforge.net Wed Jun 4 14:25:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2003 06:25:08 -0700 Subject: [Patches] [ python-Patches-748843 ] Let Email.Utils.parsedate use last 3 timetuple items Message-ID: Patches item #748843, was opened at 2003-06-04 13:22 Message generated for change (Settings changed) made by gerrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748843&group_id=5470 >Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let Email.Utils.parsedate use last 3 timetuple items Initial Comment: Hi, this patch changes the behaviour of Email.Utils.parsedate. Currently, the last 3 tuple items are unused. One place where this complicates things unnecessarily is when trying to find out the week number: currently, it is necessary to convert the tuple back and forth to a timestamp by hand, in order to retrieve the information in the last 3 items. This patch fixes this, and makes the default behaviour to use all timetuple fields. It also changes the corresponding documentation. I also sent this to patches@python.org when SF was down. Gerrit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748843&group_id=5470 From noreply@sourceforge.net Wed Jun 4 14:28:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2003 06:28:00 -0700 Subject: [Patches] [ python-Patches-748849 ] Update Tools+Demos/scripts/README file Message-ID: Patches item #748849, was opened at 2003-06-04 13:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748849&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Update Tools+Demos/scripts/README file Initial Comment: Hi, both the Tools/scripts/README and the Demo/scripts/README file were outdated: some scripts were missing, and some descriptions of removed files were included. BTW, I think Demo/scripts/wh.py could better be removed, it somehow seems outdated to me ;) This patch was sent earlier to patches@python.org when SF was down. Gerrit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748849&group_id=5470 From noreply@sourceforge.net Wed Jun 4 14:22:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2003 06:22:37 -0700 Subject: [Patches] [ python-Patches-748843 ] Let Email.Utils.parsedate use last 3 timetuple items Message-ID: Patches item #748843, was opened at 2003-06-04 13:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748843&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let Email.Utils.parsedate use last 3 timetuple items Initial Comment: Hi, this patch changes the behaviour of Email.Utils.parsedate. Currently, the last 3 tuple items are unused. One place where this complicates things unnecessarily is when trying to find out the week number: currently, it is necessary to convert the tuple back and forth to a timestamp by hand, in order to retrieve the information in the last 3 items. This patch fixes this, and makes the default behaviour to use all timetuple fields. It also changes the corresponding documentation. I also sent this to patches@python.org when SF was down. Gerrit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748843&group_id=5470 From noreply@sourceforge.net Wed Jun 4 18:12:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2003 10:12:57 -0700 Subject: [Patches] [ python-Patches-749012 ] Describe formation of method objects more accurately Message-ID: Patches item #749012, was opened at 2003-06-04 17:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749012&group_id=5470 Category: Documentation Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gareth McCaughan (gjm-w) Assigned to: Nobody/Anonymous (nobody) Summary: Describe formation of method objects more accurately Initial Comment: The documentation doesn't currently describe user-defined method objects very well, nor does it mention static method objects and class method objects (except in passing, while describing the staticmethod and classmethod functions). For instance, it says "User-defined method objects are created in two ways: when getting an attribute of a class that is a user-defined function object, or when getting an attribute of a class instance that is a user-defined function object defined by the class of the instance." It's not obvious what "defined by the class of the instance" means. (1) If it means "when the function was defined, that was within the scope of a `class' statement", then it's just plain wrong; it doesn't matter where the function was defined. (2) If it means "the place from which the attribute is retrieved is the class rather than the instance", it's right, but that doesn't seem to me a natural reading. (3) If it means "the exact place from which the attribute is retrieved is the class's dictionary" (as opposed to that of some other class) then it's wrong; a superclass would do just as well. It's also too specific; as well as user-defined function objects, the same process is applied to certain user-defined method objects, and to class method objects. There are similar problems elsewhere. * The attached patch improves this state of affairs. It's relative to python/dist/src/Doc/ref/ref3 from CVS as of a couple of hours ago. One oddity I don't understand: with this patch applied, the reference manual has a larger than expected vertical space between the first two paragraphs beginning "When a user-defined method object is created". Both these paragraphs are newly created by the patch, so this must be my fault somehow. I don't see how. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749012&group_id=5470 From noreply@sourceforge.net Wed Jun 4 18:15:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2003 10:15:33 -0700 Subject: [Patches] [ python-Patches-749012 ] Describe formation of method objects more accurately Message-ID: Patches item #749012, was opened at 2003-06-04 17:12 Message generated for change (Comment added) made by gjm-w You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749012&group_id=5470 Category: Documentation Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gareth McCaughan (gjm-w) Assigned to: Nobody/Anonymous (nobody) Summary: Describe formation of method objects more accurately Initial Comment: The documentation doesn't currently describe user-defined method objects very well, nor does it mention static method objects and class method objects (except in passing, while describing the staticmethod and classmethod functions). For instance, it says "User-defined method objects are created in two ways: when getting an attribute of a class that is a user-defined function object, or when getting an attribute of a class instance that is a user-defined function object defined by the class of the instance." It's not obvious what "defined by the class of the instance" means. (1) If it means "when the function was defined, that was within the scope of a `class' statement", then it's just plain wrong; it doesn't matter where the function was defined. (2) If it means "the place from which the attribute is retrieved is the class rather than the instance", it's right, but that doesn't seem to me a natural reading. (3) If it means "the exact place from which the attribute is retrieved is the class's dictionary" (as opposed to that of some other class) then it's wrong; a superclass would do just as well. It's also too specific; as well as user-defined function objects, the same process is applied to certain user-defined method objects, and to class method objects. There are similar problems elsewhere. * The attached patch improves this state of affairs. It's relative to python/dist/src/Doc/ref/ref3 from CVS as of a couple of hours ago. One oddity I don't understand: with this patch applied, the reference manual has a larger than expected vertical space between the first two paragraphs beginning "When a user-defined method object is created". Both these paragraphs are newly created by the patch, so this must be my fault somehow. I don't see how. :-) ---------------------------------------------------------------------- >Comment By: Gareth McCaughan (gjm-w) Date: 2003-06-04 17:15 Message: Logged In: YES user_id=338732 The summary suggests that the scope of the patch is a little narrower than it really is. The changes it makes are: - improve the description of how user-defined method objects get made - improve the description of attribute retrieval from classes and class instances - add brief documentation of static method and class method objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749012&group_id=5470 From noreply@sourceforge.net Wed Jun 4 23:06:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2003 15:06:29 -0700 Subject: [Patches] [ python-Patches-749190 ] memory leak of "callit"s using after_cancel in tkinter Message-ID: Patches item #749190, was opened at 2003-06-04 15:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749190&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Paul Janzen (pjanzen) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak of "callit"s using after_cancel in tkinter Initial Comment: I have observed a memory leak in tkinter when using after_cancel to disable pending alarm callbacks. The Tkinter.py code for "after" builds a function object with enough information to dispose of itself after the user's callback has been executed. This function object ("callit") is registered with _register(). In the normal flow, the Tk main loop wakes up after the allotted time has passed and invokes the callit function, which in turn calls the user-provided function and deletes the callit() function from the Tcl interpreter and the Python interpreter. However, when the program aborts the "after" callback with "after_cancel," this cleanup is not performed. As a result, the "callit" callback remains registered in both Tcl and Python interpreters. (By way of background, I am developing a program that communicates with a device; every time I send data to the device, I set up an alarm handler which gets canceled when the device responds. So I am performing after and after_cancel on every transaction. The memory usage can grow very quickly in this situation.) The attached patch is my quick hack at solving the problem. There may be a more elegant way to retrieve the Python callback name from the after id, but this method does stop the memory leaks. The patch is against the Tkinter.py distributed with ActiveState 2.2.2 build 224; however, the problem appears to still be present in CVS HEAD. Thanks, -- Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749190&group_id=5470 From noreply@sourceforge.net Wed Jun 4 23:06:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2003 15:06:44 -0700 Subject: [Patches] [ python-Patches-749191 ] memory leak of "callit"s using after_cancel in tkinter Message-ID: Patches item #749191, was opened at 2003-06-04 15:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749191&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Paul Janzen (pjanzen) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak of "callit"s using after_cancel in tkinter Initial Comment: I have observed a memory leak in tkinter when using after_cancel to disable pending alarm callbacks. The Tkinter.py code for "after" builds a function object with enough information to dispose of itself after the user's callback has been executed. This function object ("callit") is registered with _register(). In the normal flow, the Tk main loop wakes up after the allotted time has passed and invokes the callit function, which in turn calls the user-provided function and deletes the callit() function from the Tcl interpreter and the Python interpreter. However, when the program aborts the "after" callback with "after_cancel," this cleanup is not performed. As a result, the "callit" callback remains registered in both Tcl and Python interpreters. (By way of background, I am developing a program that communicates with a device; every time I send data to the device, I set up an alarm handler which gets canceled when the device responds. So I am performing after and after_cancel on every transaction. The memory usage can grow very quickly in this situation.) The attached patch is my quick hack at solving the problem. There may be a more elegant way to retrieve the Python callback name from the after id, but this method does stop the memory leaks. The patch is against the Tkinter.py distributed with ActiveState 2.2.2 build 224; however, the problem appears to still be present in CVS HEAD. Thanks, -- Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749191&group_id=5470 From noreply@sourceforge.net Wed Jun 4 23:08:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2003 15:08:41 -0700 Subject: [Patches] [ python-Patches-749190 ] memory leak of "callit"s using after_cancel in tkinter Message-ID: Patches item #749190, was opened at 2003-06-04 15:06 Message generated for change (Settings changed) made by pjanzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749190&group_id=5470 Category: Tkinter Group: Python 2.2.x >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Paul Janzen (pjanzen) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak of "callit"s using after_cancel in tkinter Initial Comment: I have observed a memory leak in tkinter when using after_cancel to disable pending alarm callbacks. The Tkinter.py code for "after" builds a function object with enough information to dispose of itself after the user's callback has been executed. This function object ("callit") is registered with _register(). In the normal flow, the Tk main loop wakes up after the allotted time has passed and invokes the callit function, which in turn calls the user-provided function and deletes the callit() function from the Tcl interpreter and the Python interpreter. However, when the program aborts the "after" callback with "after_cancel," this cleanup is not performed. As a result, the "callit" callback remains registered in both Tcl and Python interpreters. (By way of background, I am developing a program that communicates with a device; every time I send data to the device, I set up an alarm handler which gets canceled when the device responds. So I am performing after and after_cancel on every transaction. The memory usage can grow very quickly in this situation.) The attached patch is my quick hack at solving the problem. There may be a more elegant way to retrieve the Python callback name from the after id, but this method does stop the memory leaks. The patch is against the Tkinter.py distributed with ActiveState 2.2.2 build 224; however, the problem appears to still be present in CVS HEAD. Thanks, -- Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749190&group_id=5470 From noreply@sourceforge.net Thu Jun 5 15:55:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2003 07:55:16 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 16:33 Message generated for change (Comment added) made by yotam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 17:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 06:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 21:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 20:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 20:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 20:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 19:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 02:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-30 00:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-28 03:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 17:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Thu Jun 5 15:59:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2003 07:59:07 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 10:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 10:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-22 23:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 14:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 13:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 19:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Thu Jun 5 21:08:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2003 13:08:15 -0700 Subject: [Patches] [ python-Patches-749759 ] comparisons yield bool not int Message-ID: Patches item #749759, was opened at 2003-06-05 20:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749759&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: comparisons yield bool not int Initial Comment: fix ref5.tex statement that comparisons yield integer values: should be boolean. Gerrit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749759&group_id=5470 From noreply@sourceforge.net Thu Jun 5 23:02:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2003 15:02:52 -0700 Subject: [Patches] [ python-Patches-749830 ] allow UNIX mmap size to default to current file size Message-ID: Patches item #749830, was opened at 2003-06-05 18:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749830&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: allow UNIX mmap size to default to current file size Initial Comment: This patch makes the UNIX mmap behave like the Windows mmap in that if you pass 0 as the mmap size, the map size will default to the current length of the file being mmapped. This allows avoids a call to os.stat if you want to map the entire file. It also makes code using this feature of the Windows mmap to be portable to UNIX. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749830&group_id=5470 From noreply@sourceforge.net Fri Jun 6 03:52:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2003 19:52:53 -0700 Subject: [Patches] [ python-Patches-749759 ] comparisons yield bool not int Message-ID: Patches item #749759, was opened at 2003-06-05 15:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749759&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: comparisons yield bool not int Initial Comment: fix ref5.tex statement that comparisons yield integer values: should be boolean. Gerrit ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-05 21:52 Message: Logged In: YES user_id=80475 Fixed. See Doc/ref/ref5.tex 1.73 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749759&group_id=5470 From noreply@sourceforge.net Fri Jun 6 10:47:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2003 02:47:24 -0700 Subject: [Patches] [ python-Patches-750008 ] 'compiler' module bug with 'import foo.bar as baz' Message-ID: Patches item #750008, was opened at 2003-06-06 11:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750008&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ronny Wikh (mrpr) Assigned to: Nobody/Anonymous (nobody) Summary: 'compiler' module bug with 'import foo.bar as baz' Initial Comment: Python package 'compiler' generates incorrect code for statements on the format 'import foo.bar as baz'. Code to illustrate this follows: ----------------------- program = ''' import foo.bar as baz ''' code1 = compile(program, 'foobar', 'exec') code2 = compiler.compile(program, 'foobar', 'exec') print 'CODE builtin' dis.disassemble(code1) print print 'CODE compiler package' dis.disassemble(code2) ----------------------- With the output: ----------------------- CODE builtin 0 SET_LINENO 0 3 SET_LINENO 2 6 LOAD_CONST 0 (None) 9 IMPORT_NAME 0 (foo.bar) 12 LOAD_ATTR 1 (bar) 15 STORE_NAME 2 (baz) 18 LOAD_CONST 0 (None) 21 RETURN_VALUE CODE compiler package 0 SET_LINENO 0 3 SET_LINENO 2 6 LOAD_CONST 0 (None) 9 IMPORT_NAME 0 (foo.bar) 12 STORE_NAME 1 (baz) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE ----------------------- The attached patch fixes this bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750008&group_id=5470 From noreply@sourceforge.net Fri Jun 6 23:23:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2003 15:23:28 -0700 Subject: [Patches] [ python-Patches-749191 ] memory leak of "callit"s using after_cancel in tkinter Message-ID: Patches item #749191, was opened at 2003-06-05 00:06 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749191&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Paul Janzen (pjanzen) >Assigned to: Martin v. Löwis (loewis) Summary: memory leak of "callit"s using after_cancel in tkinter Initial Comment: I have observed a memory leak in tkinter when using after_cancel to disable pending alarm callbacks. The Tkinter.py code for "after" builds a function object with enough information to dispose of itself after the user's callback has been executed. This function object ("callit") is registered with _register(). In the normal flow, the Tk main loop wakes up after the allotted time has passed and invokes the callit function, which in turn calls the user-provided function and deletes the callit() function from the Tcl interpreter and the Python interpreter. However, when the program aborts the "after" callback with "after_cancel," this cleanup is not performed. As a result, the "callit" callback remains registered in both Tcl and Python interpreters. (By way of background, I am developing a program that communicates with a device; every time I send data to the device, I set up an alarm handler which gets canceled when the device responds. So I am performing after and after_cancel on every transaction. The memory usage can grow very quickly in this situation.) The attached patch is my quick hack at solving the problem. There may be a more elegant way to retrieve the Python callback name from the after id, but this method does stop the memory leaks. The patch is against the Tkinter.py distributed with ActiveState 2.2.2 build 224; however, the problem appears to still be present in CVS HEAD. Thanks, -- Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749191&group_id=5470 From noreply@sourceforge.net Fri Jun 6 23:23:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2003 15:23:59 -0700 Subject: [Patches] [ python-Patches-748849 ] Update Tools+Demos/scripts/README file Message-ID: Patches item #748849, was opened at 2003-06-04 15:28 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748849&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) >Assigned to: Martin v. Löwis (loewis) Summary: Update Tools+Demos/scripts/README file Initial Comment: Hi, both the Tools/scripts/README and the Demo/scripts/README file were outdated: some scripts were missing, and some descriptions of removed files were included. BTW, I think Demo/scripts/wh.py could better be removed, it somehow seems outdated to me ;) This patch was sent earlier to patches@python.org when SF was down. Gerrit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748849&group_id=5470 From noreply@sourceforge.net Fri Jun 6 23:24:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2003 15:24:21 -0700 Subject: [Patches] [ python-Patches-748846 ] Let Demo/classes/Date.py mention DateTime module Message-ID: Patches item #748846, was opened at 2003-06-04 15:24 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748846&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) >Assigned to: Martin v. Löwis (loewis) Summary: Let Demo/classes/Date.py mention DateTime module Initial Comment: Hi, this patch changes the comments in Demo/classes/Date.py. It fixes a typo and explains that the DateTime module, introduced in Python 2.3, is included in the standard library. I also sent this patch to patches@python.org when SF was down. Gerrit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748846&group_id=5470 From noreply@sourceforge.net Fri Jun 6 23:26:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2003 15:26:58 -0700 Subject: [Patches] [ python-Patches-746801 ] FreeBSD 4 port of python-2.2.3... Message-ID: Patches item #746801, was opened at 2003-06-01 01:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 Category: Tests Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Charles Swiger (cws3) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 4 port of python-2.2.3... Initial Comment: Add list of tests expected to be skipped for the 'freebsd4' platform. Diff applies okay to current CVS sources as well. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 00:26 Message: Logged In: YES user_id=21627 Can you provide a patch for Python 2.3 instead, or in addition? I doubt minidom is supposed to be skipped on FreeBSD 4 in Python 2.3. ---------------------------------------------------------------------- Comment By: Charles Swiger (cws3) Date: 2003-06-01 04:03 Message: Logged In: YES user_id=789947 Submitted port as http://www.freebsd.org/cgi/query-pr.cgi?pr=52830. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 From noreply@sourceforge.net Fri Jun 6 23:28:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2003 15:28:29 -0700 Subject: [Patches] [ python-Patches-729305 ] Compiler warning on Solaris 8 Message-ID: Patches item #729305, was opened at 2003-04-29 04:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729305&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: George Neville-Neil (gnn) Assigned to: Neal Norwitz (nnorwitz) Summary: Compiler warning on Solaris 8 Initial Comment: When compiling Python 2.2 on Solaris 8 there are complaints about _FILE_OFFSET_BITS being redefined. The following is a patch to configure.in to remedy this. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 00:28 Message: Logged In: YES user_id=21627 Rejecting the patch: There is no bug that it fixes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 01:57 Message: Logged In: YES user_id=21627 Your observation is incorrect: sys/feature_tests.h does *not* unconditionally define _FILE_OFFSET_BITS. Instead, it reads #if defined(_LP64) #ifndef _FILE_OFFSET_BITS #define _FILE_OFFSET_BITS 64 #endif #if _FILE_OFFSET_BITS - 0 != 64 #error "invalid _FILE_OFFSET_BITS value specified" #endif #else /* _LP64 */ #ifndef _FILE_OFFSET_BITS #define _FILE_OFFSET_BITS 32 #endif #if _FILE_OFFSET_BITS - 0 != 32 && _FILE_OFFSET_BITS - 0 != 64 #error "invalid _FILE_OFFSET_BITS value specified" #endif #endif /* _LP64 */ So _FILE_OFFSET_BITS is always defined conditionally only, on the condition that it isn't already defined. Since Python.h is included before anything else, feature_tests.h does *not* define it, ever. ---------------------------------------------------------------------- Comment By: George Neville-Neil (gnn) Date: 2003-05-03 01:12 Message: Logged In: YES user_id=767347 The point of the patch is that on Solaris 8 there is a file that already defines this and if configure does not notice this then both pyconfig.h and the OS file sys/feature_test.h define it and when building a program with Python embedded in it you get a lot of warnings. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-29 13:47 Message: Logged In: YES user_id=21627 The patch is clearly incorrect; Python *must* define _FILE_OFFSET_BITS. What specific problem does that patch fix? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 06:47 Message: Logged In: YES user_id=80475 Neal, is this something you know about? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729305&group_id=5470 From noreply@sourceforge.net Sat Jun 7 14:11:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 06:11:36 -0700 Subject: [Patches] [ python-Patches-750542 ] Let pprint.py use issubclass instead of is for type checking Message-ID: Patches item #750542, was opened at 2003-06-07 13:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let pprint.py use issubclass instead of is for type checking Initial Comment: Hi, subclasses of dict, list, tuple etc. should be pretty-printed according to the same rules as dict, list and tuple themselves. Because of that, this patch changes pprint.py so that rather than checking types using 'typ is list', pprint checks types using 'issubclass(typ, list)'. Gerrit Holl Patched against latest CVS ( 07/06/2003 13:11:24 UTC) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 From noreply@sourceforge.net Sat Jun 7 17:20:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 09:20:24 -0700 Subject: [Patches] [ python-Patches-750595 ] patch for bug #595837 Message-ID: Patches item #750595, was opened at 2003-06-07 16:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750595&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: patch for bug #595837 Initial Comment: Compiling Python with #define WITHOUT_COMPLEX works fine, but there is a (single) place in the standard library that uses the complex number syntax : copy_reg.py. This makes Python quite unusable, because a lot of other modules rely on being able to import this one successfully. There are also a number of test files that use the complex syntax. I don't think I could be bothered to fix the relevant ones however. The attached patch uses 'complex' as a synonym of 'type(1j)'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750595&group_id=5470 From noreply@sourceforge.net Sat Jun 7 17:33:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 09:33:55 -0700 Subject: [Patches] [ python-Patches-746801 ] FreeBSD 4 port of python-2.2.3... Message-ID: Patches item #746801, was opened at 2003-05-31 23:27 Message generated for change (Comment added) made by cws3 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 Category: Tests Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Charles Swiger (cws3) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 4 port of python-2.2.3... Initial Comment: Add list of tests expected to be skipped for the 'freebsd4' platform. Diff applies okay to current CVS sources as well. ---------------------------------------------------------------------- >Comment By: Charles Swiger (cws3) Date: 2003-06-07 16:33 Message: Logged In: YES user_id=789947 I'd be pleased to take a look and generate a diff against either 2.3b1 or against the CVS sources. minidom was skipped because "no XML parser was available", as a dependency on pyexpat IIRC? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-06 22:26 Message: Logged In: YES user_id=21627 Can you provide a patch for Python 2.3 instead, or in addition? I doubt minidom is supposed to be skipped on FreeBSD 4 in Python 2.3. ---------------------------------------------------------------------- Comment By: Charles Swiger (cws3) Date: 2003-06-01 02:03 Message: Logged In: YES user_id=789947 Submitted port as http://www.freebsd.org/cgi/query-pr.cgi?pr=52830. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 From noreply@sourceforge.net Sat Jun 7 18:08:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 10:08:15 -0700 Subject: [Patches] [ python-Patches-746801 ] FreeBSD 4 port of python-2.2.3... Message-ID: Patches item #746801, was opened at 2003-05-31 23:27 Message generated for change (Comment added) made by cws3 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 Category: Tests Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Charles Swiger (cws3) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 4 port of python-2.2.3... Initial Comment: Add list of tests expected to be skipped for the 'freebsd4' platform. Diff applies okay to current CVS sources as well. ---------------------------------------------------------------------- >Comment By: Charles Swiger (cws3) Date: 2003-06-07 17:08 Message: Logged In: YES user_id=789947 Under 2.3, minidom, sax, and expat are all recognized and test properly. Yay! On the other hand, there seems to a problem with the curses module and "wchar_t". I'll include both... ---------------------------------------------------------------------- Comment By: Charles Swiger (cws3) Date: 2003-06-07 16:33 Message: Logged In: YES user_id=789947 I'd be pleased to take a look and generate a diff against either 2.3b1 or against the CVS sources. minidom was skipped because "no XML parser was available", as a dependency on pyexpat IIRC? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-06 22:26 Message: Logged In: YES user_id=21627 Can you provide a patch for Python 2.3 instead, or in addition? I doubt minidom is supposed to be skipped on FreeBSD 4 in Python 2.3. ---------------------------------------------------------------------- Comment By: Charles Swiger (cws3) Date: 2003-06-01 02:03 Message: Logged In: YES user_id=789947 Submitted port as http://www.freebsd.org/cgi/query-pr.cgi?pr=52830. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 From noreply@sourceforge.net Sat Jun 7 18:55:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 10:55:05 -0700 Subject: [Patches] [ python-Patches-742823 ] Ordering of handlers in urllib2 Message-ID: Patches item #742823, was opened at 2003-05-24 18:47 Message generated for change (Settings changed) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742823&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: Ordering of handlers in urllib2 Initial Comment: With this patch urllib2.py will know how to order proxy classes, so the user doesn't have to insert it in front of other classes, nor do dirty tricks like inserting a "dummy" HTTPHandler after a ProxyHandler when building an opener with proxy support. It is also interesting enough to let the users easily create their own specially ordered handlers. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-07 17:55 Message: Logged In: YES user_id=7887 Applied as: Doc/lib/liburllib2.tex: 1.10 Lib/urllib2.py: 1.48 Misc/NEWS: 1.775 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742823&group_id=5470 From noreply@sourceforge.net Sat Jun 7 19:47:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 11:47:21 -0700 Subject: [Patches] [ python-Patches-748849 ] Update Tools+Demos/scripts/README file Message-ID: Patches item #748849, was opened at 2003-06-04 15:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748849&group_id=5470 Category: Demos and tools Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Martin v. Löwis (loewis) Summary: Update Tools+Demos/scripts/README file Initial Comment: Hi, both the Tools/scripts/README and the Demo/scripts/README file were outdated: some scripts were missing, and some descriptions of removed files were included. BTW, I think Demo/scripts/wh.py could better be removed, it somehow seems outdated to me ;) This patch was sent earlier to patches@python.org when SF was down. Gerrit. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 20:47 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as README 1.20 README 1.12 Notice that these files use tabulators to separate file name and description. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748849&group_id=5470 From noreply@sourceforge.net Sat Jun 7 20:42:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 12:42:02 -0700 Subject: [Patches] [ python-Patches-748846 ] Let Demo/classes/Date.py mention DateTime module Message-ID: Patches item #748846, was opened at 2003-06-04 15:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748846&group_id=5470 Category: Demos and tools Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Martin v. Löwis (loewis) Summary: Let Demo/classes/Date.py mention DateTime module Initial Comment: Hi, this patch changes the comments in Demo/classes/Date.py. It fixes a typo and explains that the DateTime module, introduced in Python 2.3, is included in the standard library. I also sent this patch to patches@python.org when SF was down. Gerrit. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 21:42 Message: Logged In: YES user_id=21627 Thanks for the patch. I have added the datetime reference as Dates.py 1.4. The "iff" is no typo; it is short for "if and only if". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748846&group_id=5470 From noreply@sourceforge.net Sat Jun 7 20:55:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 12:55:15 -0700 Subject: [Patches] [ python-Patches-749191 ] memory leak of "callit"s using after_cancel in tkinter Message-ID: Patches item #749191, was opened at 2003-06-05 00:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749191&group_id=5470 Category: Tkinter Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Paul Janzen (pjanzen) Assigned to: Martin v. Löwis (loewis) Summary: memory leak of "callit"s using after_cancel in tkinter Initial Comment: I have observed a memory leak in tkinter when using after_cancel to disable pending alarm callbacks. The Tkinter.py code for "after" builds a function object with enough information to dispose of itself after the user's callback has been executed. This function object ("callit") is registered with _register(). In the normal flow, the Tk main loop wakes up after the allotted time has passed and invokes the callit function, which in turn calls the user-provided function and deletes the callit() function from the Tcl interpreter and the Python interpreter. However, when the program aborts the "after" callback with "after_cancel," this cleanup is not performed. As a result, the "callit" callback remains registered in both Tcl and Python interpreters. (By way of background, I am developing a program that communicates with a device; every time I send data to the device, I set up an alarm handler which gets canceled when the device responds. So I am performing after and after_cancel on every transaction. The memory usage can grow very quickly in this situation.) The attached patch is my quick hack at solving the problem. There may be a more elegant way to retrieve the Python callback name from the after id, but this method does stop the memory leaks. The patch is against the Tkinter.py distributed with ActiveState 2.2.2 build 224; however, the problem appears to still be present in CVS HEAD. Thanks, -- Paul ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 21:55 Message: Logged In: YES user_id=21627 Thanks for the patch. I think your approach is entirely appropriate. Applied as Tkinter.py 1.176 and 1.160.10.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749191&group_id=5470 From noreply@sourceforge.net Sat Jun 7 21:04:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 13:04:39 -0700 Subject: [Patches] [ python-Patches-746801 ] FreeBSD 4 port of python-2.2.3... Message-ID: Patches item #746801, was opened at 2003-06-01 01:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 Category: Tests Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Charles Swiger (cws3) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 4 port of python-2.2.3... Initial Comment: Add list of tests expected to be skipped for the 'freebsd4' platform. Diff applies okay to current CVS sources as well. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 22:04 Message: Logged In: YES user_id=21627 Thanks for the patches; applied as regrtest.py 1.142 and 1.70.4.5. pyexpat is now found as Expat is now distributed with the Python source code. The wchar_t problem looks like a FreeBSD bug; it appears that ncurses.h and stdlib.h are incompatible. I recommend you report this to the FreeBSD maintainers. ---------------------------------------------------------------------- Comment By: Charles Swiger (cws3) Date: 2003-06-07 19:08 Message: Logged In: YES user_id=789947 Under 2.3, minidom, sax, and expat are all recognized and test properly. Yay! On the other hand, there seems to a problem with the curses module and "wchar_t". I'll include both... ---------------------------------------------------------------------- Comment By: Charles Swiger (cws3) Date: 2003-06-07 18:33 Message: Logged In: YES user_id=789947 I'd be pleased to take a look and generate a diff against either 2.3b1 or against the CVS sources. minidom was skipped because "no XML parser was available", as a dependency on pyexpat IIRC? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 00:26 Message: Logged In: YES user_id=21627 Can you provide a patch for Python 2.3 instead, or in addition? I doubt minidom is supposed to be skipped on FreeBSD 4 in Python 2.3. ---------------------------------------------------------------------- Comment By: Charles Swiger (cws3) Date: 2003-06-01 04:03 Message: Logged In: YES user_id=789947 Submitted port as http://www.freebsd.org/cgi/query-pr.cgi?pr=52830. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 From noreply@sourceforge.net Sat Jun 7 21:12:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 13:12:31 -0700 Subject: [Patches] [ python-Patches-750595 ] patch for bug #595837 Message-ID: Patches item #750595, was opened at 2003-06-07 18:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750595&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: patch for bug #595837 Initial Comment: Compiling Python with #define WITHOUT_COMPLEX works fine, but there is a (single) place in the standard library that uses the complex number syntax : copy_reg.py. This makes Python quite unusable, because a lot of other modules rely on being able to import this one successfully. There are also a number of test files that use the complex syntax. I don't think I could be bothered to fix the relevant ones however. The attached patch uses 'complex' as a synonym of 'type(1j)'. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 22:12 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as 1.25 and 1.9.6.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750595&group_id=5470 From noreply@sourceforge.net Sat Jun 7 21:30:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 13:30:57 -0700 Subject: [Patches] [ python-Patches-750542 ] Let pprint.py use issubclass instead of is for type checking Message-ID: Patches item #750542, was opened at 2003-06-07 09:11 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let pprint.py use issubclass instead of is for type checking Initial Comment: Hi, subclasses of dict, list, tuple etc. should be pretty-printed according to the same rules as dict, list and tuple themselves. Because of that, this patch changes pprint.py so that rather than checking types using 'typ is list', pprint checks types using 'issubclass(typ, list)'. Gerrit Holl Patched against latest CVS ( 07/06/2003 13:11:24 UTC) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-07 16:30 Message: Logged In: YES user_id=3066 >From python-dev: http://mail.python.org/pipermail/python-dev/2003-June/036008.html Hmm; this patch was never assigned to me, so I was unaware that anyone thought there was a problem with this. I specifically considered making changes like these when subclassing built-in types became possible, but decided against it since it didn't appear reasonable to assume that __repr__() hadn't been redefined. I'm sure it's possible to check, but to do so cleanly and efficiently seems like a huge change to the module for little value. I think the patch, as it stands, should be reverted. If another patch appears that addresses the issue of overridden __repr__() methods, it should be considered again. -1 for the patch as applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 From noreply@sourceforge.net Sat Jun 7 21:31:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 13:31:41 -0700 Subject: [Patches] [ python-Patches-750542 ] Let pprint.py use issubclass instead of is for type checking Message-ID: Patches item #750542, was opened at 2003-06-07 15:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let pprint.py use issubclass instead of is for type checking Initial Comment: Hi, subclasses of dict, list, tuple etc. should be pretty-printed according to the same rules as dict, list and tuple themselves. Because of that, this patch changes pprint.py so that rather than checking types using 'typ is list', pprint checks types using 'issubclass(typ, list)'. Gerrit Holl Patched against latest CVS ( 07/06/2003 13:11:24 UTC) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 22:31 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as pprint.py 1.25. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-07 22:30 Message: Logged In: YES user_id=3066 >From python-dev: http://mail.python.org/pipermail/python-dev/2003-June/036008.html Hmm; this patch was never assigned to me, so I was unaware that anyone thought there was a problem with this. I specifically considered making changes like these when subclassing built-in types became possible, but decided against it since it didn't appear reasonable to assume that __repr__() hadn't been redefined. I'm sure it's possible to check, but to do so cleanly and efficiently seems like a huge change to the module for little value. I think the patch, as it stands, should be reverted. If another patch appears that addresses the issue of overridden __repr__() methods, it should be considered again. -1 for the patch as applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 From noreply@sourceforge.net Sat Jun 7 21:49:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 13:49:17 -0700 Subject: [Patches] [ python-Patches-750542 ] Let pprint.py use issubclass instead of is for type checking Message-ID: Patches item #750542, was opened at 2003-06-07 15:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let pprint.py use issubclass instead of is for type checking Initial Comment: Hi, subclasses of dict, list, tuple etc. should be pretty-printed according to the same rules as dict, list and tuple themselves. Because of that, this patch changes pprint.py so that rather than checking types using 'typ is list', pprint checks types using 'issubclass(typ, list)'. Gerrit Holl Patched against latest CVS ( 07/06/2003 13:11:24 UTC) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 22:49 Message: Logged In: YES user_id=21627 I have reverted the patch on Fred's request. The patch does not support an overridden __repr__ implementation, and thus has to be rejected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 22:31 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as pprint.py 1.25. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-07 22:30 Message: Logged In: YES user_id=3066 >From python-dev: http://mail.python.org/pipermail/python-dev/2003-June/036008.html Hmm; this patch was never assigned to me, so I was unaware that anyone thought there was a problem with this. I specifically considered making changes like these when subclassing built-in types became possible, but decided against it since it didn't appear reasonable to assume that __repr__() hadn't been redefined. I'm sure it's possible to check, but to do so cleanly and efficiently seems like a huge change to the module for little value. I think the patch, as it stands, should be reverted. If another patch appears that addresses the issue of overridden __repr__() methods, it should be considered again. -1 for the patch as applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 From noreply@sourceforge.net Sat Jun 7 22:24:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 14:24:12 -0700 Subject: [Patches] [ python-Patches-746801 ] FreeBSD 4 port of python-2.2.3... Message-ID: Patches item #746801, was opened at 2003-05-31 23:27 Message generated for change (Comment added) made by cws3 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 Category: Tests Group: Python 2.2.x Status: Closed Resolution: Accepted Priority: 5 Submitted By: Charles Swiger (cws3) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 4 port of python-2.2.3... Initial Comment: Add list of tests expected to be skipped for the 'freebsd4' platform. Diff applies okay to current CVS sources as well. ---------------------------------------------------------------------- >Comment By: Charles Swiger (cws3) Date: 2003-06-07 21:24 Message: Logged In: YES user_id=789947 Thanks for the commit, and for your time. PR submitted to FreeBSD with regard to the "wchar_t" problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 20:04 Message: Logged In: YES user_id=21627 Thanks for the patches; applied as regrtest.py 1.142 and 1.70.4.5. pyexpat is now found as Expat is now distributed with the Python source code. The wchar_t problem looks like a FreeBSD bug; it appears that ncurses.h and stdlib.h are incompatible. I recommend you report this to the FreeBSD maintainers. ---------------------------------------------------------------------- Comment By: Charles Swiger (cws3) Date: 2003-06-07 17:08 Message: Logged In: YES user_id=789947 Under 2.3, minidom, sax, and expat are all recognized and test properly. Yay! On the other hand, there seems to a problem with the curses module and "wchar_t". I'll include both... ---------------------------------------------------------------------- Comment By: Charles Swiger (cws3) Date: 2003-06-07 16:33 Message: Logged In: YES user_id=789947 I'd be pleased to take a look and generate a diff against either 2.3b1 or against the CVS sources. minidom was skipped because "no XML parser was available", as a dependency on pyexpat IIRC? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-06 22:26 Message: Logged In: YES user_id=21627 Can you provide a patch for Python 2.3 instead, or in addition? I doubt minidom is supposed to be skipped on FreeBSD 4 in Python 2.3. ---------------------------------------------------------------------- Comment By: Charles Swiger (cws3) Date: 2003-06-01 02:03 Message: Logged In: YES user_id=789947 Submitted port as http://www.freebsd.org/cgi/query-pr.cgi?pr=52830. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746801&group_id=5470 From noreply@sourceforge.net Sun Jun 8 00:06:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2003 16:06:25 -0700 Subject: [Patches] [ python-Patches-711448 ] Warn about inter-module assignments shadowing builtins Message-ID: Patches item #711448, was opened at 2003-03-28 17:12 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Guido van Rossum (gvanrossum) Summary: Warn about inter-module assignments shadowing builtins Initial Comment: The attached patch modifies module tp_setattro to warn about code that adds a name to the globals of another module that shadows a builtin. Unfortunately, there are other ways to modify module globals (e.g. using vars() and mutating the dictionary). There are a few issues with module objects that I'm not clear about. For example, do modules always have a md_dict that is a PyDictObject? ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-06-07 23:06 Message: Logged In: YES user_id=35752 Here's a new version that uses PyEval_GetBuiltins() to get the builtin module dict and then builds a set of builtin names from that. Is using PyEval_GetBuiltins() safe? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-20 21:20 Message: Logged In: YES user_id=6380 The basic idea of the patch is sound. Why can't you check whether the name is in __builtin__.__dict__ ? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-04-20 16:17 Message: Logged In: YES user_id=35752 Is it okay if I move the list to the bltinmodule as a non-static variable? That would make it easier for the compiler to use the list if or when it was changed to optimize builtin lookup. Also, is the basic idea of this patch sound? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 19:01 Message: Logged In: YES user_id=6380 Hm, it's kind of ugly to list all built-in names explicitly; this list will be out of sync whenever a new built-in is added. Can't you access the __builtin__ module and use its keys? (One way to get the __builtin__ module is to use PySys_GetObject("modules"), which should give you sys.modules, and take it from there; you can count on __builtin__ to be there, and if it's not, forget the whole thing.) ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-03-28 17:15 Message: Logged In: YES user_id=35752 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 From noreply@sourceforge.net Sun Jun 8 14:57:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 06:57:38 -0700 Subject: [Patches] [ python-Patches-735051 ] time.tzset documentation Message-ID: Patches item #735051, was opened at 2003-05-09 02:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735051&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Stuart Bishop (zenzen) >Assigned to: Neal Norwitz (nnorwitz) Summary: time.tzset documentation Initial Comment: Here is the documentation for the time.tzset method, to be inserted in Doc/lib/libtime.tex just after tzname, or wherever else you think it fits. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-08 09:57 Message: Logged In: YES user_id=33168 Thanks! Checked in as: Doc/lib/libtime.tex 1.57 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735051&group_id=5470 From noreply@sourceforge.net Sun Jun 8 21:06:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 13:06:31 -0700 Subject: [Patches] [ python-Patches-750542 ] Let pprint.py use issubclass instead of is for type checking Message-ID: Patches item #750542, was opened at 2003-06-07 13:11 Message generated for change (Comment added) made by gerrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Open Resolution: Rejected Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let pprint.py use issubclass instead of is for type checking Initial Comment: Hi, subclasses of dict, list, tuple etc. should be pretty-printed according to the same rules as dict, list and tuple themselves. Because of that, this patch changes pprint.py so that rather than checking types using 'typ is list', pprint checks types using 'issubclass(typ, list)'. Gerrit Holl Patched against latest CVS ( 07/06/2003 13:11:24 UTC) ---------------------------------------------------------------------- >Comment By: Gerrit Holl (gerrit) Date: 2003-06-08 20:06 Message: Logged In: YES user_id=13298 I have changed the patch. Instead of replacing 'typ is list' with 'issubclass(typ, list)', it is now replaced with 'issubclass(typ, list) and typ.__repr__ is typ.__list__'. This way, classes overriding __repr__ keep the current behaviour and classes that don't get the new behaviour. See also the thread on python-dev. BTW, I also expanded 2 of the 3 assert statements, so they explain what's wrong is somethings wrong. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 20:49 Message: Logged In: YES user_id=21627 I have reverted the patch on Fred's request. The patch does not support an overridden __repr__ implementation, and thus has to be rejected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 20:31 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as pprint.py 1.25. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-07 20:30 Message: Logged In: YES user_id=3066 >From python-dev: http://mail.python.org/pipermail/python-dev/2003-June/036008.html Hmm; this patch was never assigned to me, so I was unaware that anyone thought there was a problem with this. I specifically considered making changes like these when subclassing built-in types became possible, but decided against it since it didn't appear reasonable to assume that __repr__() hadn't been redefined. I'm sure it's possible to check, but to do so cleanly and efficiently seems like a huge change to the module for little value. I think the patch, as it stands, should be reverted. If another patch appears that addresses the issue of overridden __repr__() methods, it should be considered again. -1 for the patch as applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 From noreply@sourceforge.net Sun Jun 8 21:08:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 13:08:39 -0700 Subject: [Patches] [ python-Patches-751031 ] imghdr -- identify JPEGs in EXIF format Message-ID: Patches item #751031, was opened at 2003-06-08 14:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751031&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: imghdr -- identify JPEGs in EXIF format Initial Comment: Someone posted to c.l.py [1] about some of their JPEGs not being identified as such by imghdr. Turns out they were EXIF files, and imghdr only identifies JFIF files. A little web research suggests EXIF is the usual format for JPEGS from digital cameras. The patch adds the ability to identify such files; they are reported as 'jpeg-exif'. I've no idea whether this is the Right Thing. [1] http://groups.google.com/groups?th=45c0442a1d74e9c4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751031&group_id=5470 From noreply@sourceforge.net Sun Jun 8 21:10:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 13:10:27 -0700 Subject: [Patches] [ python-Patches-751031 ] imghdr -- identify JPEGs in EXIF format Message-ID: Patches item #751031, was opened at 2003-06-08 14:08 Message generated for change (Settings changed) made by staschuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751031&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None >Priority: 1 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: imghdr -- identify JPEGs in EXIF format Initial Comment: Someone posted to c.l.py [1] about some of their JPEGs not being identified as such by imghdr. Turns out they were EXIF files, and imghdr only identifies JFIF files. A little web research suggests EXIF is the usual format for JPEGS from digital cameras. The patch adds the ability to identify such files; they are reported as 'jpeg-exif'. I've no idea whether this is the Right Thing. [1] http://groups.google.com/groups?th=45c0442a1d74e9c4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751031&group_id=5470 From noreply@sourceforge.net Sun Jun 8 21:28:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 13:28:30 -0700 Subject: [Patches] [ python-Patches-751038 ] Bug fix 750092: exec doesn't need newline Message-ID: Patches item #751038, was opened at 2003-06-08 14:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751038&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Bug fix 750092: exec doesn't need newline Initial Comment: See bug 750092. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751038&group_id=5470 From noreply@sourceforge.net Sun Jun 8 22:33:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 14:33:37 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-25 20:09 Message generated for change (Comment added) made by djohnanderson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Jeremy Hylton (jhylton) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- >Comment By: John Anderson (djohnanderson) Date: 2003-06-08 14:33 Message: Logged In: YES user_id=618290 I just got the 7.1 version of the microsoft compiler and read over the code jhylton submitted and it looks like there is a problem with get_msvc_paths, which hard codes the registry path: ..\7.0\VC\VC_OBJECTS_PLATFORM_INFO\Win32\Directories it needs to be: ..\7.1\VC\VC_OBJECTS_PLATFORM_INFO\Win32\Directories for the 7.1 compiler. Although, there may be other problems with 7.1, I suspect they are minor, so it would probably be pretty easy to include minor changes to support 7.1 ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 09:07 Message: Logged In: YES user_id=31392 Applied variant as rev 1.54 of msvccompiler.py. Tested with MSVC 7 for 2.3 and MSVC6 for 2.2 and 2.3. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-01 15:44 Message: Logged In: YES user_id=31392 I ran into this problem today, so I think I'll spend some time to fix it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-06 09:34 Message: Logged In: YES user_id=31435 Nobody at PLabs has MSVC7, nor time to work on this even if we did. So it would require people outside of PLabs to do all the work. Incompatibility with MSCV6 needs to be addressed too, as I doubt Guido would be willing to say that anyone with an extension module on Windows *has* to use MSVC7 if they want their extension to run with Python 2.3. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 08:37 Message: Logged In: YES user_id=11105 I want to support John's comment about MSVC 7. Not that I like it, but I'm forced to to use it. Seriously, what would be required to release the (official) 2.3 Python windows build with MSVC7? ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-12-06 08:03 Message: Logged In: YES user_id=618290 I think Tim's change which makes it possible to correctly identify the compiler used to build Python makes a lot of sense. So I'm happy to include this in the patch. I'll also remove the Alpha code. I will test it with the version 6 and 7 compilers using python 2.3. I'm very busy these days so it may take me awhile. On a slightly different subject, I think you guys should consider switching over to the version 7 compiler. Version 6 is over 6 years old. The version 7 compiler is nearly a year old and a new version is on the horizon. Since I've been building Python with the version 7 compiler I've identified and f ixed the few problems necessary to get it to work and would be happy to provide Version 7 project files. This would make it easy for people to use either compiler, which in turn would make it easier for you to eventually make the transition to a newer compiler. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-06 01:56 Message: Logged In: YES user_id=21627 John, given Tim's recent changes: Are you willing to revise your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-11 11:38 Message: Logged In: YES user_id=31435 Martin, assuming the tests pass, I'm about to check in a change so that, under 2.3, >>> import sys >>> sys.version '2.3a0 (#29, Nov 11 2002, 14:23:17) [MSC v.1200 32 bit (Intel)] >>> under MSVC 6. Also gets rid of the _M_ALPHA code. Those are good changes regardless of the fate of the issue here, but at least poor John won't have to figure out how to trick the preprocessor into stringizing the value of _MSC_VER (that's not easy, alas). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 09:07 Message: Logged In: YES user_id=21627 The typical distutils user does use a Python binary compiled by somebody else, and may have multiple MSVC versions installed, or may have the wrong version installed. I was hoping that you can find the MSVC version from sys.version, but that only tells you that it is MSC (or that it isn't). I would suggest to modify the compiler identification in sys.version to include the MSC version. Perhaps we could eliminate the identification of Win32-Alpha at the same time. IOW, the compiler string should read [MSC v.12 32 bit] or perhaps v.1200 if that makes it easier. Then, distutils should look into sys.version for the compiler revision, and assume v.1200 (i.e. MSVC6) if no version indication is found. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-11-11 08:19 Message: Logged In: YES user_id=618290 I'm a bit confused by the question. On my computer, I installed the current Microsoft compiler (7.0), compiled Python, installed distutils with my patch, and built several extensions. So distutils did use the same compiler as was used to build Python. If you want to use the same compiler that someone else built Python with, then you'll need to get the same compiler they used, to make sure it's the only version that's installed, and distutils works fine. Perhaps you mean that there is some way to determine which compiler was used by Python from examining something in Python itself. If this is possible, please let me know how to do it. In this case I'd propose modifying the patch to write out of warning when a different compiler was used to run distutils than was used to compile Python. In the case of the Microsoft compiler not all versions have been incompatible. Or perhaps you mean distutils should have a generalized way to specify which version of compiler to use when more than one is installed on your computer. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 07:09 Message: Logged In: YES user_id=21627 It seems clear that the patch is unacceptable in its current form: distutils *must* use the compiler that was used to compile Python. Would you be willing to revise your patch in that direction? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-16 01:50 Message: Logged In: YES user_id=11105 It seems Martin is correct. I made the following experiment: Compile pythoncore, python and pythonw with MSVC7, and the remaining extension modules with MSVC6 (all, except bsddb and _tkinter). Now the test-suite crashes hard in test_parser. When everything is built with MSVC7, the test-suite runs fine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 01:20 Message: Logged In: YES user_id=21627 The biggest problem is that VC.NET uses a new C library, msvcr70[d].dll. I have not fully studied all issues, but it appears that, for purposes of Python, you cannot mix extensions, atleast not in the general case. In particular, you cannot pass FILE* between both C libraries. This is particularly annoying, since MS has managed that struct _iobuf (aka FILE) has identical layout in both compilers. Nevertheless, it crashes in the following scenario: VC7:fopen VC: fputs The problem is that fputs wants to lock the file. For that, it tests whether the pointer comes from its own _iob (_file.c:_lock_file). If the pointer comes from the _iob of the other C library, it concludes that this must be a _FILEX (which it isn't), and crashes :-( So it appears that one *must* build extension modules with the Visual Studio that also has built Python. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-15 14:01 Message: Logged In: YES user_id=31435 Thomas, I'm just curious here: if we were to create the Windows Python distribution with VC7, would the DLLs be compatible with extensions compiled by VC6? In return for your answer to that , here's how to determine your MSVC6 service pack level: HKLM\ SOFTWARE\ Microsoft\ VisualStudio\ 6.0\ ServicePacks and look at key "latest". ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-15 10:13 Message: Logged In: YES user_id=11105 I've tried out the patch, and it works for me, at least with simple extensions - both with MSVC 6 and with MSVC 7, freshly installed. I don't know the service pack level of my MSVC6, Help- >About doesn't show it. I'm not sure if using 7.0 (if available) should be the default. Python itself is still built with MSVC6 AFAIK. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-08 08:51 Message: Logged In: YES user_id=618290 Thanks Martin for taking the time to review my proposed changes. I think your comments about looking in Software\Microsoft\VisualStudio instead of Software\Microsoft\DevStudio is a good point. I decided to two look only in VisualStudio because that works for both the version 6 and 7 compiler I tested with. I don't know if the version 5 compiler also stores the version in DevStudio. Another alternative, which would of course complicate code, would be two look in both places and choose the highest version. Let me know if that's what you'd prefer and I'll upload a new patch. The problem I'm having with the version 6 compiler (latest service Pack 5) is that SOFTWARE\Microsoft\Devstudio\6.0\Build System\ doesn't exist. Instead it looks like it's been moved to SOFTWARE\Microsoft\Shared Tools\Build System\, but in that new location, SOFTWARE\Microsoft\Shared Tools\Build System\Components\Platforms\Win32 (x86)\Directories doesn't exist. This has the effect of not getting the correct include directories for builds. This also points out a serious flaw in looking at undocumented registry entries to find information for the build -- there's no guarantee that the registry information won't change even within the same version of the compiler. I don't have a good solution for this problem, but I'd rather distutils reported an error when it couldn't find the registry entries it expected -- rather than silently ignoring it as it does now. In a few places I added code to report unexpected missing registry entries, but not all. I could if you're interested add error code in all cases. Fixing the problem I'm having with the version 6 compiler seems difficult, since it seems to work for you and doesn't work for me -- apparently are registries are different. Personally I'm content with leaving the version 6 compiler broken since it isn't obvious how to fix it and it apparently works for some people and I only intend to use the version 7 or newer compilers. I added three new functions: convert_mbcs, read_key, and by far the largest: expand_macros. The first two make the code simpler, easier to read, avoid unnecessary duplications, and minimize the risk that someone would forget to deal with mbcs. It would be difficult to understand the bug fix without these two functions. My hope was that these changes would make it easier for the next person who needs to learn the code. The last, expand_macros, is necessary because the version 7 compiler introduces macros which didn't exist in previous versions of the compiler. It would be awkward to implement the macros without having adding a new function. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 02:21 Message: Logged In: YES user_id=21627 I'm asking because you are not looking into Software\Microsoft\Devstudio anymore to find the most recent version. Not supporting MSVC5 anymore is probably acceptable. I never noticed that support for MSVC6 is broken - it works fine for me... However, if you think you can improve that somehow, please do - please elaborate what changes solve what problems, though. It seems that a number of changes are not strictly necessary (e.g. creation of new functions), to really evaluate the patch, I have to know why you propose these changes. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-07 08:27 Message: Logged In: YES user_id=618290 It's been so long since I had a copy of MSVC 5 -- I think it became obsolete about 6 or 7 years ago. None of my changes should have any impact on the operation of MSVC 5, but of course you never know unless you try it. Also, the MSVC 6 support in distutils is currently broken -- although it finds the compiler, the code to find the include paths is totally broken. I have MSVC 6 (latest service pack) and 7 and would be willing to make both those work. Anyone who's using 5 is going to have lots of other problems to deal with besides distutils. Wouldn't surprise me if the MSVC 6 code for finding paths would differ in each service pack -- since it depends upon unsupported registry entries. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 04:43 Message: Logged In: YES user_id=21627 Can you report whether this patch works with MSVC 5? ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 14:38 Message: Logged In: YES user_id=618290 Opps, I guess I forgot to check that little box. Sorry about that. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 14:38 Message: Logged In: YES user_id=618290 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-25 21:30 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=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Sun Jun 8 22:49:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 14:49:27 -0700 Subject: [Patches] [ python-Patches-751062 ] Tutorial: remove string exceptions, add parnassus, #posts Message-ID: Patches item #751062, was opened at 2003-06-08 21:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751062&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial: remove string exceptions, add parnassus, #posts Initial Comment: This patch, agains latest CVS, changes three things in the tutorial: The subsection "Exceptions Can Be Classes" is removed: Exceptions _should_ be classes, and the described behaviour is also documented elsewhere: since string exceptions are deprecated, they should not be mentioned in the tutorial because new users will never use them and it is very improbable that they will ever encounter them. The tutorial states that c.l.py receives "around 120 messages" a day. A note is added that there are peaks with up to several hundreds of postings (i.e. pep-308). The tutorial mentions www.python.org and starship.python.net. I have added a link to parnassus, because every Python user should know about its existence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751062&group_id=5470 From noreply@sourceforge.net Mon Jun 9 00:06:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 16:06:17 -0700 Subject: [Patches] [ python-Patches-750542 ] Let pprint.py use issubclass instead of is for type checking Message-ID: Patches item #750542, was opened at 2003-06-07 15:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Rejected Priority: 5 Submitted By: Gerrit Holl (gerrit) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Let pprint.py use issubclass instead of is for type checking Initial Comment: Hi, subclasses of dict, list, tuple etc. should be pretty-printed according to the same rules as dict, list and tuple themselves. Because of that, this patch changes pprint.py so that rather than checking types using 'typ is list', pprint checks types using 'issubclass(typ, list)'. Gerrit Holl Patched against latest CVS ( 07/06/2003 13:11:24 UTC) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-09 01:06 Message: Logged In: YES user_id=21627 Assigning to Fred. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-06-08 22:06 Message: Logged In: YES user_id=13298 I have changed the patch. Instead of replacing 'typ is list' with 'issubclass(typ, list)', it is now replaced with 'issubclass(typ, list) and typ.__repr__ is typ.__list__'. This way, classes overriding __repr__ keep the current behaviour and classes that don't get the new behaviour. See also the thread on python-dev. BTW, I also expanded 2 of the 3 assert statements, so they explain what's wrong is somethings wrong. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 22:49 Message: Logged In: YES user_id=21627 I have reverted the patch on Fred's request. The patch does not support an overridden __repr__ implementation, and thus has to be rejected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-07 22:31 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as pprint.py 1.25. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-07 22:30 Message: Logged In: YES user_id=3066 >From python-dev: http://mail.python.org/pipermail/python-dev/2003-June/036008.html Hmm; this patch was never assigned to me, so I was unaware that anyone thought there was a problem with this. I specifically considered making changes like these when subclassing built-in types became possible, but decided against it since it didn't appear reasonable to assume that __repr__() hadn't been redefined. I'm sure it's possible to check, but to do so cleanly and efficiently seems like a huge change to the module for little value. I think the patch, as it stands, should be reverted. If another patch appears that addresses the issue of overridden __repr__() methods, it should be considered again. -1 for the patch as applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 From noreply@sourceforge.net Mon Jun 9 01:57:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 17:57:40 -0700 Subject: [Patches] [ python-Patches-751107 ] Wrong constant in tkFont module Message-ID: Patches item #751107, was opened at 2003-06-09 00:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751107&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pedro Werneck (pedrowerneck) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong constant in tkFont module Initial Comment: Both constant and docstring on the tkFont module have wrong value for non-italic font, "normal", instead of "roman"... using the NORMAL constant as documented raises a "TclError: bad -slant value "normal": must be roman, or italic". This patch correct both constant and docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751107&group_id=5470 From noreply@sourceforge.net Mon Jun 9 02:36:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 18:36:28 -0700 Subject: [Patches] [ python-Patches-751113 ] fix memory leaks in _csv Message-ID: Patches item #751113, was opened at 2003-06-08 21:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751113&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Skip Montanaro (montanaro) Summary: fix memory leaks in _csv Initial Comment: Skip, I sent a message to the CSV mailling list, but I don't know if it got there. This is the same patch (I think). It fixes some memory leaks. If anyone else familiar with CSV would like to review this patch, that would be great too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751113&group_id=5470 From noreply@sourceforge.net Mon Jun 9 02:39:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 18:39:09 -0700 Subject: [Patches] [ python-Patches-751114 ] fix memory leaks in posixmodule on Windows Message-ID: Patches item #751114, was opened at 2003-06-08 21:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751114&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: fix memory leaks in posixmodule on Windows Initial Comment: The attached patch should fix memory leaks from os.listdir() on Windows. I can't test this, but it appears that bufptr was leaked in most circumstances. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751114&group_id=5470 From noreply@sourceforge.net Mon Jun 9 03:49:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 19:49:28 -0700 Subject: [Patches] [ python-Patches-751113 ] fix memory leaks in _csv Message-ID: Patches item #751113, was opened at 2003-06-08 20:36 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751113&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Andrew McNamara (andrewmcnamara) Summary: fix memory leaks in _csv Initial Comment: Skip, I sent a message to the CSV mailling list, but I don't know if it got there. This is the same patch (I think). It fixes some memory leaks. If anyone else familiar with CSV would like to review this patch, that would be great too. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-06-08 21:49 Message: Logged In: YES user_id=44345 Assigning to Andrew since he knows the _csv module much better than I do. Andrew, if you can't get to it soon, please assign it back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751113&group_id=5470 From noreply@sourceforge.net Mon Jun 9 07:06:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 08 Jun 2003 23:06:52 -0700 Subject: [Patches] [ python-Patches-751113 ] fix memory leaks in _csv Message-ID: Patches item #751113, was opened at 2003-06-09 11:36 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751113&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Andrew McNamara (andrewmcnamara) Summary: fix memory leaks in _csv Initial Comment: Skip, I sent a message to the CSV mailling list, but I don't know if it got there. This is the same patch (I think). It fixes some memory leaks. If anyone else familiar with CSV would like to review this patch, that would be great too. ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2003-06-09 16:06 Message: Logged In: YES user_id=698599 Applied. I don't think the first and third stanzas in the patch are actual leaks, since the *size variable is initialised at the same time as the pointer variable (if one is zero, they both should be zero), but making your changes is safer in the long run. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-06-09 12:49 Message: Logged In: YES user_id=44345 Assigning to Andrew since he knows the _csv module much better than I do. Andrew, if you can't get to it soon, please assign it back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751113&group_id=5470 From noreply@sourceforge.net Mon Jun 9 17:05:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 09 Jun 2003 09:05:21 -0700 Subject: [Patches] [ python-Patches-711448 ] Warn about inter-module assignments shadowing builtins Message-ID: Patches item #711448, was opened at 2003-03-28 12:12 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Warn about inter-module assignments shadowing builtins Initial Comment: The attached patch modifies module tp_setattro to warn about code that adds a name to the globals of another module that shadows a builtin. Unfortunately, there are other ways to modify module globals (e.g. using vars() and mutating the dictionary). There are a few issues with module objects that I'm not clear about. For example, do modules always have a md_dict that is a PyDictObject? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-09 12:05 Message: Logged In: YES user_id=6380 Looks good to me. One nit: PyEval_GetBuiltins() doesn't ever return NULL, but it if were to return NULL, it wouldn't set an exception. In that case the assumption would be made by the code that an exception was set. Perhaps you can combine this with a typecheck on the return, so that you write e.g. if (builtins == NULL || !PyDict_Check(builtins)) { PyErr_SetString(PyExc_SystemError, "no builtins directory?!?!"); return NULL; } ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-06-07 19:06 Message: Logged In: YES user_id=35752 Here's a new version that uses PyEval_GetBuiltins() to get the builtin module dict and then builds a set of builtin names from that. Is using PyEval_GetBuiltins() safe? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-20 17:20 Message: Logged In: YES user_id=6380 The basic idea of the patch is sound. Why can't you check whether the name is in __builtin__.__dict__ ? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-04-20 12:17 Message: Logged In: YES user_id=35752 Is it okay if I move the list to the bltinmodule as a non-static variable? That would make it easier for the compiler to use the list if or when it was changed to optimize builtin lookup. Also, is the basic idea of this patch sound? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 15:01 Message: Logged In: YES user_id=6380 Hm, it's kind of ugly to list all built-in names explicitly; this list will be out of sync whenever a new built-in is added. Can't you access the __builtin__ module and use its keys? (One way to get the __builtin__ module is to use PySys_GetObject("modules"), which should give you sys.modules, and take it from there; you can count on __builtin__ to be there, and if it's not, forget the whole thing.) ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-03-28 12:15 Message: Logged In: YES user_id=35752 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 From noreply@sourceforge.net Mon Jun 9 17:33:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 09 Jun 2003 09:33:17 -0700 Subject: [Patches] [ python-Patches-621891 ] tkFileDialog multiple option Message-ID: Patches item #621891, was opened at 2002-10-11 10:04 Message generated for change (Comment added) made by s014djs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Nobody/Anonymous (nobody) Summary: tkFileDialog multiple option Initial Comment: In tk8.4 tk_getOpenFile and tk_getSaveFile dialogs used by tkFileDialog.py now allow the multiple option on all platforms, according to the docs... I have only tested in Linux (RedHat 7.2) python 2.2.1 and tk 8.4 This patch adds two new functions to the tkFileDialog module askopenfilenames() and askopenfiles() the function doc strings explain what they do... I've uploaded a diff. ---------------------------------------------------------------------- Comment By: Deacon Sweeney (s014djs) Date: 2003-06-09 12:33 Message: Logged In: YES user_id=797021 This didn't really work for me. The problem is in tkCommonDialog.py, in the Dialog.show(). The first try is not set up to handle the list that gets returned by the multiple option. Here's a fix: replace the stuff in that try (a call command, followed by a _fixresult command, with the following: [start snip] t = w.tk.call(self.command, *w._options (self.options)) # for the special case of multiple file selection, # return a list, instead of a singleton for i, j in self.options.items(): if i == 'multiple' and self.command == 'tk_getOpenFile': s = [] for m in t: s.append(self._fixresult(w, m)) break else: s = self._fixresult(w, t) [end snip] Its only set up to handle stuff from tk_getOpenFile commands, but would provide a framework for solving other problems as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-14 07:56 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as tkFileDialog.py 1.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 From noreply@sourceforge.net Mon Jun 9 17:42:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 09 Jun 2003 09:42:28 -0700 Subject: [Patches] [ python-Patches-744104 ] Remove eval() from csv Message-ID: Patches item #744104, was opened at 2003-05-27 02:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Andrew McNamara (andrewmcnamara) Summary: Remove eval() from csv Initial Comment: The eval() step in the csv module can be eliminated, resulting in better security, more clarity, and a little speed. The idea is to make successive attempts to coerce the string to a python type: int(s), long(s), float(s), etc. This allows the logic to be controlled precisely and for specific types to be included or excluded (unicode types for instance). The patch is attached and passes all regression tests. It should also work fine under Py2.2. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-09 11:42 Message: Logged In: YES user_id=80475 Skip said it would be fine if you took care of this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 From noreply@sourceforge.net Mon Jun 9 17:51:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 09 Jun 2003 09:51:54 -0700 Subject: [Patches] [ python-Patches-621891 ] tkFileDialog multiple option Message-ID: Patches item #621891, was opened at 2002-10-11 16:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Nobody/Anonymous (nobody) Summary: tkFileDialog multiple option Initial Comment: In tk8.4 tk_getOpenFile and tk_getSaveFile dialogs used by tkFileDialog.py now allow the multiple option on all platforms, according to the docs... I have only tested in Linux (RedHat 7.2) python 2.2.1 and tk 8.4 This patch adds two new functions to the tkFileDialog module askopenfilenames() and askopenfiles() the function doc strings explain what they do... I've uploaded a diff. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-09 18:51 Message: Logged In: YES user_id=21627 Are you trying to report some bug? If so, what bug? I.e. what is your source code, what is the expected behaviour, what is the observed behaviour? ---------------------------------------------------------------------- Comment By: Deacon Sweeney (s014djs) Date: 2003-06-09 18:33 Message: Logged In: YES user_id=797021 This didn't really work for me. The problem is in tkCommonDialog.py, in the Dialog.show(). The first try is not set up to handle the list that gets returned by the multiple option. Here's a fix: replace the stuff in that try (a call command, followed by a _fixresult command, with the following: [start snip] t = w.tk.call(self.command, *w._options (self.options)) # for the special case of multiple file selection, # return a list, instead of a singleton for i, j in self.options.items(): if i == 'multiple' and self.command == 'tk_getOpenFile': s = [] for m in t: s.append(self._fixresult(w, m)) break else: s = self._fixresult(w, t) [end snip] Its only set up to handle stuff from tk_getOpenFile commands, but would provide a framework for solving other problems as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-14 13:56 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as tkFileDialog.py 1.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 From noreply@sourceforge.net Mon Jun 9 19:37:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 09 Jun 2003 11:37:51 -0700 Subject: [Patches] [ python-Patches-621891 ] tkFileDialog multiple option Message-ID: Patches item #621891, was opened at 2002-10-11 10:04 Message generated for change (Comment added) made by s014djs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Nobody/Anonymous (nobody) Summary: tkFileDialog multiple option Initial Comment: In tk8.4 tk_getOpenFile and tk_getSaveFile dialogs used by tkFileDialog.py now allow the multiple option on all platforms, according to the docs... I have only tested in Linux (RedHat 7.2) python 2.2.1 and tk 8.4 This patch adds two new functions to the tkFileDialog module askopenfilenames() and askopenfiles() the function doc strings explain what they do... I've uploaded a diff. ---------------------------------------------------------------------- Comment By: Deacon Sweeney (s014djs) Date: 2003-06-09 14:37 Message: Logged In: YES user_id=797021 I encountered this bug running Python2.3 beta, on Windows XP. The reported patch (621891 tkFileDialog multiple option) is supposed to return a list of file names upon selection of multiple files in the askopenfilenames function of the tkFileDialog module. It fails, mentioning some bug about concatenating a string with a tuple, if I remember correctly. So I fixed it on my machine. I haven't studied the whole system to know what other fuctions call the show function, but I specified the fix for the tk_getOpenFile command with the 'multiple' option, so it shouldn't fail for any other cases. I need this option for the software I'm developing, but am new to this development forum. Is there anything else I can do to help get this fixed for the Python 2.3 release? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-09 12:51 Message: Logged In: YES user_id=21627 Are you trying to report some bug? If so, what bug? I.e. what is your source code, what is the expected behaviour, what is the observed behaviour? ---------------------------------------------------------------------- Comment By: Deacon Sweeney (s014djs) Date: 2003-06-09 12:33 Message: Logged In: YES user_id=797021 This didn't really work for me. The problem is in tkCommonDialog.py, in the Dialog.show(). The first try is not set up to handle the list that gets returned by the multiple option. Here's a fix: replace the stuff in that try (a call command, followed by a _fixresult command, with the following: [start snip] t = w.tk.call(self.command, *w._options (self.options)) # for the special case of multiple file selection, # return a list, instead of a singleton for i, j in self.options.items(): if i == 'multiple' and self.command == 'tk_getOpenFile': s = [] for m in t: s.append(self._fixresult(w, m)) break else: s = self._fixresult(w, t) [end snip] Its only set up to handle stuff from tk_getOpenFile commands, but would provide a framework for solving other problems as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-14 07:56 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as tkFileDialog.py 1.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 From noreply@sourceforge.net Mon Jun 9 20:16:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 09 Jun 2003 12:16:37 -0700 Subject: [Patches] [ python-Patches-711448 ] Warn about inter-module assignments shadowing builtins Message-ID: Patches item #711448, was opened at 2003-03-28 17:12 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Warn about inter-module assignments shadowing builtins Initial Comment: The attached patch modifies module tp_setattro to warn about code that adds a name to the globals of another module that shadows a builtin. Unfortunately, there are other ways to modify module globals (e.g. using vars() and mutating the dictionary). There are a few issues with module objects that I'm not clear about. For example, do modules always have a md_dict that is a PyDictObject? ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-06-09 19:16 Message: Logged In: YES user_id=35752 Commited as moduleobject.c 2.46 (with nit fixed). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-09 16:05 Message: Logged In: YES user_id=6380 Looks good to me. One nit: PyEval_GetBuiltins() doesn't ever return NULL, but it if were to return NULL, it wouldn't set an exception. In that case the assumption would be made by the code that an exception was set. Perhaps you can combine this with a typecheck on the return, so that you write e.g. if (builtins == NULL || !PyDict_Check(builtins)) { PyErr_SetString(PyExc_SystemError, "no builtins directory?!?!"); return NULL; } ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-06-07 23:06 Message: Logged In: YES user_id=35752 Here's a new version that uses PyEval_GetBuiltins() to get the builtin module dict and then builds a set of builtin names from that. Is using PyEval_GetBuiltins() safe? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-20 21:20 Message: Logged In: YES user_id=6380 The basic idea of the patch is sound. Why can't you check whether the name is in __builtin__.__dict__ ? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-04-20 16:17 Message: Logged In: YES user_id=35752 Is it okay if I move the list to the bltinmodule as a non-static variable? That would make it easier for the compiler to use the list if or when it was changed to optimize builtin lookup. Also, is the basic idea of this patch sound? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 19:01 Message: Logged In: YES user_id=6380 Hm, it's kind of ugly to list all built-in names explicitly; this list will be out of sync whenever a new built-in is added. Can't you access the __builtin__ module and use its keys? (One way to get the __builtin__ module is to use PySys_GetObject("modules"), which should give you sys.modules, and take it from there; you can count on __builtin__ to be there, and if it's not, forget the whole thing.) ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-03-28 17:15 Message: Logged In: YES user_id=35752 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 From noreply@sourceforge.net Mon Jun 9 21:35:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 09 Jun 2003 13:35:28 -0700 Subject: [Patches] [ python-Patches-621891 ] tkFileDialog multiple option Message-ID: Patches item #621891, was opened at 2002-10-11 16:04 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 Category: Tkinter Group: Python 2.2.x >Status: Open Resolution: Accepted Priority: 5 Submitted By: Martin Franklin (mfranklin1) >Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog multiple option Initial Comment: In tk8.4 tk_getOpenFile and tk_getSaveFile dialogs used by tkFileDialog.py now allow the multiple option on all platforms, according to the docs... I have only tested in Linux (RedHat 7.2) python 2.2.1 and tk 8.4 This patch adds two new functions to the tkFileDialog module askopenfilenames() and askopenfiles() the function doc strings explain what they do... I've uploaded a diff. ---------------------------------------------------------------------- Comment By: Deacon Sweeney (s014djs) Date: 2003-06-09 20:37 Message: Logged In: YES user_id=797021 I encountered this bug running Python2.3 beta, on Windows XP. The reported patch (621891 tkFileDialog multiple option) is supposed to return a list of file names upon selection of multiple files in the askopenfilenames function of the tkFileDialog module. It fails, mentioning some bug about concatenating a string with a tuple, if I remember correctly. So I fixed it on my machine. I haven't studied the whole system to know what other fuctions call the show function, but I specified the fix for the tk_getOpenFile command with the 'multiple' option, so it shouldn't fail for any other cases. I need this option for the software I'm developing, but am new to this development forum. Is there anything else I can do to help get this fixed for the Python 2.3 release? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-09 18:51 Message: Logged In: YES user_id=21627 Are you trying to report some bug? If so, what bug? I.e. what is your source code, what is the expected behaviour, what is the observed behaviour? ---------------------------------------------------------------------- Comment By: Deacon Sweeney (s014djs) Date: 2003-06-09 18:33 Message: Logged In: YES user_id=797021 This didn't really work for me. The problem is in tkCommonDialog.py, in the Dialog.show(). The first try is not set up to handle the list that gets returned by the multiple option. Here's a fix: replace the stuff in that try (a call command, followed by a _fixresult command, with the following: [start snip] t = w.tk.call(self.command, *w._options (self.options)) # for the special case of multiple file selection, # return a list, instead of a singleton for i, j in self.options.items(): if i == 'multiple' and self.command == 'tk_getOpenFile': s = [] for m in t: s.append(self._fixresult(w, m)) break else: s = self._fixresult(w, t) [end snip] Its only set up to handle stuff from tk_getOpenFile commands, but would provide a framework for solving other problems as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-14 13:56 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as tkFileDialog.py 1.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 From noreply@sourceforge.net Tue Jun 10 14:36:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 10 Jun 2003 06:36:27 -0700 Subject: [Patches] [ python-Patches-751916 ] Handle keyboard interrupts in SSL module Message-ID: Patches item #751916, was opened at 2003-06-10 08:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751916&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Jacobs (jacobs99) Assigned to: Nobody/Anonymous (nobody) Summary: Handle keyboard interrupts in SSL module Initial Comment: As of Python 2.3 beta 1 (and current CVS), the SSL module does not check to see if a keyboard interrupt occurred after waiting on connections, reads, and writes. This results in long delays (seconds or even minutes) before the KeyboardInterrupt is finally raised, causing problematic pauses for interactive processes. This does not happen in Python 2.2.2, though I have not looked into what has changed. My next step is to look into httplib, the use-case that brought this to my attention, since some of the buffering code is not exception safe. i.e., a KeyboardInterrupt can cause data to be lost on subsequent reads. I suspect that it is also possible to lose data on due to socket timeouts as well, so I consider this issue a distinct bug. I did not include a new unit test, since it is a little tricky to produce. It requires a large SSL transfer and a network timing-sensitive threshold test to detect. Also included in the attached patch are some error handling fixes and cleanups related to time-out operations that I happened to notice. This module deserves more attention, since the timeout changes don't look like they were integrated as carefully as they could have been and other similar errors are possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751916&group_id=5470 From noreply@sourceforge.net Tue Jun 10 15:31:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 10 Jun 2003 07:31:38 -0700 Subject: [Patches] [ python-Patches-751943 ] cgitb: make more usable for 'binary-only' software Message-ID: Patches item #751943, was opened at 2003-06-10 14:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751943&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rob W.W. Hooft (hooft) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb: make more usable for 'binary-only' software Initial Comment: I am abusing cgitb to show a traceback window for a GUI application in Qt. In such a case, the source code to the program is not always available. The stack trace is anyway useful to be submitted to the developers of the code. I attach a patch that should add some info to the HTML traceback made by cgitb in case the source file is not available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751943&group_id=5470 From noreply@sourceforge.net Wed Jun 11 16:47:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 11 Jun 2003 08:47:37 -0700 Subject: [Patches] [ python-Patches-752671 ] NetBSD needs to link libintl Message-ID: Patches item #752671, was opened at 2003-06-11 17:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752671&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD needs to link libintl Initial Comment: On NetBSD the libintl.h is found, but the libintl to linked. Therefore the locale module fails to link. The attached patch changes configure.in to check for textdomain in libintl and if it's found it adds libintl to $LIBS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752671&group_id=5470 From noreply@sourceforge.net Wed Jun 11 19:07:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 11 Jun 2003 11:07:26 -0700 Subject: [Patches] [ python-Patches-744104 ] Remove eval() from csv Message-ID: Patches item #744104, was opened at 2003-05-27 02:43 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: Remove eval() from csv Initial Comment: The eval() step in the csv module can be eliminated, resulting in better security, more clarity, and a little speed. The idea is to make successive attempts to coerce the string to a python type: int(s), long(s), float(s), etc. This allows the logic to be controlled precisely and for specific types to be included or excluded (unicode types for instance). The patch is attached and passes all regression tests. It should also work fine under Py2.2. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-09 11:42 Message: Logged In: YES user_id=80475 Skip said it would be fine if you took care of this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 From noreply@sourceforge.net Wed Jun 11 22:08:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 11 Jun 2003 14:08:29 -0700 Subject: [Patches] [ python-Patches-752911 ] ast-branch: multiple function fixes Message-ID: Patches item #752911, was opened at 2003-06-11 16:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752911&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: ast-branch: multiple function fixes Initial Comment: This patch fixes: - handling of keywords, varargs, and kwargs on function definition - handing of keywords, varargs, and kwargs on function call - handling of keywords for lambdas - function chaining (foo().bar().baz()) Applying this uncovers some another bug that at least: - cause a core dump upon import of sre_parse - cause an infinate loop upon import of ntpath I believe I've tracked down the problem to the generation of bad bytecode for nested loops, as in: for x in 1,2: for y in 3,4: print x,y This causes problems with Subpattern.dump() in sre_parse and ntpath's commonprefix(). I'll try to figure out what's wrong with nested loops next. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752911&group_id=5470 From noreply@sourceforge.net Thu Jun 12 03:26:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 11 Jun 2003 19:26:32 -0700 Subject: [Patches] [ python-Patches-744104 ] Remove eval() from csv Message-ID: Patches item #744104, was opened at 2003-05-27 02:43 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: Remove eval() from csv Initial Comment: The eval() step in the csv module can be eliminated, resulting in better security, more clarity, and a little speed. The idea is to make successive attempts to coerce the string to a python type: int(s), long(s), float(s), etc. This allows the logic to be controlled precisely and for specific types to be included or excluded (unicode types for instance). The patch is attached and passes all regression tests. It should also work fine under Py2.2. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-06-11 21:26 Message: Logged In: YES user_id=44345 I think this is fine though there's a typo: # treat longs as ints if thisType == long: thisType == int The last "==" should be "=". That this didn't trigger a test failure suggests we need another test case. Also, since the interpreter can conceivably be built without complex types, the use of the complex builtin should probably be guarded. S ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-09 11:42 Message: Logged In: YES user_id=80475 Skip said it would be fine if you took care of this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 From noreply@sourceforge.net Thu Jun 12 04:10:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 11 Jun 2003 20:10:31 -0700 Subject: [Patches] [ python-Patches-744104 ] Remove eval() from csv Message-ID: Patches item #744104, was opened at 2003-05-27 02:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: Remove eval() from csv Initial Comment: The eval() step in the csv module can be eliminated, resulting in better security, more clarity, and a little speed. The idea is to make successive attempts to coerce the string to a python type: int(s), long(s), float(s), etc. This allows the logic to be controlled precisely and for specific types to be included or excluded (unicode types for instance). The patch is attached and passes all regression tests. It should also work fine under Py2.2. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-11 22:10 Message: Logged In: YES user_id=80475 * Added guard for complex(). * Changed == to = * Ran against Skip's new tests * Committed as Lib/csv.py 1.5 * Closing patch ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-06-11 21:26 Message: Logged In: YES user_id=44345 I think this is fine though there's a typo: # treat longs as ints if thisType == long: thisType == int The last "==" should be "=". That this didn't trigger a test failure suggests we need another test case. Also, since the interpreter can conceivably be built without complex types, the use of the complex builtin should probably be guarded. S ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-09 11:42 Message: Logged In: YES user_id=80475 Skip said it would be fine if you took care of this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 From noreply@sourceforge.net Thu Jun 12 04:10:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 11 Jun 2003 20:10:32 -0700 Subject: [Patches] [ python-Patches-744104 ] Remove eval() from csv Message-ID: Patches item #744104, was opened at 2003-05-27 02:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: Remove eval() from csv Initial Comment: The eval() step in the csv module can be eliminated, resulting in better security, more clarity, and a little speed. The idea is to make successive attempts to coerce the string to a python type: int(s), long(s), float(s), etc. This allows the logic to be controlled precisely and for specific types to be included or excluded (unicode types for instance). The patch is attached and passes all regression tests. It should also work fine under Py2.2. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-11 22:10 Message: Logged In: YES user_id=80475 * Added guard for complex(). * Changed == to = * Ran against Skip's new tests * Committed as Lib/csv.py 1.5 * Closing patch ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-11 22:10 Message: Logged In: YES user_id=80475 * Added guard for complex(). * Changed == to = * Ran against Skip's new tests * Committed as Lib/csv.py 1.5 * Closing patch ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-06-11 21:26 Message: Logged In: YES user_id=44345 I think this is fine though there's a typo: # treat longs as ints if thisType == long: thisType == int The last "==" should be "=". That this didn't trigger a test failure suggests we need another test case. Also, since the interpreter can conceivably be built without complex types, the use of the complex builtin should probably be guarded. S ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-09 11:42 Message: Logged In: YES user_id=80475 Skip said it would be fine if you took care of this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 From noreply@sourceforge.net Fri Jun 13 05:56:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 12 Jun 2003 21:56:56 -0700 Subject: [Patches] [ python-Patches-753733 ] sys.interrupt_main() Message-ID: Patches item #753733, was opened at 2003-06-12 23:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753733&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: sys.interrupt_main() Initial Comment: Patch implements this function. Needed for interrupting IDLE subprocess when running on win32. Better here than in a separate module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753733&group_id=5470 From noreply@sourceforge.net Fri Jun 13 06:05:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 12 Jun 2003 22:05:33 -0700 Subject: [Patches] [ python-Patches-753733 ] sys.interrupt_main() Message-ID: Patches item #753733, was opened at 2003-06-12 23:56 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753733&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: sys.interrupt_main() Initial Comment: Patch implements this function. Needed for interrupting IDLE subprocess when running on win32. Better here than in a separate module. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-06-13 00:05 Message: Logged In: YES user_id=149084 Urm, check the box! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753733&group_id=5470 From noreply@sourceforge.net Fri Jun 13 10:43:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 02:43:50 -0700 Subject: [Patches] [ python-Patches-753845 ] Update README for Redhat 9 Tkinter compile with USC-4 Message-ID: Patches item #753845, was opened at 2003-06-13 11:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753845&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Update README for Redhat 9 Tkinter compile with USC-4 Initial Comment: This patch updates the README to describe a workaround to the problem described in SF#719880, http://mail.python.org/pipermail/python-dev/2003-April/034724.html and http://mail.python.org/pipermail/python-dev/2003-June/036277.html. It was about --enable-unicode=ucs4 and having to remove the build/ directory. It also adds to the Redhat-Python-1.5.2 note that this is only true for old Redhat systems (I think <8, but I'm not sure so I didn't add the detail). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753845&group_id=5470 From noreply@sourceforge.net Fri Jun 13 13:03:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 05:03:21 -0700 Subject: [Patches] [ python-Patches-753733 ] sys.interrupt_main() Message-ID: Patches item #753733, was opened at 2003-06-13 00:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753733&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) >Assigned to: Kurt B. Kaiser (kbk) Summary: sys.interrupt_main() Initial Comment: Patch implements this function. Needed for interrupting IDLE subprocess when running on win32. Better here than in a separate module. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-13 08:03 Message: Logged In: YES user_id=33168 One thing that should be changed is METH_VARARGS should be METH_NOARGS (this problem was in the original code). The sys doc should be updated (Doc/lib/libsys.tex) to mention interupt*(). Probably a NEWS entry should be made too. Otherwise the patch is fine, but I didn't see a resolution on changing the name to interupt vs interupt_main. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-06-13 01:05 Message: Logged In: YES user_id=149084 Urm, check the box! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753733&group_id=5470 From noreply@sourceforge.net Fri Jun 13 15:54:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 07:54:31 -0700 Subject: [Patches] [ python-Patches-754004 ] incorrect release year in PEP 251 Message-ID: Patches item #754004, was opened at 2003-06-13 16:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754004&group_id=5470 Category: None Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect release year in PEP 251 Initial Comment: PEP 251 states that Python 2.2a3 was released on 7-Sep-1001, 1000 years after 2.2a2 and 1000 years before 2.2a3. This seems unlikely; this patch reverses the time leap and puts Python 2.2a3 back in the 21st century. BTW, no Category seem appropiate; is that because it's in the nondist/ dir? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754004&group_id=5470 From noreply@sourceforge.net Fri Jun 13 16:25:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 08:25:03 -0700 Subject: [Patches] [ python-Patches-754022 ] Enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 19:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply@sourceforge.net Fri Jun 13 16:26:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 08:26:41 -0700 Subject: [Patches] [ python-Patches-754022 ] Enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 19:24 Message generated for change (Settings changed) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None >Priority: 4 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply@sourceforge.net Fri Jun 13 20:27:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 12:27:12 -0700 Subject: [Patches] [ python-Patches-707900 ] bug fix 702858: deepcopying reflexive objects Message-ID: Patches item #707900, was opened at 2003-03-21 23:08 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707900&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Guido van Rossum (gvanrossum) Summary: bug fix 702858: deepcopying reflexive objects Initial Comment: A fix for bug 702858, which concerns the inability of copy.deepcopy to correctly process reflexive new-style class instances, that is, instances referring to themselves. The fix is one line; the other 51 lines in the patch are altered and enhanced altered tests in test_copy.py for this kind of thing. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-13 15:27 Message: Logged In: YES user_id=6380 Looks fine to me; classic instances already did the same thing. Thanks, Steven! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 11:28 Message: Logged In: YES user_id=31435 Assigned to Guido because he knows more about this and I'm out of time for the next two days. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 10:42 Message: Logged In: YES user_id=33168 This patch works on 2.3. I'm not sure if this is fixing a bug or a feature. The change seems reasonable, but I don't know enough about copy to know if there are any negative consequences. I can check in if someone else agrees. Tim? Guido? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707900&group_id=5470 From noreply@sourceforge.net Fri Jun 13 20:29:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 12:29:59 -0700 Subject: [Patches] [ python-Patches-707900 ] bug fix 702858: deepcopying reflexive objects Message-ID: Patches item #707900, was opened at 2003-03-21 23:08 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707900&group_id=5470 Category: Library (Lib) >Group: Python 2.2.x >Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) >Assigned to: Neal Norwitz (nnorwitz) Summary: bug fix 702858: deepcopying reflexive objects Initial Comment: A fix for bug 702858, which concerns the inability of copy.deepcopy to correctly process reflexive new-style class instances, that is, instances referring to themselves. The fix is one line; the other 51 lines in the patch are altered and enhanced altered tests in test_copy.py for this kind of thing. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-13 15:29 Message: Logged In: YES user_id=6380 Reopened - Neal, would you mind backporting this to 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-13 15:27 Message: Logged In: YES user_id=6380 Looks fine to me; classic instances already did the same thing. Thanks, Steven! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 11:28 Message: Logged In: YES user_id=31435 Assigned to Guido because he knows more about this and I'm out of time for the next two days. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 10:42 Message: Logged In: YES user_id=33168 This patch works on 2.3. I'm not sure if this is fixing a bug or a feature. The change seems reasonable, but I don't know enough about copy to know if there are any negative consequences. I can check in if someone else agrees. Tim? Guido? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707900&group_id=5470 From noreply@sourceforge.net Sat Jun 14 01:51:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 17:51:48 -0700 Subject: [Patches] [ python-Patches-754340 ] *another* redirect_request typo Message-ID: Patches item #754340, was opened at 2003-06-14 01:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754340&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: *another* redirect_request typo Initial Comment: Yet another typo from my patch for #549151. Presumably this is now in 2.2.3 final. Found by Pychecker, rather belatedly run... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754340&group_id=5470 From noreply@sourceforge.net Sat Jun 14 04:52:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 20:52:29 -0700 Subject: [Patches] [ python-Patches-572936 ] (?(id/name)yes|no) re implementation Message-ID: Patches item #572936, was opened at 2002-06-24 01:41 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: (?(id/name)yes|no) re implementation Initial Comment: This patch implements a regular expression feature, which allows some interesting patterns, in the same way as implemented in perl. For example, (?(1)yes|no) matches with "yes" if group "1" exists, and with "no", if it doesn't. Without this feature, the regular expression must be duplicated to get the same results. In addition to perl's feature, it will also accept a Python named group as argument. Here's an example: (<)?\w+@\w+(\.\w+)+(?(1)>) This is a poor email matching regular expression, which will match with or without the "<>" symbols. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-14 03:52 Message: Logged In: YES user_id=7887 Martin, I've checked your concern about making "(X)|(?(1)Y)" an error, and unfortunately the current framework doesn't implement enough state information to catch this. Notice that this is not implemented in very similar cases, like "(X)|\1", which does exactly the same thing as "(X)|(?(1)X)". I'll be applying that patch as soon as I check it against the current HEAD, and implement some tests (and before it completes its first year of life 8-). Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 22:09 Message: Logged In: YES user_id=7887 I see. I'll try to improve the patch with your suggestions as soon as I get some time to work on it. Thanks for your support. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 21:57 Message: Logged In: YES user_id=21627 Exactly: My example makes no sense, it will always be false since the reference is to an alternative that cannot be simultaneously be taken. Therefore, I think this should be an error. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 08:12 Message: Logged In: YES user_id=7887 About the test cases, they're missing indeed. I can write some while applying the patch. About being experimental, IIRC, it is listed like experimental in the Perl documentation for several years, and will probably stay like this forever. :-) Anyway, IMO this shouldn't affect our evaluation of the importance of that feature for Python's sre. About semantic restriction, do you mean check if the backreference is lesser than the current group? Should be doable. OTOH, I don't understand your example. In "(X)|(?(1)Y)", there's no sense in using (?(1), as it will always be false. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 06:23 Message: Logged In: YES user_id=21627 I like the patch in principle, but I have a number of additional concerns: - there are no test cases - the feature is declared experimental in perlre(1). Why? - Shouldn't there be a semantic restriction that the back reference is only allowed if it points to a group that is known to precede? I.e. is (X)|(?(1)Y) valid? If not, the restriction should be atleast documented, but if possible, it should also be implemented. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 21:30 Message: Logged In: YES user_id=7887 That patch is around for a long time. Should I work on it, fixing that problem, and apply it? Do you agree with the feature inclusion? I remember that the main reason for implementing this is because it is hard to achieve the same results without it. You have to rewrite the whole match twice inside an or'ed group (e.g. "(<... match email ...>|... match email ...)"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 08:50 Message: Logged In: YES user_id=21627 If you add new opcodes, you should also change SRE_MAGIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 From noreply@sourceforge.net Sat Jun 14 06:15:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 22:15:35 -0700 Subject: [Patches] [ python-Patches-572936 ] (?(id/name)yes|no) re implementation Message-ID: Patches item #572936, was opened at 2002-06-24 03:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: (?(id/name)yes|no) re implementation Initial Comment: This patch implements a regular expression feature, which allows some interesting patterns, in the same way as implemented in perl. For example, (?(1)yes|no) matches with "yes" if group "1" exists, and with "no", if it doesn't. Without this feature, the regular expression must be duplicated to get the same results. In addition to perl's feature, it will also accept a Python named group as argument. Here's an example: (<)?\w+@\w+(\.\w+)+(?(1)>) This is a poor email matching regular expression, which will match with or without the "<>" symbols. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 07:15 Message: Logged In: YES user_id=21627 Please don't apply the patch before 2.3; this is in beta now, so no new features are allowed (unless you get BDFL permission, of course). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-14 05:52 Message: Logged In: YES user_id=7887 Martin, I've checked your concern about making "(X)|(?(1)Y)" an error, and unfortunately the current framework doesn't implement enough state information to catch this. Notice that this is not implemented in very similar cases, like "(X)|\1", which does exactly the same thing as "(X)|(?(1)X)". I'll be applying that patch as soon as I check it against the current HEAD, and implement some tests (and before it completes its first year of life 8-). Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-21 00:09 Message: Logged In: YES user_id=7887 I see. I'll try to improve the patch with your suggestions as soon as I get some time to work on it. Thanks for your support. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 23:57 Message: Logged In: YES user_id=21627 Exactly: My example makes no sense, it will always be false since the reference is to an alternative that cannot be simultaneously be taken. Therefore, I think this should be an error. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 10:12 Message: Logged In: YES user_id=7887 About the test cases, they're missing indeed. I can write some while applying the patch. About being experimental, IIRC, it is listed like experimental in the Perl documentation for several years, and will probably stay like this forever. :-) Anyway, IMO this shouldn't affect our evaluation of the importance of that feature for Python's sre. About semantic restriction, do you mean check if the backreference is lesser than the current group? Should be doable. OTOH, I don't understand your example. In "(X)|(?(1)Y)", there's no sense in using (?(1), as it will always be false. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 08:23 Message: Logged In: YES user_id=21627 I like the patch in principle, but I have a number of additional concerns: - there are no test cases - the feature is declared experimental in perlre(1). Why? - Shouldn't there be a semantic restriction that the back reference is only allowed if it points to a group that is known to precede? I.e. is (X)|(?(1)Y) valid? If not, the restriction should be atleast documented, but if possible, it should also be implemented. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:30 Message: Logged In: YES user_id=7887 That patch is around for a long time. Should I work on it, fixing that problem, and apply it? Do you agree with the feature inclusion? I remember that the main reason for implementing this is because it is hard to achieve the same results without it. You have to rewrite the whole match twice inside an or'ed group (e.g. "(<... match email ...>|... match email ...)"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 10:50 Message: Logged In: YES user_id=21627 If you add new opcodes, you should also change SRE_MAGIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 From noreply@sourceforge.net Sat Jun 14 06:30:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 22:30:12 -0700 Subject: [Patches] [ python-Patches-753845 ] Update README for Redhat 9 Tkinter compile with USC-4 Message-ID: Patches item #753845, was opened at 2003-06-13 11:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753845&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Update README for Redhat 9 Tkinter compile with USC-4 Initial Comment: This patch updates the README to describe a workaround to the problem described in SF#719880, http://mail.python.org/pipermail/python-dev/2003-April/034724.html and http://mail.python.org/pipermail/python-dev/2003-June/036277.html. It was about --enable-unicode=ucs4 and having to remove the build/ directory. It also adds to the Redhat-Python-1.5.2 note that this is only true for old Redhat systems (I think <8, but I'm not sure so I didn't add the detail). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 07:30 Message: Logged In: YES user_id=21627 Thanks, applied as 1.174. Removing the build directory is not needed if you give --enable-ucs4 right from the beginning, so I have removed that sentence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753845&group_id=5470 From noreply@sourceforge.net Sat Jun 14 06:36:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 22:36:05 -0700 Subject: [Patches] [ python-Patches-754004 ] incorrect release year in PEP 251 Message-ID: Patches item #754004, was opened at 2003-06-13 16:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754004&group_id=5470 Category: None Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect release year in PEP 251 Initial Comment: PEP 251 states that Python 2.2a3 was released on 7-Sep-1001, 1000 years after 2.2a2 and 1000 years before 2.2a3. This seems unlikely; this patch reverses the time leap and puts Python 2.2a3 back in the 21st century. BTW, no Category seem appropiate; is that because it's in the nondist/ dir? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 07:36 Message: Logged In: YES user_id=21627 Thanks, installed. Perhaps the documentation category would be reasonable; leaving the category as None is also fine - we rarely get PEP patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754004&group_id=5470 From noreply@sourceforge.net Sat Jun 14 06:37:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 22:37:16 -0700 Subject: [Patches] [ python-Patches-572936 ] (?(id/name)yes|no) re implementation Message-ID: Patches item #572936, was opened at 2002-06-24 01:41 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: (?(id/name)yes|no) re implementation Initial Comment: This patch implements a regular expression feature, which allows some interesting patterns, in the same way as implemented in perl. For example, (?(1)yes|no) matches with "yes" if group "1" exists, and with "no", if it doesn't. Without this feature, the regular expression must be duplicated to get the same results. In addition to perl's feature, it will also accept a Python named group as argument. Here's an example: (<)?\w+@\w+(\.\w+)+(?(1)>) This is a poor email matching regular expression, which will match with or without the "<>" symbols. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-14 05:37 Message: Logged In: YES user_id=7887 Ack!! I'm not going to ask Guido if you belive it's not worth for 2.3. I'm attaching a new version of the patch, updated to the current HEAD, and including tests. Thanks for your attention! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 05:15 Message: Logged In: YES user_id=21627 Please don't apply the patch before 2.3; this is in beta now, so no new features are allowed (unless you get BDFL permission, of course). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-14 03:52 Message: Logged In: YES user_id=7887 Martin, I've checked your concern about making "(X)|(?(1)Y)" an error, and unfortunately the current framework doesn't implement enough state information to catch this. Notice that this is not implemented in very similar cases, like "(X)|\1", which does exactly the same thing as "(X)|(?(1)X)". I'll be applying that patch as soon as I check it against the current HEAD, and implement some tests (and before it completes its first year of life 8-). Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 22:09 Message: Logged In: YES user_id=7887 I see. I'll try to improve the patch with your suggestions as soon as I get some time to work on it. Thanks for your support. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 21:57 Message: Logged In: YES user_id=21627 Exactly: My example makes no sense, it will always be false since the reference is to an alternative that cannot be simultaneously be taken. Therefore, I think this should be an error. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 08:12 Message: Logged In: YES user_id=7887 About the test cases, they're missing indeed. I can write some while applying the patch. About being experimental, IIRC, it is listed like experimental in the Perl documentation for several years, and will probably stay like this forever. :-) Anyway, IMO this shouldn't affect our evaluation of the importance of that feature for Python's sre. About semantic restriction, do you mean check if the backreference is lesser than the current group? Should be doable. OTOH, I don't understand your example. In "(X)|(?(1)Y)", there's no sense in using (?(1), as it will always be false. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 06:23 Message: Logged In: YES user_id=21627 I like the patch in principle, but I have a number of additional concerns: - there are no test cases - the feature is declared experimental in perlre(1). Why? - Shouldn't there be a semantic restriction that the back reference is only allowed if it points to a group that is known to precede? I.e. is (X)|(?(1)Y) valid? If not, the restriction should be atleast documented, but if possible, it should also be implemented. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 21:30 Message: Logged In: YES user_id=7887 That patch is around for a long time. Should I work on it, fixing that problem, and apply it? Do you agree with the feature inclusion? I remember that the main reason for implementing this is because it is hard to achieve the same results without it. You have to rewrite the whole match twice inside an or'ed group (e.g. "(<... match email ...>|... match email ...)"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 08:50 Message: Logged In: YES user_id=21627 If you add new opcodes, you should also change SRE_MAGIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 From noreply@sourceforge.net Sat Jun 14 06:47:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 22:47:50 -0700 Subject: [Patches] [ python-Patches-752671 ] NetBSD needs to link libintl Message-ID: Patches item #752671, was opened at 2003-06-11 17:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752671&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD needs to link libintl Initial Comment: On NetBSD the libintl.h is found, but the libintl to linked. Therefore the locale module fails to link. The attached patch changes configure.in to check for textdomain in libintl and if it's found it adds libintl to $LIBS. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 07:47 Message: Logged In: YES user_id=21627 Linking python with libintl is incorrect as it is needed for _locale.so. Instead, you should come up with a patch for setup.py, and perhaps a (comment) patch for Modules/Setup.dist. While the patch probably "works" on most systems, it fails when libintl is needed and is a non-shared library (libintl.a). It would be IMO safe to assume that -lintl is needed if libintl.h is present; if you want to, you can still perform a test for textdomain in configure, and communicate its result to setup.py through a #define. P.S. There is no need to compress 600 byte attachments, IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752671&group_id=5470 From noreply@sourceforge.net Sat Jun 14 06:52:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2003 22:52:44 -0700 Subject: [Patches] [ python-Patches-754340 ] *another* redirect_request typo Message-ID: Patches item #754340, was opened at 2003-06-14 02:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754340&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: *another* redirect_request typo Initial Comment: Yet another typo from my patch for #549151. Presumably this is now in 2.2.3 final. Found by Pychecker, rather belatedly run... ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 07:52 Message: Logged In: YES user_id=21627 Thanks, committed as 1.49 and 1.24.8.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754340&group_id=5470 From noreply@sourceforge.net Sat Jun 14 16:13:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 14 Jun 2003 08:13:44 -0700 Subject: [Patches] [ python-Patches-752671 ] NetBSD needs to link libintl Message-ID: Patches item #752671, was opened at 2003-06-11 17:47 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752671&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD needs to link libintl Initial Comment: On NetBSD the libintl.h is found, but the libintl to linked. Therefore the locale module fails to link. The attached patch changes configure.in to check for textdomain in libintl and if it's found it adds libintl to $LIBS. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-06-14 17:13 Message: Logged In: YES user_id=205 OK, changed that. In fact I made two different solutions, because there was no prior case of configure/setup.py interaction (or I didn't see it..) 1. configure checks for textdomain in libintl, sets a define accordingly and setup.py checks for that define 2. setupy checkfs for libintl.h if it's found libintl is added to list of libs for _locale Both solutions for on my NetBSD-current system with today's Python 2.3/cvs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 07:47 Message: Logged In: YES user_id=21627 Linking python with libintl is incorrect as it is needed for _locale.so. Instead, you should come up with a patch for setup.py, and perhaps a (comment) patch for Modules/Setup.dist. While the patch probably "works" on most systems, it fails when libintl is needed and is a non-shared library (libintl.a). It would be IMO safe to assume that -lintl is needed if libintl.h is present; if you want to, you can still perform a test for textdomain in configure, and communicate its result to setup.py through a #define. P.S. There is no need to compress 600 byte attachments, IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752671&group_id=5470 From noreply@sourceforge.net Sat Jun 14 16:44:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 14 Jun 2003 08:44:48 -0700 Subject: [Patches] [ python-Patches-752671 ] NetBSD needs to link libintl Message-ID: Patches item #752671, was opened at 2003-06-11 17:47 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752671&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) >Assigned to: Martin v. Löwis (loewis) Summary: NetBSD needs to link libintl Initial Comment: On NetBSD the libintl.h is found, but the libintl to linked. Therefore the locale module fails to link. The attached patch changes configure.in to check for textdomain in libintl and if it's found it adds libintl to $LIBS. ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-06-14 17:13 Message: Logged In: YES user_id=205 OK, changed that. In fact I made two different solutions, because there was no prior case of configure/setup.py interaction (or I didn't see it..) 1. configure checks for textdomain in libintl, sets a define accordingly and setup.py checks for that define 2. setupy checkfs for libintl.h if it's found libintl is added to list of libs for _locale Both solutions for on my NetBSD-current system with today's Python 2.3/cvs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 07:47 Message: Logged In: YES user_id=21627 Linking python with libintl is incorrect as it is needed for _locale.so. Instead, you should come up with a patch for setup.py, and perhaps a (comment) patch for Modules/Setup.dist. While the patch probably "works" on most systems, it fails when libintl is needed and is a non-shared library (libintl.a). It would be IMO safe to assume that -lintl is needed if libintl.h is present; if you want to, you can still perform a test for textdomain in configure, and communicate its result to setup.py through a #define. P.S. There is no need to compress 600 byte attachments, IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752671&group_id=5470 From noreply@sourceforge.net Sat Jun 14 20:52:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 14 Jun 2003 12:52:07 -0700 Subject: [Patches] [ python-Patches-754632 ] Enhance xrange description by mentioning itertools.repeat Message-ID: Patches item #754632, was opened at 2003-06-14 21:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754632&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance xrange description by mentioning itertools.repeat Initial Comment: This patch lets the description of the xrange builtin function include the recently by Alex Martelli on python-dev described notion that itertools.repeat(None, n) may be a lot faster than range() or xrange(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754632&group_id=5470 From noreply@sourceforge.net Sat Jun 14 22:03:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 14 Jun 2003 14:03:53 -0700 Subject: [Patches] [ python-Patches-752671 ] NetBSD needs to link libintl Message-ID: Patches item #752671, was opened at 2003-06-11 17:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752671&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Martin v. Löwis (loewis) Summary: NetBSD needs to link libintl Initial Comment: On NetBSD the libintl.h is found, but the libintl to linked. Therefore the locale module fails to link. The attached patch changes configure.in to check for textdomain in libintl and if it's found it adds libintl to $LIBS. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 23:03 Message: Logged In: YES user_id=21627 Thanks for the patch. I have committed the configure version as configure 1.407 configure.in 1.418 pyconfig.h.in 1.81 setup.py 1.169 Setup.dist 1.41 ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-06-14 17:13 Message: Logged In: YES user_id=205 OK, changed that. In fact I made two different solutions, because there was no prior case of configure/setup.py interaction (or I didn't see it..) 1. configure checks for textdomain in libintl, sets a define accordingly and setup.py checks for that define 2. setupy checkfs for libintl.h if it's found libintl is added to list of libs for _locale Both solutions for on my NetBSD-current system with today's Python 2.3/cvs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 07:47 Message: Logged In: YES user_id=21627 Linking python with libintl is incorrect as it is needed for _locale.so. Instead, you should come up with a patch for setup.py, and perhaps a (comment) patch for Modules/Setup.dist. While the patch probably "works" on most systems, it fails when libintl is needed and is a non-shared library (libintl.a). It would be IMO safe to assume that -lintl is needed if libintl.h is present; if you want to, you can still perform a test for textdomain in configure, and communicate its result to setup.py through a #define. P.S. There is no need to compress 600 byte attachments, IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752671&group_id=5470 From noreply@sourceforge.net Sat Jun 14 22:35:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 14 Jun 2003 14:35:10 -0700 Subject: [Patches] [ python-Patches-621891 ] tkFileDialog multiple option Message-ID: Patches item #621891, was opened at 2002-10-11 16:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 Category: Tkinter Group: Python 2.2.x >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog multiple option Initial Comment: In tk8.4 tk_getOpenFile and tk_getSaveFile dialogs used by tkFileDialog.py now allow the multiple option on all platforms, according to the docs... I have only tested in Linux (RedHat 7.2) python 2.2.1 and tk 8.4 This patch adds two new functions to the tkFileDialog module askopenfilenames() and askopenfiles() the function doc strings explain what they do... I've uploaded a diff. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 23:35 Message: Logged In: YES user_id=21627 This is now fixed in tkFileDialog.py 1.10 _tkinter.c 1.161 ---------------------------------------------------------------------- Comment By: Deacon Sweeney (s014djs) Date: 2003-06-09 20:37 Message: Logged In: YES user_id=797021 I encountered this bug running Python2.3 beta, on Windows XP. The reported patch (621891 tkFileDialog multiple option) is supposed to return a list of file names upon selection of multiple files in the askopenfilenames function of the tkFileDialog module. It fails, mentioning some bug about concatenating a string with a tuple, if I remember correctly. So I fixed it on my machine. I haven't studied the whole system to know what other fuctions call the show function, but I specified the fix for the tk_getOpenFile command with the 'multiple' option, so it shouldn't fail for any other cases. I need this option for the software I'm developing, but am new to this development forum. Is there anything else I can do to help get this fixed for the Python 2.3 release? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-09 18:51 Message: Logged In: YES user_id=21627 Are you trying to report some bug? If so, what bug? I.e. what is your source code, what is the expected behaviour, what is the observed behaviour? ---------------------------------------------------------------------- Comment By: Deacon Sweeney (s014djs) Date: 2003-06-09 18:33 Message: Logged In: YES user_id=797021 This didn't really work for me. The problem is in tkCommonDialog.py, in the Dialog.show(). The first try is not set up to handle the list that gets returned by the multiple option. Here's a fix: replace the stuff in that try (a call command, followed by a _fixresult command, with the following: [start snip] t = w.tk.call(self.command, *w._options (self.options)) # for the special case of multiple file selection, # return a list, instead of a singleton for i, j in self.options.items(): if i == 'multiple' and self.command == 'tk_getOpenFile': s = [] for m in t: s.append(self._fixresult(w, m)) break else: s = self._fixresult(w, t) [end snip] Its only set up to handle stuff from tk_getOpenFile commands, but would provide a framework for solving other problems as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-14 13:56 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as tkFileDialog.py 1.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 From noreply@sourceforge.net Sat Jun 14 22:40:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 14 Jun 2003 14:40:26 -0700 Subject: [Patches] [ python-Patches-751107 ] Wrong constant in tkFont module Message-ID: Patches item #751107, was opened at 2003-06-09 02:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751107&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Pedro Werneck (pedrowerneck) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong constant in tkFont module Initial Comment: Both constant and docstring on the tkFont module have wrong value for non-italic font, "normal", instead of "roman"... using the NORMAL constant as documented raises a "TclError: bad -slant value "normal": must be roman, or italic". This patch correct both constant and docstring. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 23:40 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as tkFont.py 1.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751107&group_id=5470 From noreply@sourceforge.net Mon Jun 16 07:22:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 15 Jun 2003 23:22:07 -0700 Subject: [Patches] [ python-Patches-755147 ] Makefile changes for IDLE fork merge Message-ID: Patches item #755147, was opened at 2003-06-16 06:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755147&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Jack Jansen (jackjansen) Summary: Makefile changes for IDLE fork merge Initial Comment: This patch fixes the Makefile in Mac/OSX so Idle.app can build again after the merge of the IDLE fork code. I also tweaked the flags for ln so symlinks won't fail on reinstalls. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755147&group_id=5470 From noreply@sourceforge.net Mon Jun 16 10:47:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 02:47:40 -0700 Subject: [Patches] [ python-Patches-755147 ] Makefile changes for IDLE fork merge Message-ID: Patches item #755147, was opened at 2003-06-16 08:22 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755147&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Jack Jansen (jackjansen) Summary: Makefile changes for IDLE fork merge Initial Comment: This patch fixes the Makefile in Mac/OSX so Idle.app can build again after the merge of the IDLE fork code. I also tweaked the flags for ln so symlinks won't fail on reinstalls. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-06-16 11:47 Message: Logged In: YES user_id=45365 Thanks, checked in as Mac/OSX/Makefile rev. 1.42. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755147&group_id=5470 From noreply@sourceforge.net Mon Jun 16 12:22:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 04:22:06 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 13:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Mon Jun 16 13:48:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 05:48:46 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 16 13:57:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 05:57:18 -0700 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply@sourceforge.net Mon Jun 16 14:31:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 06:31:13 -0700 Subject: [Patches] [ python-Patches-754870 ] SSL crash interpreter on error Message-ID: Patches item #754870, was opened at 2003-06-15 09:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754870&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: SSL crash interpreter on error Initial Comment: When testing bug 739909, I provoked this bug. To reproduce: # ./python # need to be root to listen on privileged port >>> from socket import * >>> s = socket(AF_INET, SOCK_STREAM) >>> s.bind(('', 993)) >>> s.listen(5) >>> s.accept() # now go to another window and do: $ ./python >>> import imaplib >>> imaplib.IMAP4_SSL('localhost') # this will wait for the first (root) interpreter # exit from first/root interpreter and SSL will crash There is a stack trace below. The problem is that in PySSL_SetError(), there is an assumption that obj->Socket exists, but it doesn't in this case. The attached patch fixes the crash, but I'm not certain it is correct. #0 0x4046eaba in PySSL_SetError (obj=0x81e0718, ret=-1) at /home/neal/build/python/2_3/Modules/_ssl.c:118 #1 0x4046efed in newPySSLObject (Sock=0x4013f9c8, key_file=0x0, cert_file=0x0) at /home/neal/build/python/2_3/Modules/_ssl.c:259 #2 0x4046f181 in PySocket_ssl (self=0x0, args=0x403e4df4) at /home/neal/build/python/2_3/Modules/_ssl.c:296 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-16 09:31 Message: Logged In: YES user_id=33168 Moved to patches ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-06-15 15:26 Message: Logged In: YES user_id=38388 Sorry, no time for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754870&group_id=5470 From noreply@sourceforge.net Mon Jun 16 14:49:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 06:49:40 -0700 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply@sourceforge.net Mon Jun 16 16:37:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 08:37:10 -0700 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply@sourceforge.net Mon Jun 16 16:44:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 08:44:14 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 16 16:59:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 08:59:09 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 16 17:01:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 09:01:27 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 06:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Brett Cannon (bcannon) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:01 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Mon Jun 16 17:04:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 09:04:27 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 16 18:58:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 10:58:47 -0700 Subject: [Patches] [ python-Patches-569574 ] plain text enhancement for cgitb Message-ID: Patches item #569574, was opened at 2002-06-16 00:46 Message generated for change (Comment added) made by hfastedge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569574&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Ka-Ping Yee (ping) Summary: plain text enhancement for cgitb Initial Comment: Here's a patch to cgitb that allows you to enable plain text output. It adds an extra variable to the cgitb.enable function and corresponding underlying functions. To get plain text invoke it as import cgitb cgitb.enable(format="text") (actually, any value for format other than "html" will enable plain text output). The default value is "html", so existing usage of cgitb should be unaffected. I realize this isn't quite what you suggested, but it seemed to me worthwhile to keep such similar code together. I'm not entirely certain I haven't fouled up the html formatting. It needs to be checked still. Also still to come is a doc change. Skip ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-06-16 13:58 Message: Logged In: YES user_id=479934 http://mail.python.org/pipermail/python-dev/2003-June/036230.html the need for this is clear and longstanding. I filed a bug about this https://sourceforge.net/tracker/?group_id=5470&atid=105470 please remove it as i never found this bug im writing on before now I even later wrote the patch for myself. im sure ping's patch is better. I use this patch every day because it simply is flat out better than python's current error mechanism. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-02 13:45 Message: Logged In: YES user_id=44345 I started messing around with this, but quickly figured out I didn't know what "main routine" belongs in traceback. Moving lookup and scanvars there is no problem, but the rest of the functionality is almost entirely in the html() and text() routines. Do you mean they should go in traceback? ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-07-09 23:33 Message: Logged In: YES user_id=45338 I think enhanced text tracebacks would be great. (I even have my own hacked-up one lying around here somewhere -- it colourized the output. I think a part of me was waiting for an opportunity to make enhanced tracebacks standard. The most important enhancement IMHO is to show argument values.) I don't think the functionality belongs in cgitb, though. The main routine probably should go in traceback; the common routines (scanvars and lookup) can go there too. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-07-09 19:48 Message: Logged In: YES user_id=44345 Ping How about you? As the author I think you're in the best position to decide on the merits of the patch... Skip ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 23:36 Message: Logged In: YES user_id=6380 Unassigning -- I won't get to this before my vacation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-16 01:09 Message: Logged In: YES user_id=44345 Okay, here's a correction to the first patch. It fixes the logic bug that corrupted the HTML output. It also adds a little bit of extra documentation. Writing the documentation made me think that perhaps this should be added to the traceback module as Guido suggested with just a stub cgitb module that provides an enable function that calls the enable function in the traceback module with format="html". The cgitb module could then be deprecated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569574&group_id=5470 From noreply@sourceforge.net Mon Jun 16 19:00:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 11:00:12 -0700 Subject: [Patches] [ python-Patches-569574 ] plain text enhancement for cgitb Message-ID: Patches item #569574, was opened at 2002-06-16 00:46 Message generated for change (Comment added) made by hfastedge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569574&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Ka-Ping Yee (ping) Summary: plain text enhancement for cgitb Initial Comment: Here's a patch to cgitb that allows you to enable plain text output. It adds an extra variable to the cgitb.enable function and corresponding underlying functions. To get plain text invoke it as import cgitb cgitb.enable(format="text") (actually, any value for format other than "html" will enable plain text output). The default value is "html", so existing usage of cgitb should be unaffected. I realize this isn't quite what you suggested, but it seemed to me worthwhile to keep such similar code together. I'm not entirely certain I haven't fouled up the html formatting. It needs to be checked still. Also still to come is a doc change. Skip ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-06-16 14:00 Message: Logged In: YES user_id=479934 proper location to my bug https://sourceforge.net/tracker/?func=detail&aid=654558&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-06-16 13:58 Message: Logged In: YES user_id=479934 http://mail.python.org/pipermail/python-dev/2003-June/036230.html the need for this is clear and longstanding. I filed a bug about this https://sourceforge.net/tracker/?group_id=5470&atid=105470 please remove it as i never found this bug im writing on before now I even later wrote the patch for myself. im sure ping's patch is better. I use this patch every day because it simply is flat out better than python's current error mechanism. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-02 13:45 Message: Logged In: YES user_id=44345 I started messing around with this, but quickly figured out I didn't know what "main routine" belongs in traceback. Moving lookup and scanvars there is no problem, but the rest of the functionality is almost entirely in the html() and text() routines. Do you mean they should go in traceback? ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-07-09 23:33 Message: Logged In: YES user_id=45338 I think enhanced text tracebacks would be great. (I even have my own hacked-up one lying around here somewhere -- it colourized the output. I think a part of me was waiting for an opportunity to make enhanced tracebacks standard. The most important enhancement IMHO is to show argument values.) I don't think the functionality belongs in cgitb, though. The main routine probably should go in traceback; the common routines (scanvars and lookup) can go there too. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-07-09 19:48 Message: Logged In: YES user_id=44345 Ping How about you? As the author I think you're in the best position to decide on the merits of the patch... Skip ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 23:36 Message: Logged In: YES user_id=6380 Unassigning -- I won't get to this before my vacation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-16 01:09 Message: Logged In: YES user_id=44345 Okay, here's a correction to the first patch. It fixes the logic bug that corrupted the HTML output. It also adds a little bit of extra documentation. Writing the documentation made me think that perhaps this should be added to the traceback module as Guido suggested with just a stub cgitb module that provides an enable function that calls the enable function in the traceback module with format="html". The cgitb module could then be deprecated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569574&group_id=5470 From noreply@sourceforge.net Mon Jun 16 19:09:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 11:09:43 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 16 19:20:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 11:20:06 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 03:45 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-16 11:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 11:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 09:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 08:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 08:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 05:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 09:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 08:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 06:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 16:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 18:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 17:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 16:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 16 19:22:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 11:22:20 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 04:22 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-16 11:22 Message: Logged In: YES user_id=357491 You sure you want me to check this after what happened last time I tried to "modernize" a module? =) OK, I will take a look. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 09:01 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Mon Jun 16 19:36:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 11:36:12 -0700 Subject: [Patches] [ python-Patches-569574 ] plain text enhancement for cgitb Message-ID: Patches item #569574, was opened at 2002-06-15 23:46 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569574&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Ka-Ping Yee (ping) Summary: plain text enhancement for cgitb Initial Comment: Here's a patch to cgitb that allows you to enable plain text output. It adds an extra variable to the cgitb.enable function and corresponding underlying functions. To get plain text invoke it as import cgitb cgitb.enable(format="text") (actually, any value for format other than "html" will enable plain text output). The default value is "html", so existing usage of cgitb should be unaffected. I realize this isn't quite what you suggested, but it seemed to me worthwhile to keep such similar code together. I'm not entirely certain I haven't fouled up the html formatting. It needs to be checked still. Also still to come is a doc change. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-06-16 13:36 Message: Logged In: YES user_id=44345 Okay, I closed 654558 as a duplicate of this one. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-06-16 13:00 Message: Logged In: YES user_id=479934 proper location to my bug https://sourceforge.net/tracker/?func=detail&aid=654558&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-06-16 12:58 Message: Logged In: YES user_id=479934 http://mail.python.org/pipermail/python-dev/2003-June/036230.html the need for this is clear and longstanding. I filed a bug about this https://sourceforge.net/tracker/?group_id=5470&atid=105470 please remove it as i never found this bug im writing on before now I even later wrote the patch for myself. im sure ping's patch is better. I use this patch every day because it simply is flat out better than python's current error mechanism. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-02 12:45 Message: Logged In: YES user_id=44345 I started messing around with this, but quickly figured out I didn't know what "main routine" belongs in traceback. Moving lookup and scanvars there is no problem, but the rest of the functionality is almost entirely in the html() and text() routines. Do you mean they should go in traceback? ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-07-09 22:33 Message: Logged In: YES user_id=45338 I think enhanced text tracebacks would be great. (I even have my own hacked-up one lying around here somewhere -- it colourized the output. I think a part of me was waiting for an opportunity to make enhanced tracebacks standard. The most important enhancement IMHO is to show argument values.) I don't think the functionality belongs in cgitb, though. The main routine probably should go in traceback; the common routines (scanvars and lookup) can go there too. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-07-09 18:48 Message: Logged In: YES user_id=44345 Ping How about you? As the author I think you're in the best position to decide on the merits of the patch... Skip ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 22:36 Message: Logged In: YES user_id=6380 Unassigning -- I won't get to this before my vacation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-16 00:09 Message: Logged In: YES user_id=44345 Okay, here's a correction to the first patch. It fixes the logic bug that corrupted the HTML output. It also adds a little bit of extra documentation. Writing the documentation made me think that perhaps this should be added to the traceback module as Guido suggested with just a stub cgitb module that provides an enable function that calls the enable function in the traceback module with format="html". The cgitb module could then be deprecated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569574&group_id=5470 From noreply@sourceforge.net Mon Jun 16 20:09:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 12:09:08 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 13:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 16 20:13:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 12:13:22 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 06:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:13 Message: Logged In: YES user_id=80475 Yes. I've already checked it but wanted you to see the process of how it can be done reliably (clear objectives, single module changes, expanded tests, detailed second party review, etc). It should take less than half an hour and it's good for you (like vitamins). BTW, don't accept the patch until the new test suite runs on all platforms. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:22 Message: Logged In: YES user_id=357491 You sure you want me to check this after what happened last time I tried to "modernize" a module? =) OK, I will take a look. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:01 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Mon Jun 16 20:33:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 12:33:13 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 16 20:39:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 12:39:29 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 13:22 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:39 Message: Logged In: YES user_id=89016 There is missing += update in expandvars(). Uploading new version of the patch ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:13 Message: Logged In: YES user_id=80475 Yes. I've already checked it but wanted you to see the process of how it can be done reliably (clear objectives, single module changes, expanded tests, detailed second party review, etc). It should take less than half an hour and it's good for you (like vitamins). BTW, don't accept the patch until the new test suite runs on all platforms. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:22 Message: Logged In: YES user_id=357491 You sure you want me to check this after what happened last time I tried to "modernize" a module? =) OK, I will take a look. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:01 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Mon Jun 16 20:41:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 12:41:14 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 13:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 16 20:44:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 12:44:28 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 06:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:44 Message: Logged In: YES user_id=80475 You're too quick. Brett was supposed to find that one. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:39 Message: Logged In: YES user_id=89016 There is missing += update in expandvars(). Uploading new version of the patch ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:13 Message: Logged In: YES user_id=80475 Yes. I've already checked it but wanted you to see the process of how it can be done reliably (clear objectives, single module changes, expanded tests, detailed second party review, etc). It should take less than half an hour and it's good for you (like vitamins). BTW, don't accept the patch until the new test suite runs on all platforms. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:22 Message: Logged In: YES user_id=357491 You sure you want me to check this after what happened last time I tried to "modernize" a module? =) OK, I will take a look. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:01 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Mon Jun 16 20:51:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 12:51:26 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 13:22 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 We could always delete the new version! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:44 Message: Logged In: YES user_id=80475 You're too quick. Brett was supposed to find that one. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:39 Message: Logged In: YES user_id=89016 There is missing += update in expandvars(). Uploading new version of the patch ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:13 Message: Logged In: YES user_id=80475 Yes. I've already checked it but wanted you to see the process of how it can be done reliably (clear objectives, single module changes, expanded tests, detailed second party review, etc). It should take less than half an hour and it's good for you (like vitamins). BTW, don't accept the patch until the new test suite runs on all platforms. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:22 Message: Logged In: YES user_id=357491 You sure you want me to check this after what happened last time I tried to "modernize" a module? =) OK, I will take a look. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:01 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Mon Jun 16 20:51:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 12:51:55 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 16 22:31:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 14:31:40 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 04:22 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-16 14:31 Message: Logged In: YES user_id=357491 Geez, I step out to pick a friend up from the airport and you guys already revise the thing! And no, you are not deleting the new version. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 12:51 Message: Logged In: YES user_id=89016 We could always delete the new version! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:44 Message: Logged In: YES user_id=80475 You're too quick. Brett was supposed to find that one. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 12:39 Message: Logged In: YES user_id=89016 There is missing += update in expandvars(). Uploading new version of the patch ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:13 Message: Logged In: YES user_id=80475 Yes. I've already checked it but wanted you to see the process of how it can be done reliably (clear objectives, single module changes, expanded tests, detailed second party review, etc). It should take less than half an hour and it's good for you (like vitamins). BTW, don't accept the patch until the new test suite runs on all platforms. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 11:22 Message: Logged In: YES user_id=357491 You sure you want me to check this after what happened last time I tried to "modernize" a module? =) OK, I will take a look. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 09:01 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Mon Jun 16 22:55:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 14:55:12 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 03:45 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-16 14:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 12:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 12:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 11:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 11:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 09:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 08:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 08:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 05:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 09:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 08:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 06:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 16:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 18:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 17:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 16:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Tue Jun 17 03:10:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 19:10:15 -0700 Subject: [Patches] [ python-Patches-751114 ] fix memory leaks in posixmodule on Windows Message-ID: Patches item #751114, was opened at 2003-06-08 21:39 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751114&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Mark Hammond (mhammond) Summary: fix memory leaks in posixmodule on Windows Initial Comment: The attached patch should fix memory leaks from os.listdir() on Windows. I can't test this, but it appears that bufptr was leaked in most circumstances. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-06-16 22:10 Message: Logged In: YES user_id=31435 Reassigned to MarkH, since CVS annotate shows his name in this area more than anyone else's. Offhand I don't see a reason to believe there's a leak here: looks like bufptr is non-NULL when PyArg_ParseTuple() is called, pointing to stack memory, and """ If *buffer points to a non-NULL pointer (an already allocated buffer), PyArg_ParseTuple() will use this location as buffer and interpret *buffer_length as buffer size. It will then copy the encoded data into the buffer and 0-terminate it. Buffer overflow is signalled with an exception. """ If so, we certainly shouldn't try to free it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751114&group_id=5470 From noreply@sourceforge.net Tue Jun 17 03:27:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 19:27:45 -0700 Subject: [Patches] [ python-Patches-755660 ] allow HTMLParser to continue after a parse error Message-ID: Patches item #755660, was opened at 2003-06-17 02:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755660&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Rosenthal (smroid) Assigned to: Nobody/Anonymous (nobody) Summary: allow HTMLParser to continue after a parse error Initial Comment: The HTMLParser.error method raises HTMLParseError, terminating the parse upon detection of a parse error. This patch is to allow HTMLParser to continue parsing if the error() method is overridden to not throw an exception. Doc impact is on the error() method. The existing test_htmlparser.py unit test is unaffected by the patch. The base file is HTMLParser.py, revision 1.11.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755660&group_id=5470 From noreply@sourceforge.net Tue Jun 17 03:39:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 19:39:49 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 04:22 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-16 19:39 Message: Logged In: YES user_id=357491 OK, I have uploaded a new diff with some stuff more changes (Ha!). If no one complains by tomorrow about the new test_posixpath.py I will apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 14:31 Message: Logged In: YES user_id=357491 Geez, I step out to pick a friend up from the airport and you guys already revise the thing! And no, you are not deleting the new version. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 12:51 Message: Logged In: YES user_id=89016 We could always delete the new version! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:44 Message: Logged In: YES user_id=80475 You're too quick. Brett was supposed to find that one. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 12:39 Message: Logged In: YES user_id=89016 There is missing += update in expandvars(). Uploading new version of the patch ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:13 Message: Logged In: YES user_id=80475 Yes. I've already checked it but wanted you to see the process of how it can be done reliably (clear objectives, single module changes, expanded tests, detailed second party review, etc). It should take less than half an hour and it's good for you (like vitamins). BTW, don't accept the patch until the new test suite runs on all platforms. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 11:22 Message: Logged In: YES user_id=357491 You sure you want me to check this after what happened last time I tried to "modernize" a module? =) OK, I will take a look. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 09:01 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Tue Jun 17 04:09:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 20:09:17 -0700 Subject: [Patches] [ python-Patches-755670 ] improve HTMLParser attribute processing regexps Message-ID: Patches item #755670, was opened at 2003-06-17 03:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Rosenthal (smroid) Assigned to: Nobody/Anonymous (nobody) Summary: improve HTMLParser attribute processing regexps Initial Comment: HTML examples seen in the wild that cause parse errors in HTMLParser include: -- note lack of space between val and next attr name -- trailing attribute has no value after = -- javascript fragment with embedded quotes My patch contains improvements to the 'attrfind' and 'locatestarttagend' regexps that allow these examples to parse. The existing test_htmlparser.py unit test continues to pass, except for the one test case where it considers to be an error. I commented out that case and added new test cases to cover the examples above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470 From noreply@sourceforge.net Tue Jun 17 04:10:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 20:10:57 -0700 Subject: [Patches] [ python-Patches-755670 ] improve HTMLParser attribute processing regexps Message-ID: Patches item #755670, was opened at 2003-06-17 03:09 Message generated for change (Comment added) made by smroid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Rosenthal (smroid) Assigned to: Nobody/Anonymous (nobody) Summary: improve HTMLParser attribute processing regexps Initial Comment: HTML examples seen in the wild that cause parse errors in HTMLParser include: -- note lack of space between val and next attr name -- trailing attribute has no value after = -- javascript fragment with embedded quotes My patch contains improvements to the 'attrfind' and 'locatestarttagend' regexps that allow these examples to parse. The existing test_htmlparser.py unit test continues to pass, except for the one test case where it considers to be an error. I commented out that case and added new test cases to cover the examples above. ---------------------------------------------------------------------- >Comment By: Steven Rosenthal (smroid) Date: 2003-06-17 03:10 Message: Logged In: YES user_id=159908 Base version for HTMLParser.py is 1.11.2.1; base version for test_htmlparser.py is 1.8.8.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470 From noreply@sourceforge.net Tue Jun 17 04:35:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 20:35:53 -0700 Subject: [Patches] [ python-Patches-755677 ] 755617: better docs for os.chmod Message-ID: Patches item #755677, was opened at 2003-06-16 22:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Nobody/Anonymous (nobody) Summary: 755617: better docs for os.chmod Initial Comment: As per the discussion thread on c.l.p and summarized by Matthew Shomphe ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 From noreply@sourceforge.net Tue Jun 17 05:05:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 21:05:47 -0700 Subject: [Patches] [ python-Patches-755683 ] 700827: Compiler Limits (indentation) Message-ID: Patches item #755683, was opened at 2003-06-16 23:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755683&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Nobody/Anonymous (nobody) Summary: 700827: Compiler Limits (indentation) Initial Comment: Add docs to state that certain platforms have different max indentation levels, and that should be noted by the developer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755683&group_id=5470 From noreply@sourceforge.net Tue Jun 17 06:22:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2003 22:22:05 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 06:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 00:22 Message: Logged In: YES user_id=80475 According to tradition, Walter should apply the patch after checking to make sure he agrees with the changes. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 21:39 Message: Logged In: YES user_id=357491 OK, I have uploaded a new diff with some stuff more changes (Ha!). If no one complains by tomorrow about the new test_posixpath.py I will apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 16:31 Message: Logged In: YES user_id=357491 Geez, I step out to pick a friend up from the airport and you guys already revise the thing! And no, you are not deleting the new version. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:51 Message: Logged In: YES user_id=89016 We could always delete the new version! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:44 Message: Logged In: YES user_id=80475 You're too quick. Brett was supposed to find that one. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:39 Message: Logged In: YES user_id=89016 There is missing += update in expandvars(). Uploading new version of the patch ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:13 Message: Logged In: YES user_id=80475 Yes. I've already checked it but wanted you to see the process of how it can be done reliably (clear objectives, single module changes, expanded tests, detailed second party review, etc). It should take less than half an hour and it's good for you (like vitamins). BTW, don't accept the patch until the new test suite runs on all platforms. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:22 Message: Logged In: YES user_id=357491 You sure you want me to check this after what happened last time I tried to "modernize" a module? =) OK, I will take a look. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:01 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Tue Jun 17 09:36:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 01:36:41 -0700 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply@sourceforge.net Tue Jun 17 13:06:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 05:06:16 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Tue Jun 17 13:59:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 05:59:55 -0700 Subject: [Patches] [ python-Patches-569574 ] plain text enhancement for cgitb Message-ID: Patches item #569574, was opened at 2002-06-15 23:46 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569574&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: plain text enhancement for cgitb Initial Comment: Here's a patch to cgitb that allows you to enable plain text output. It adds an extra variable to the cgitb.enable function and corresponding underlying functions. To get plain text invoke it as import cgitb cgitb.enable(format="text") (actually, any value for format other than "html" will enable plain text output). The default value is "html", so existing usage of cgitb should be unaffected. I realize this isn't quite what you suggested, but it seemed to me worthwhile to keep such similar code together. I'm not entirely certain I haven't fouled up the html formatting. It needs to be checked still. Also still to come is a doc change. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-06-17 07:59 Message: Logged In: YES user_id=44345 checked in as * cgitb.py 1.8 * Doc/lib/libcgitb.tex 1.4 * Misc/News 1.788 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-06-16 13:36 Message: Logged In: YES user_id=44345 Okay, I closed 654558 as a duplicate of this one. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-06-16 13:00 Message: Logged In: YES user_id=479934 proper location to my bug https://sourceforge.net/tracker/?func=detail&aid=654558&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-06-16 12:58 Message: Logged In: YES user_id=479934 http://mail.python.org/pipermail/python-dev/2003-June/036230.html the need for this is clear and longstanding. I filed a bug about this https://sourceforge.net/tracker/?group_id=5470&atid=105470 please remove it as i never found this bug im writing on before now I even later wrote the patch for myself. im sure ping's patch is better. I use this patch every day because it simply is flat out better than python's current error mechanism. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-02 12:45 Message: Logged In: YES user_id=44345 I started messing around with this, but quickly figured out I didn't know what "main routine" belongs in traceback. Moving lookup and scanvars there is no problem, but the rest of the functionality is almost entirely in the html() and text() routines. Do you mean they should go in traceback? ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-07-09 22:33 Message: Logged In: YES user_id=45338 I think enhanced text tracebacks would be great. (I even have my own hacked-up one lying around here somewhere -- it colourized the output. I think a part of me was waiting for an opportunity to make enhanced tracebacks standard. The most important enhancement IMHO is to show argument values.) I don't think the functionality belongs in cgitb, though. The main routine probably should go in traceback; the common routines (scanvars and lookup) can go there too. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-07-09 18:48 Message: Logged In: YES user_id=44345 Ping How about you? As the author I think you're in the best position to decide on the merits of the patch... Skip ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 22:36 Message: Logged In: YES user_id=6380 Unassigning -- I won't get to this before my vacation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-16 00:09 Message: Logged In: YES user_id=44345 Okay, here's a correction to the first patch. It fixes the logic bug that corrupted the HTML output. It also adds a little bit of extra documentation. Writing the documentation made me think that perhaps this should be added to the traceback module as Guido suggested with just a stub cgitb module that provides an enable function that calls the enable function in the traceback module with format="html". The cgitb module could then be deprecated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569574&group_id=5470 From noreply@sourceforge.net Tue Jun 17 14:06:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 06:06:17 -0700 Subject: [Patches] [ python-Patches-649742 ] urllib2.Request's headers are case-sens. Message-ID: Patches item #649742, was opened at 2002-12-06 21:26 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=649742&group_id=5470 Category: Library (Lib) >Group: Python 2.3 >Status: Open Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Brett Cannon (bcannon) Summary: urllib2.Request's headers are case-sens. Initial Comment: urllib2.Request's headers are case-sensitive. This is unfortunate if, for example, you add a content-type header like so: req = urllib2.Request("http://blah/", data, headers={"Content-Type": "text/ugly"}) because, while urllib2.AbstractHTTPHandler is careful to check not to add this header if it's already in the Request, it happens to use a different case convention: if not req.headers.has_key('Content-type'): h.putheader('Content-type', 'application/x-www-form-urlencoded') so you get both headers: Content-Type: text/ugly Content-type: application/x-www-form-urlencoded in essentially random order. The documentation says: """Note that there cannot be more than one header with the same name, and later calls will overwrite previous calls in case the key collides. Currently, this is no loss of functionality, since all headers which have meaning when used more than once have a (header-specific) way of gaining the same functionality using only one header.""" RFC 2616 (section 4.2) says: """The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.""" The patch fixes this by adding normalisation of header case to urllib.Request. With the patch, you'd get: Content-type: text/ugly John ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=261020 OpenerDirector.addheaders is another source of headers, on top of the ones provided by Request.headers and those hard-coded in AbstractHTTPHandler.do_open. These headers should be compared case- insensitively, just as the others are. The patch I just attached does this. Since all the other headers are .capitalize()d, this patch also changes the default value of addheaders back to "User-agent" (reversing patch 599836). This really needs to be fixed before 2.3 final. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 08:30 Message: Logged In: YES user_id=357491 Applied as urllib2.py 1.43. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 07:56 Message: Logged In: YES user_id=357491 OK, the idea of the patch was cleared. I will apply it some time this week. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 00:27 Message: Logged In: YES user_id=357491 OK, I fixed the 'items' calls in my local copy of the file. I am going to get someone to double-check this patch and if they give me the all-clear I will apply it. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-11 12:19 Message: Logged In: YES user_id=261020 I used iter rather than iteritems because that's what the rest of the module does, so maybe you want to look at the other 5 instances of that if you use iteritems. Otherwise, fine. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 07:06 Message: Logged In: YES user_id=357491 So the patch looks almost perfect. There are only two things that I would change. One is how you iterate over the dictionary. It is better to use header.iteritems than header.items . Second, I would not do the capitalization in __init__ directly. Instead, to match the expectation of the docs ("headers should be a dictionary, and will be treated as if add_header() was called with each key and value as arguments") you should just call self.add_header(k, v) in the loop. This will lower code redundency and if for some reason add_header is changed no one will have to worry about changing __init__ at the same time. But otherwise the patch looks good. I have uploaded a corrected version of the patch. Have a look and let me know that if it works for you. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 12:55 Message: Logged In: YES user_id=261020 Patch is attached (no doc changes required). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-10 00:46 Message: Logged In: YES user_id=357491 OK. If you can rewrite the patch then using capitalize I will take a look and decide whether to apply it or not. Also, if this will require changes to the docs please also include a patch for that. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 13:41 Message: Logged In: YES user_id=261020 Ooh, look at all those string methods I'd forgotten about. Yes, good idea, but name.capitalize() would be simpler and minutely more conservative (the module already uses that convention), hence better. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 02:38 Message: Logged In: YES user_id=357491 Do you think this would also work, John, if instead of having normalise_header_case you did name.title()? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-12-08 17:18 Message: Logged In: YES user_id=261020 Here it is. I swear I did check the box. I clicked the button twice, though -- I guess SF doesn't like that. John ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-07 08:43 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=305470&aid=649742&group_id=5470 From noreply@sourceforge.net Tue Jun 17 14:14:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 06:14:42 -0700 Subject: [Patches] [ python-Patches-755245 ] Modernize Lib/posixpath.py Message-ID: Patches item #755245, was opened at 2003-06-16 13:22 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Modernize Lib/posixpath.py Initial Comment: This patch modernizes posixpath: It uses startswith(), endswith(), rstrip() and struct_passwd attributes. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 15:14 Message: Logged In: YES user_id=89016 The patch looks OK. Checked in (with minor changes) as: Lib/posixpath.py 1.59 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 07:22 Message: Logged In: YES user_id=80475 According to tradition, Walter should apply the patch after checking to make sure he agrees with the changes. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-17 04:39 Message: Logged In: YES user_id=357491 OK, I have uploaded a new diff with some stuff more changes (Ha!). If no one complains by tomorrow about the new test_posixpath.py I will apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:31 Message: Logged In: YES user_id=357491 Geez, I step out to pick a friend up from the airport and you guys already revise the thing! And no, you are not deleting the new version. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 We could always delete the new version! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:44 Message: Logged In: YES user_id=80475 You're too quick. Brett was supposed to find that one. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:39 Message: Logged In: YES user_id=89016 There is missing += update in expandvars(). Uploading new version of the patch ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:13 Message: Logged In: YES user_id=80475 Yes. I've already checked it but wanted you to see the process of how it can be done reliably (clear objectives, single module changes, expanded tests, detailed second party review, etc). It should take less than half an hour and it's good for you (like vitamins). BTW, don't accept the patch until the new test suite runs on all platforms. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:22 Message: Logged In: YES user_id=357491 You sure you want me to check this after what happened last time I tried to "modernize" a module? =) OK, I will take a look. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:01 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755245&group_id=5470 From noreply@sourceforge.net Tue Jun 17 16:47:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 08:47:18 -0700 Subject: [Patches] [ python-Patches-755987 ] zipfile.py bug 755031; null byte in file name Message-ID: Patches item #755987, was opened at 2003-06-17 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755987&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile.py bug 755031; null byte in file name Initial Comment: This is a patch for Bug 755031: If a null byte appears in a file name, Python zipfile.py retains it, but InfoZip terminates the name. Null bytes in file names are used as a trick by viruses. I tested WinZip, and it also truncates the file name at the null byte. I am about 80% sure this patch is a good idea, but it does add a little more complexity. If the consensus is that virus files are not Python's problem, I won't be offended if it is rejected. It does seem useful to be consistent with WinZip and InfoZip. The patch also fixes a buglet: If a zipfile incorrectly uses a directory separator other than '/', there was an invalid complaint that the central directory name does not match the file header name. I also removed my name from the top of the file. It was there for legal reasons which I believe no longer apply. Many people have worked on this file besides me. I don't believe there should be a test for null bytes in the zipfile.py test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755987&group_id=5470 From noreply@sourceforge.net Tue Jun 17 16:53:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 08:53:36 -0700 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply@sourceforge.net Tue Jun 17 17:30:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 09:30:42 -0700 Subject: [Patches] [ python-Patches-756021 ] Allow socket.inet_aton("255.255.255.255") on Windows Message-ID: Patches item #756021, was opened at 2003-06-17 09:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756021&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Gertzfield (che_fox) Assigned to: Nobody/Anonymous (nobody) Summary: Allow socket.inet_aton("255.255.255.255") on Windows Initial Comment: Currently there's an XXX comment in socketmodule.c for the Windows implementation (actually, for any platform that doesn't have inet_aton) of socket.inet_aton: /* XXX Problem here: inet_aton('255.255.255.255') raises an exception while it should be a valid address. */ This patch (against Python CVS) fixes this problem by special-casing "255.255.255.255" as input when inet_addr returns -1 (usually an error). We just strcmp() the input string with "255.255.255.255" if inet_addr returned -1; if it matches, we allow PyString_FromStringAndSize() to do its thing on -1. Also, I noticed that the unit tests for module.inet_aton and friends were skipped if the platform didn't have inet_pton; this is an obvious error, and so I've split out the tests for inet_pton and inet_ntop's IPv4 functionality from inet_aton and inet_ntoa, as well as adding an explicit test for the now-handled "255.255.255.255" case. Finally, I haven't gotten CVS python to build on Windows under Visual Studio.NET (I get 'invalid project errors' when it tries to convert the VS6 project files -- and I don't have VS6) although I've tested this patch and the new tests on Debian Linux. This patch really should be applied to the 2.2 maintenance branch as well as 2.3, since "255.255.255.255" is a legal IP address and is not documented to raise an exception in the Python docs (even though it does currently on Windows). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756021&group_id=5470 From noreply@sourceforge.net Tue Jun 17 17:33:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 09:33:16 -0700 Subject: [Patches] [ python-Patches-756021 ] Allow socket.inet_aton("255.255.255.255") on Windows Message-ID: Patches item #756021, was opened at 2003-06-17 09:30 Message generated for change (Settings changed) made by che_fox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756021&group_id=5470 >Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Gertzfield (che_fox) Assigned to: Nobody/Anonymous (nobody) Summary: Allow socket.inet_aton("255.255.255.255") on Windows Initial Comment: Currently there's an XXX comment in socketmodule.c for the Windows implementation (actually, for any platform that doesn't have inet_aton) of socket.inet_aton: /* XXX Problem here: inet_aton('255.255.255.255') raises an exception while it should be a valid address. */ This patch (against Python CVS) fixes this problem by special-casing "255.255.255.255" as input when inet_addr returns -1 (usually an error). We just strcmp() the input string with "255.255.255.255" if inet_addr returned -1; if it matches, we allow PyString_FromStringAndSize() to do its thing on -1. Also, I noticed that the unit tests for module.inet_aton and friends were skipped if the platform didn't have inet_pton; this is an obvious error, and so I've split out the tests for inet_pton and inet_ntop's IPv4 functionality from inet_aton and inet_ntoa, as well as adding an explicit test for the now-handled "255.255.255.255" case. Finally, I haven't gotten CVS python to build on Windows under Visual Studio.NET (I get 'invalid project errors' when it tries to convert the VS6 project files -- and I don't have VS6) although I've tested this patch and the new tests on Debian Linux. This patch really should be applied to the 2.2 maintenance branch as well as 2.3, since "255.255.255.255" is a legal IP address and is not documented to raise an exception in the Python docs (even though it does currently on Windows). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756021&group_id=5470 From noreply@sourceforge.net Tue Jun 17 17:53:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 09:53:15 -0700 Subject: [Patches] [ python-Patches-756032 ] re reads an uninitialized memory Message-ID: Patches item #756032, was opened at 2003-06-18 01:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: re reads an uninitialized memory Initial Comment: With this script, re reads from an address beyond the end of the string. >>> import re >>> r = re.compile(r"\b1") >>> print r.search('a', 1) See assert() in the attached patch to see where incorrect memory reading occurs. This patch looks fix the problem, but I'm not sure this is correct answer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 From noreply@sourceforge.net Tue Jun 17 22:04:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 14:04:22 -0700 Subject: [Patches] [ python-Patches-751916 ] Handle keyboard interrupts in SSL module Message-ID: Patches item #751916, was opened at 2003-06-10 15:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751916&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Jacobs (jacobs99) Assigned to: Nobody/Anonymous (nobody) Summary: Handle keyboard interrupts in SSL module Initial Comment: As of Python 2.3 beta 1 (and current CVS), the SSL module does not check to see if a keyboard interrupt occurred after waiting on connections, reads, and writes. This results in long delays (seconds or even minutes) before the KeyboardInterrupt is finally raised, causing problematic pauses for interactive processes. This does not happen in Python 2.2.2, though I have not looked into what has changed. My next step is to look into httplib, the use-case that brought this to my attention, since some of the buffering code is not exception safe. i.e., a KeyboardInterrupt can cause data to be lost on subsequent reads. I suspect that it is also possible to lose data on due to socket timeouts as well, so I consider this issue a distinct bug. I did not include a new unit test, since it is a little tricky to produce. It requires a large SSL transfer and a network timing-sensitive threshold test to detect. Also included in the attached patch are some error handling fixes and cleanups related to time-out operations that I happened to notice. This module deserves more attention, since the timeout changes don't look like they were integrated as carefully as they could have been and other similar errors are possible. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-17 23:04 Message: Logged In: YES user_id=21627 The patch looks fine to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751916&group_id=5470 From noreply@sourceforge.net Tue Jun 17 22:35:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 14:35:14 -0700 Subject: [Patches] [ python-Patches-756253 ] itertools roundrobin() and window() Message-ID: Patches item #756253, was opened at 2003-06-17 17:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Nobody/Anonymous (nobody) Summary: itertools roundrobin() and window() Initial Comment: a patch to add the roundrobin() and window() objects to the itertools module. Hettinger has already seen the implementation of roundrobin, but not window. test_itertools.py in a seperate patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 From noreply@sourceforge.net Tue Jun 17 22:36:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 14:36:43 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Tue Jun 17 22:37:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 14:37:07 -0700 Subject: [Patches] [ python-Patches-756255 ] test_itertools for roundrobin() and window() Message-ID: Patches item #756255, was opened at 2003-06-17 17:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756255&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Nobody/Anonymous (nobody) Summary: test_itertools for roundrobin() and window() Initial Comment: patch to add test to Lib/test/test_itertools.py for roundrobin and window ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756255&group_id=5470 From noreply@sourceforge.net Tue Jun 17 22:53:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 14:53:00 -0700 Subject: [Patches] [ python-Patches-649742 ] urllib2.Request's headers are case-sens. Message-ID: Patches item #649742, was opened at 2002-12-06 13:26 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=649742&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Brett Cannon (bcannon) Summary: urllib2.Request's headers are case-sens. Initial Comment: urllib2.Request's headers are case-sensitive. This is unfortunate if, for example, you add a content-type header like so: req = urllib2.Request("http://blah/", data, headers={"Content-Type": "text/ugly"}) because, while urllib2.AbstractHTTPHandler is careful to check not to add this header if it's already in the Request, it happens to use a different case convention: if not req.headers.has_key('Content-type'): h.putheader('Content-type', 'application/x-www-form-urlencoded') so you get both headers: Content-Type: text/ugly Content-type: application/x-www-form-urlencoded in essentially random order. The documentation says: """Note that there cannot be more than one header with the same name, and later calls will overwrite previous calls in case the key collides. Currently, this is no loss of functionality, since all headers which have meaning when used more than once have a (header-specific) way of gaining the same functionality using only one header.""" RFC 2616 (section 4.2) says: """The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.""" The patch fixes this by adding normalisation of header case to urllib.Request. With the patch, you'd get: Content-type: text/ugly John ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-17 14:53 Message: Logged In: YES user_id=357491 Dont as revision 1.51 . ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-06-17 06:06 Message: Logged In: YES user_id=261020 OpenerDirector.addheaders is another source of headers, on top of the ones provided by Request.headers and those hard-coded in AbstractHTTPHandler.do_open. These headers should be compared case- insensitively, just as the others are. The patch I just attached does this. Since all the other headers are .capitalize()d, this patch also changes the default value of addheaders back to "User-agent" (reversing patch 599836). This really needs to be fixed before 2.3 final. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 00:30 Message: Logged In: YES user_id=357491 Applied as urllib2.py 1.43. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 23:56 Message: Logged In: YES user_id=357491 OK, the idea of the patch was cleared. I will apply it some time this week. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 16:27 Message: Logged In: YES user_id=357491 OK, I fixed the 'items' calls in my local copy of the file. I am going to get someone to double-check this patch and if they give me the all-clear I will apply it. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-11 04:19 Message: Logged In: YES user_id=261020 I used iter rather than iteritems because that's what the rest of the module does, so maybe you want to look at the other 5 instances of that if you use iteritems. Otherwise, fine. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-10 23:06 Message: Logged In: YES user_id=357491 So the patch looks almost perfect. There are only two things that I would change. One is how you iterate over the dictionary. It is better to use header.iteritems than header.items . Second, I would not do the capitalization in __init__ directly. Instead, to match the expectation of the docs ("headers should be a dictionary, and will be treated as if add_header() was called with each key and value as arguments") you should just call self.add_header(k, v) in the loop. This will lower code redundency and if for some reason add_header is changed no one will have to worry about changing __init__ at the same time. But otherwise the patch looks good. I have uploaded a corrected version of the patch. Have a look and let me know that if it works for you. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 04:55 Message: Logged In: YES user_id=261020 Patch is attached (no doc changes required). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 16:46 Message: Logged In: YES user_id=357491 OK. If you can rewrite the patch then using capitalize I will take a look and decide whether to apply it or not. Also, if this will require changes to the docs please also include a patch for that. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 05:41 Message: Logged In: YES user_id=261020 Ooh, look at all those string methods I'd forgotten about. Yes, good idea, but name.capitalize() would be simpler and minutely more conservative (the module already uses that convention), hence better. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 18:38 Message: Logged In: YES user_id=357491 Do you think this would also work, John, if instead of having normalise_header_case you did name.title()? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-12-08 09:18 Message: Logged In: YES user_id=261020 Here it is. I swear I did check the box. I clicked the button twice, though -- I guess SF doesn't like that. John ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-07 00:43 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=305470&aid=649742&group_id=5470 From noreply@sourceforge.net Wed Jun 18 00:49:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 16:49:29 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 18:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 16:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 07:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 16:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 13:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Wed Jun 18 02:07:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 18:07:58 -0700 Subject: [Patches] [ python-Patches-755987 ] zipfile.py bug 755031; null byte in file name Message-ID: Patches item #755987, was opened at 2003-06-17 11:47 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755987&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile.py bug 755031; null byte in file name Initial Comment: This is a patch for Bug 755031: If a null byte appears in a file name, Python zipfile.py retains it, but InfoZip terminates the name. Null bytes in file names are used as a trick by viruses. I tested WinZip, and it also truncates the file name at the null byte. I am about 80% sure this patch is a good idea, but it does add a little more complexity. If the consensus is that virus files are not Python's problem, I won't be offended if it is rejected. It does seem useful to be consistent with WinZip and InfoZip. The patch also fixes a buglet: If a zipfile incorrectly uses a directory separator other than '/', there was an invalid complaint that the central directory name does not match the file header name. I also removed my name from the top of the file. It was there for legal reasons which I believe no longer apply. Many people have worked on this file besides me. I don't believe there should be a test for null bytes in the zipfile.py test suite. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2003-06-17 21:07 Message: Logged In: YES user_id=14422 Thanks Jim! Your patch works for me, and the test still passes. I've checked it in on the trunk (rev 1.29, 1.30) and backported it to release22-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755987&group_id=5470 From noreply@sourceforge.net Wed Jun 18 02:32:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 18:32:56 -0700 Subject: [Patches] [ python-Patches-751038 ] Bug fix 750092: exec doesn't need newline Message-ID: Patches item #751038, was opened at 2003-06-08 15:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751038&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Bug fix 750092: exec doesn't need newline Initial Comment: See bug 750092. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 20:32 Message: Logged In: YES user_id=80475 Applied as Doc/ref/ref6.tex 1.66 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751038&group_id=5470 From noreply@sourceforge.net Wed Jun 18 04:13:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 20:13:41 -0700 Subject: [Patches] [ python-Patches-755660 ] allow HTMLParser to continue after a parse error Message-ID: Patches item #755660, was opened at 2003-06-17 02:27 Message generated for change (Comment added) made by smroid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755660&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Rosenthal (smroid) Assigned to: Nobody/Anonymous (nobody) Summary: allow HTMLParser to continue after a parse error Initial Comment: The HTMLParser.error method raises HTMLParseError, terminating the parse upon detection of a parse error. This patch is to allow HTMLParser to continue parsing if the error() method is overridden to not throw an exception. Doc impact is on the error() method. The existing test_htmlparser.py unit test is unaffected by the patch. The base file is HTMLParser.py, revision 1.11.2.1 ---------------------------------------------------------------------- >Comment By: Steven Rosenthal (smroid) Date: 2003-06-18 03:13 Message: Logged In: YES user_id=159908 this fixes bug #736428 (submitted by me earlier) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755660&group_id=5470 From noreply@sourceforge.net Wed Jun 18 04:22:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2003 20:22:20 -0700 Subject: [Patches] [ python-Patches-755670 ] improve HTMLParser attribute processing regexps Message-ID: Patches item #755670, was opened at 2003-06-17 03:09 Message generated for change (Comment added) made by smroid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Rosenthal (smroid) Assigned to: Nobody/Anonymous (nobody) Summary: improve HTMLParser attribute processing regexps Initial Comment: HTML examples seen in the wild that cause parse errors in HTMLParser include: -- note lack of space between val and next attr name -- trailing attribute has no value after = -- javascript fragment with embedded quotes My patch contains improvements to the 'attrfind' and 'locatestarttagend' regexps that allow these examples to parse. The existing test_htmlparser.py unit test continues to pass, except for the one test case where it considers to be an error. I commented out that case and added new test cases to cover the examples above. ---------------------------------------------------------------------- >Comment By: Steven Rosenthal (smroid) Date: 2003-06-18 03:22 Message: Logged In: YES user_id=159908 This also fixes bugs 683938 and 699079. ---------------------------------------------------------------------- Comment By: Steven Rosenthal (smroid) Date: 2003-06-17 03:10 Message: Logged In: YES user_id=159908 Base version for HTMLParser.py is 1.11.2.1; base version for test_htmlparser.py is 1.8.8.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470 From noreply@sourceforge.net Wed Jun 18 15:27:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 18 Jun 2003 07:27:11 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Wed Jun 18 20:48:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 18 Jun 2003 12:48:48 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 14:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-18 09:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 18:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 16:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 07:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 16:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 13:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Wed Jun 18 21:11:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 18 Jun 2003 13:11:41 -0700 Subject: [Patches] [ python-Patches-756253 ] itertools roundrobin() and window() Message-ID: Patches item #756253, was opened at 2003-06-17 16:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jack Diederich (jackdied) >Assigned to: Raymond Hettinger (rhettinger) Summary: itertools roundrobin() and window() Initial Comment: a patch to add the roundrobin() and window() objects to the itertools module. Hettinger has already seen the implementation of roundrobin, but not window. test_itertools.py in a seperate patch ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 15:11 Message: Logged In: YES user_id=80475 *Please post the tests to this patch and close the other patch. *Add a documentation patch to this patch *Let's drop the addition of window(). The C code for it is less than beautiful and offers only a minimal performance gain over the pure python equivalent. I've added the pure python version to the docs so folks can cut and paste it if they need it. Sorry for the wild goose chase (I had expected the C version to be much cleaner and faster and that the python verions would've been harder -- actual code was needed for me to see it). * In roundrobin_next(), replace the % operator with: if (lz->iternum==lz->itersize) lz-iternum=0; * In roundrobin_next(), remove the extra blank line following "long listsize;" * Fixup the indentation, currently it is a mix of spaces and tabs. It should be just pure tabs. * Replace the variable name 'lz' with 'rr'. I should have changed that in other places too but for new code it should be fixed. * 'unti' is mispelled in the docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 From noreply@sourceforge.net Thu Jun 19 03:49:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 18 Jun 2003 19:49:38 -0700 Subject: [Patches] [ python-Patches-756996 ] Bare except in ZipFile.testzip() Message-ID: Patches item #756996, was opened at 2003-06-18 20:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756996&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Bare except in ZipFile.testzip() Initial Comment: ZipFile.testzip tries to call self.read, and reports the first file in the archive for which this raises an exception. Since a bare except is used, way too many kinds of exception are caught. This causes weirdness such as >>> import zipfile >>> z = zipfile.ZipFile('foo.zip') >>> z.close() >>> z.testzip() 'nt.to.png' When the ZipFile has been closed, .read raises a RuntimeError; .testzip reports this as a problem with the first file in the archive, which is misleading in the extreme. Propagating the RuntimeError would be better. Similarly IOErrors while reading the file are swallowed, as are KeyboardInterrupts, SystemExits, RuntimeErrors due to the absence of zlib... The patch changes the except clause to catch only BadZipfile, which is explicitly raised in .read for checksum failures. The docs indicate that that's what .testzip tests. (This exception is also raised for unsupported compression methods. I'm not sure how .testzip should treat those; perhaps the two conditions should have different exception types.) (A different bare except in this module received attention in bug 411881.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756996&group_id=5470 From noreply@sourceforge.net Thu Jun 19 08:08:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 19 Jun 2003 00:08:56 -0700 Subject: [Patches] [ python-Patches-757058 ] Modernize Lib/posixpath.py again Message-ID: Patches item #757058, was opened at 2003-06-19 11:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757058&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: Modernize Lib/posixpath.py again Initial Comment: expanduser(): while => str.find() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757058&group_id=5470 From noreply@sourceforge.net Thu Jun 19 10:46:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 19 Jun 2003 02:46:20 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Thu Jun 19 11:22:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 19 Jun 2003 03:22:48 -0700 Subject: [Patches] [ python-Patches-757058 ] Modernize Lib/posixpath.py again Message-ID: Patches item #757058, was opened at 2003-06-19 09:08 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757058&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: Modernize Lib/posixpath.py again Initial Comment: expanduser(): while => str.find() ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-19 12:22 Message: Logged In: YES user_id=89016 Checked in (with slight modifications) as Lib/posixpath.py 1.60 Lib/test/test_posixpath.py 1.7 Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757058&group_id=5470 From noreply@sourceforge.net Thu Jun 19 14:42:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 19 Jun 2003 06:42:22 -0700 Subject: [Patches] [ python-Patches-757229 ] libsocket.tex typo Message-ID: Patches item #757229, was opened at 2003-06-19 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757229&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: libsocket.tex typo Initial Comment: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757229&group_id=5470 From noreply@sourceforge.net Thu Jun 19 22:32:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 19 Jun 2003 14:32:01 -0700 Subject: [Patches] [ python-Patches-644920 ] Build _tkinter in setup.jaguar.py Message-ID: Patches item #644920, was opened at 2002-11-27 20:55 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=644920&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Postponed Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: Build _tkinter in setup.jaguar.py Initial Comment: The attached patch builds the _tkinter module, if Tk.framework or Tcl.framework are found. The appropriate binary installer for those framworks is here: http://prdownloads.sourceforge.net/tcl/TclTkAqua-8.4.1-Jaguar.dmg?download ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-06-19 23:32 Message: Logged In: YES user_id=45365 I'm afraid that building the 2.3 Mac stuff on top of a 2.2 /usr/bin/ python has moved beyond my horizon. I'm setting the status to "postponed", just in case the project is ever revived (depending on what Python version will be in 10.3 and other issues). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=644920&group_id=5470 From noreply@sourceforge.net Fri Jun 20 02:42:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 19 Jun 2003 18:42:32 -0700 Subject: [Patches] [ python-Patches-757624 ] Fixing recursive problem in SRE Message-ID: Patches item #757624, was opened at 2003-06-20 01:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757624&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Fixing recursive problem in SRE Initial Comment: Here is a preview for the SRE change being discussed in python-dev mailing list. It also includes the changes in patch #572936 (groupref_exists). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757624&group_id=5470 From noreply@sourceforge.net Fri Jun 20 18:12:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 20 Jun 2003 10:12:11 -0700 Subject: [Patches] [ python-Patches-757229 ] libsocket.tex typo Message-ID: Patches item #757229, was opened at 2003-06-19 09:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757229&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Neal Norwitz (nnorwitz) Summary: libsocket.tex typo Initial Comment: ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 13:12 Message: Logged In: YES user_id=33168 Thanks, checked in as libsocket.tex 1.74 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757229&group_id=5470 From noreply@sourceforge.net Fri Jun 20 20:26:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 20 Jun 2003 12:26:00 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 14:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-19 04:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 14:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-18 09:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 18:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 16:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 07:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 16:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 13:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Fri Jun 20 22:23:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 20 Jun 2003 14:23:15 -0700 Subject: [Patches] [ python-Patches-757997 ] Using __slots__ with str derived classes can cause segfault Message-ID: Patches item #757997, was opened at 2003-06-20 12:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757997&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 7 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Using __slots__ with str derived classes can cause segfault Initial Comment: The following results in a segfault on Linux with 2.3b1: ------------------------- class StringDerived(str): __slots__ = ['a'] def __init__(self, string): str.__init__(self, string) self.a = 1 class DerivedAgain(StringDerived): pass o = DerivedAgain('hello world') o.b = 2 -------------------------- Python 2.2.2 raises a TypeError when attempting to derive a class from str with a non-empty __slots__, maybe 2.3 should do the same? I have no use case for deriving from str and defining __slots__; I encountered the bug when writing test cases for a debugger. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 17:23 Message: Logged In: YES user_id=33168 I think the problem is that strings are variable length. clear_slots() doesn't handle this condtion. The attached patch fixes the crash and works fine under valgrind, but I'm not entirely sure it's correct. Hopefully someone more familiar with the TypeObject code can review this. I'll add a test later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 13:18 Message: Logged In: YES user_id=33168 unicode, list, and dict don't crash, only string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757997&group_id=5470 From noreply@sourceforge.net Fri Jun 20 23:05:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 20 Jun 2003 15:05:20 -0700 Subject: [Patches] [ python-Patches-757997 ] Using __slots__ with str derived classes can cause segfault Message-ID: Patches item #757997, was opened at 2003-06-20 12:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757997&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Using __slots__ with str derived classes can cause segfault Initial Comment: The following results in a segfault on Linux with 2.3b1: ------------------------- class StringDerived(str): __slots__ = ['a'] def __init__(self, string): str.__init__(self, string) self.a = 1 class DerivedAgain(StringDerived): pass o = DerivedAgain('hello world') o.b = 2 -------------------------- Python 2.2.2 raises a TypeError when attempting to derive a class from str with a non-empty __slots__, maybe 2.3 should do the same? I have no use case for deriving from str and defining __slots__; I encountered the bug when writing test cases for a debugger. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 18:05 Message: Logged In: YES user_id=33168 Ain't testing grand. Found a couple more problems. Patch 2 is better, but I'm still not sure it's complete or correct. I'm thinking the slot offset should be fixed when it's set, rather than at each usage of the slot offset. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 17:23 Message: Logged In: YES user_id=33168 I think the problem is that strings are variable length. clear_slots() doesn't handle this condtion. The attached patch fixes the crash and works fine under valgrind, but I'm not entirely sure it's correct. Hopefully someone more familiar with the TypeObject code can review this. I'll add a test later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 13:18 Message: Logged In: YES user_id=33168 unicode, list, and dict don't crash, only string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757997&group_id=5470 From noreply@sourceforge.net Sat Jun 21 14:27:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2003 06:27:30 -0700 Subject: [Patches] [ python-Patches-736413 ] DESTDIR improvement Message-ID: Patches item #736413, was opened at 2003-05-12 12:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736413&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: DESTDIR improvement Initial Comment: Byte compile correctly with DESTDIR. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 15:27 Message: Logged In: YES user_id=21627 The patch is incorrect: setting -d to DESTDIR will cause DESTDIR to be hard-coded. Correct is to use LIBDEST, committed as Makefile.pre.in 1.134 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-05-19 11:51 Message: Logged In: YES user_id=192186 I forgot to mention, that the patch was larger before, but I saw many simmilar things applied in CVS, so this _should_ work with CVS version. However I will test it today... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-16 23:42 Message: Logged In: YES user_id=21627 Please test this on your machine. The byte code of __init__.py will still point to /home/users/user/tmp/python-2.3b1-root-user/usr/lib/python2.3/logging/__init__.py with your patch applied. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2003-05-16 10:52 Message: Logged In: YES user_id=387193 A simple test, to describe the problem, below. DESTDIR is set to "/home/users/user/tmp/python-2.3b1-root-user". ----------------- import logging class X: pass logging.setLoggerClass(X) ------------------- Code above gives following exception: Traceback (most recent call last): File "tracedir.py", line 6, in ? logging.setLoggerClass(X) File "/home/users/user/tmp/python-2.3b1-root-user/usr/lib/python2.3/logging/__init__.py", line 729, in setLoggerClass TypeError: logger not derived from logging.Logger: X I _suppose_ that, after applying the patch the exception will look like: Traceback (most recent call last): File "tracedir.py", line 6, in ? logging.setLoggerClass(X) File "/usr/lib/python2.3/logging/__init__.py", line 729, in setLoggerClass TypeError: logger not derived from logging.Logger: X There will be no DESTDIR part in the module filepath. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-16 08:09 Message: Logged In: YES user_id=21627 What is the rationale of this patch? If I set DESTDIR to, say, /tmp/py, why is passing -d /tmp/py to compileall desirable? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736413&group_id=5470 From noreply@sourceforge.net Sat Jun 21 14:30:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2003 06:30:49 -0700 Subject: [Patches] [ python-Patches-756032 ] re reads an uninitialized memory Message-ID: Patches item #756032, was opened at 2003-06-17 18:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: re reads an uninitialized memory Initial Comment: With this script, re reads from an address beyond the end of the string. >>> import re >>> r = re.compile(r"\b1") >>> print r.search('a', 1) See assert() in the attached patch to see where incorrect memory reading occurs. This patch looks fix the problem, but I'm not sure this is correct answer. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 15:30 Message: Logged In: YES user_id=21627 Gustavo, can your review this code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 From noreply@sourceforge.net Sat Jun 21 14:33:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2003 06:33:16 -0700 Subject: [Patches] [ python-Patches-755677 ] 755617: better docs for os.chmod Message-ID: Patches item #755677, was opened at 2003-06-17 05:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Nobody/Anonymous (nobody) Summary: 755617: better docs for os.chmod Initial Comment: As per the discussion thread on c.l.p and summarized by Matthew Shomphe ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 15:33 Message: Logged In: YES user_id=21627 Can you give the rationale for this change, for those of us that don't know which thread you are referring to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 From noreply@sourceforge.net Sat Jun 21 14:40:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2003 06:40:30 -0700 Subject: [Patches] [ python-Patches-755683 ] 700827: Compiler Limits (indentation) Message-ID: Patches item #755683, was opened at 2003-06-17 06:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755683&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Nobody/Anonymous (nobody) Summary: 700827: Compiler Limits (indentation) Initial Comment: Add docs to state that certain platforms have different max indentation levels, and that should be noted by the developer. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 15:40 Message: Logged In: YES user_id=21627 Thanks, committed as ref2.tex 1.48 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755683&group_id=5470 From noreply@sourceforge.net Sat Jun 21 15:05:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2003 07:05:49 -0700 Subject: [Patches] [ python-Patches-736417 ] Put DEFS back to Makefile.pre.in Message-ID: Patches item #736417, was opened at 2003-05-12 12:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736417&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Put DEFS back to Makefile.pre.in Initial Comment: Put DEFS back to Makefile.pre.in because some modules use this for configuration.... ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 16:05 Message: Logged In: YES user_id=21627 I see. I reject this patch: pybibliographer will have to adjust. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-05-19 11:48 Message: Logged In: YES user_id=192186 AFAIK it was pybliographer ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-16 08:10 Message: Logged In: YES user_id=21627 Which modules? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736417&group_id=5470 From noreply@sourceforge.net Sat Jun 21 15:08:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2003 07:08:36 -0700 Subject: [Patches] [ python-Patches-645382 ] Don't FPE on FreeBSD... Message-ID: Patches item #645382, was opened at 2002-11-28 19:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645382&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: Don't FPE on FreeBSD... Initial Comment: --- Python-2.2.2/Objects/floatobject.c Sun May 12 17:20:38 2002 +++ Python-2.2.2-ben/Objects/floatobject.c Thu Nov 28 18:25:04 2002 @@ -645,7 +645,7 @@ long aslong; /* (long)wholepart */ (void)modf(x, &wholepart); -#ifdef RISCOS +#if defined(RISCOS) || defined(__FreeBSD__) /* conversion from floating to integral type would raise exception */ if (wholepart>LONG_MAX || wholepartComment By: Martin v. Löwis (loewis) Date: 2003-06-21 16:08 Message: Logged In: YES user_id=21627 Since there has been no follow-up, I conclude that Ben is happy with the current code as-is. Rejecting this patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-13 04:43 Message: Logged In: YES user_id=31435 CVS Python later grew a single patch to python.c that turns off FreeBSD's non-standard exception behavior before Py_Main is called. We don't want #ifdef ugliness spreading all over the core. It only turns off one of FreeBSD's oddball behaviors, though, so without more info from the FP we can't know whether or not it address all the problems he saw. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:30 Message: Logged In: YES user_id=33168 Ben it's not clear to me if this should be applied to 2.3 and/or 2.2.2. Can you clarify what the problem is and which version(s) of FreeBSD have the problem. I tested the current CVS version on FreeBSD 4.7 (in the SF compile farm) and did not have any unexpected errors. Can you add a patch with tests too? ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-01 00:03 Message: Logged In: YES user_id=14333 In current CVS the problem is fixed, but others have been introduced. The enclosed patch fixes the FPE problems found so far. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 07:31 Message: Logged In: YES user_id=31435 Please try current CVS and see whether the problem is already fixed there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645382&group_id=5470 From noreply@sourceforge.net Sat Jun 21 15:15:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2003 07:15:55 -0700 Subject: [Patches] [ python-Patches-640236 ] zlib.decompressobj under-described. Message-ID: Patches item #640236, was opened at 2002-11-18 19:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=640236&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) 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: Martin v. Löwis (loewis) Date: 2003-06-21 16:15 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as libzlib.tex 1.28. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-22 05:39 Message: Logged In: YES user_id=357491 I don't see much of a difference between the current docs for unused_data and the ones Scott posted here. unused_tail does seem to be more informative. I have no issue addding the extra info that Scott added in his version. Anyone else think it is worth adding? Since the comment basically has a patch, I am making this tracker item a patch. ---------------------------------------------------------------------- Comment By: Scott David Daniels (scott_daniels) Date: 2002-12-12 18: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=305470&aid=640236&group_id=5470 From noreply@sourceforge.net Sun Jun 22 00:28:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2003 16:28:45 -0700 Subject: [Patches] [ python-Patches-756032 ] re reads an uninitialized memory Message-ID: Patches item #756032, was opened at 2003-06-17 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re reads an uninitialized memory Initial Comment: With this script, re reads from an address beyond the end of the string. >>> import re >>> r = re.compile(r"\b1") >>> print r.search('a', 1) See assert() in the attached patch to see where incorrect memory reading occurs. This patch looks fix the problem, but I'm not sure this is correct answer. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-21 23:28 Message: Logged In: YES user_id=7887 Atsuo, can you please describe what problem you're trying to fix!? In other words, can you provide some code which breaks SRE? Your assertion doesn't seem to make sense in this place, since having ptr outside the boundaries of beginning/end *is* accepted. Notice how "ptr < state->end" is checked before using ptr[0]. I'm closing this bug as invalid. If you have something you belive to prove there's a bug in this place, please reopen this bug. Thank you very much for taking the time to fill this bug. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 13:30 Message: Logged In: YES user_id=21627 Gustavo, can your review this code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 From noreply@sourceforge.net Sun Jun 22 02:13:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2003 18:13:37 -0700 Subject: [Patches] [ python-Patches-757624 ] Fixing recursive problem in SRE Message-ID: Patches item #757624, was opened at 2003-06-20 01:42 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757624&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Fixing recursive problem in SRE Initial Comment: Here is a preview for the SRE change being discussed in python-dev mailing list. It also includes the changes in patch #572936 (groupref_exists). ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-22 01:13 Message: Logged In: YES user_id=7887 Updated version of the patch. More on the mailing list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757624&group_id=5470 From noreply@sourceforge.net Sun Jun 22 03:14:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2003 19:14:22 -0700 Subject: [Patches] [ python-Patches-756032 ] re reads an uninitialized memory Message-ID: Patches item #756032, was opened at 2003-06-18 01:53 Message generated for change (Comment added) made by ishimoto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 Category: Modules Group: None >Status: Open Resolution: Invalid Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re reads an uninitialized memory Initial Comment: With this script, re reads from an address beyond the end of the string. >>> import re >>> r = re.compile(r"\b1") >>> print r.search('a', 1) See assert() in the attached patch to see where incorrect memory reading occurs. This patch looks fix the problem, but I'm not sure this is correct answer. ---------------------------------------------------------------------- >Comment By: atsuo ishimoto (ishimoto) Date: 2003-06-22 11:14 Message: Logged In: YES user_id=463672 Sorry for my lack of infomation. While ptr outside the boundaries is legal, but fetching from there is not. One example of problem is using SRE for mmap object. This script causes an application error under my w2k box. open("tstfile", "wb").write('a'*4096) import mmap f = open("tstfile", "rb") xx = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) import re r = re.compile(r"\b1") r.search(xx, len(xx)) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-22 08:28 Message: Logged In: YES user_id=7887 Atsuo, can you please describe what problem you're trying to fix!? In other words, can you provide some code which breaks SRE? Your assertion doesn't seem to make sense in this place, since having ptr outside the boundaries of beginning/end *is* accepted. Notice how "ptr < state->end" is checked before using ptr[0]. I'm closing this bug as invalid. If you have something you belive to prove there's a bug in this place, please reopen this bug. Thank you very much for taking the time to fill this bug. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 22:30 Message: Logged In: YES user_id=21627 Gustavo, can your review this code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 From noreply@sourceforge.net Sun Jun 22 18:15:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 22 Jun 2003 10:15:22 -0700 Subject: [Patches] [ python-Patches-721464 ] Remote debugging with pdb.py Message-ID: Patches item #721464, was opened at 2003-04-14 18:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pelecq (lpelecq) >Assigned to: Nobody/Anonymous (nobody) Summary: Remote debugging with pdb.py Initial Comment: With this patch, instances of pdb.Pdb can read and write from arbitrary file objects. It is based on similar changes that have been made to cmd.py. It basically consists of replacing print statement with calls to self.stdout.write. So it is possible for example to control the debugger from another terminal to debug curses-based applications or CGI scripts. I can provide a basic client/server debugger. This patch has been tested on Mandrake Linux 9.1 with the current CVS version. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-22 12:15 Message: Logged In: YES user_id=80475 I think this is a good idea. It is past the the time for being added to 2.3. Unassigning, but will come back to it for 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&group_id=5470 From noreply@sourceforge.net Sun Jun 22 21:33:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 22 Jun 2003 13:33:15 -0700 Subject: [Patches] [ python-Patches-756032 ] re reads an uninitialized memory Message-ID: Patches item #756032, was opened at 2003-06-17 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 Category: Modules Group: None Status: Open Resolution: Invalid Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re reads an uninitialized memory Initial Comment: With this script, re reads from an address beyond the end of the string. >>> import re >>> r = re.compile(r"\b1") >>> print r.search('a', 1) See assert() in the attached patch to see where incorrect memory reading occurs. This patch looks fix the problem, but I'm not sure this is correct answer. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-22 20:33 Message: Logged In: YES user_id=7887 Now I can see the problem. The current test doesn't contemplate a broken ptr/end pair. Your code is addressing the right problem, but the right way to fix this seems to be to avoid that branch completely, unless pattern[3] > 1 (unlike the current > 0). Thank you very much for your patch and your insistence! ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-06-22 02:14 Message: Logged In: YES user_id=463672 Sorry for my lack of infomation. While ptr outside the boundaries is legal, but fetching from there is not. One example of problem is using SRE for mmap object. This script causes an application error under my w2k box. open("tstfile", "wb").write('a'*4096) import mmap f = open("tstfile", "rb") xx = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) import re r = re.compile(r"\b1") r.search(xx, len(xx)) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-21 23:28 Message: Logged In: YES user_id=7887 Atsuo, can you please describe what problem you're trying to fix!? In other words, can you provide some code which breaks SRE? Your assertion doesn't seem to make sense in this place, since having ptr outside the boundaries of beginning/end *is* accepted. Notice how "ptr < state->end" is checked before using ptr[0]. I'm closing this bug as invalid. If you have something you belive to prove there's a bug in this place, please reopen this bug. Thank you very much for taking the time to fill this bug. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 13:30 Message: Logged In: YES user_id=21627 Gustavo, can your review this code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 From noreply@sourceforge.net Sun Jun 22 22:56:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 22 Jun 2003 14:56:05 -0700 Subject: [Patches] [ python-Patches-758910 ] add thread flags to CXX, too (fixes build on FreeBSD) Message-ID: Patches item #758910, was opened at 2003-06-22 23:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=758910&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: add thread flags to CXX, too (fixes build on FreeBSD) Initial Comment: FreeBSD 5.x fails to link Modules/ccpython.cc: Python/thread_pthread.h:217: undefined reference to `pthread_create' Python/thread_pthread.h:253: undefined reference to `pthread_detach' The attached patch tests of the detected CC threads flag (-pthread, -kthread, -Kpthread or none) also works for CXX. This fixes the above error for FreeBSD 5.x. (Tested on today's -current with today's Python 2.3/cvs.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=758910&group_id=5470 From noreply@sourceforge.net Mon Jun 23 00:06:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 22 Jun 2003 16:06:05 -0700 Subject: [Patches] [ python-Patches-720329 ] Patch to make shlex accept escaped quotes in strings. Message-ID: Patches item #720329, was opened at 2003-04-12 18:41 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720329&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to make shlex accept escaped quotes in strings. Initial Comment: Shlex currently has no way to escape quoting characters within strings. This fixes that. No test is provided, but I'll be willing to write a test module to test this and the other basic behavior of the shlex module. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-22 23:06 Message: Logged In: YES user_id=7887 Jeremy, shlex.py has been extended to support posix-mode parsing in 2.3. This should include support for escapings and other goodies, similar to shells. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720329&group_id=5470 From noreply@sourceforge.net Mon Jun 23 12:49:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 23 Jun 2003 04:49:50 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 23 12:50:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 23 Jun 2003 04:50:10 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 23 14:03:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 23 Jun 2003 06:03:54 -0700 Subject: [Patches] [ python-Patches-758910 ] add thread flags to CXX, too (fixes build on FreeBSD) Message-ID: Patches item #758910, was opened at 2003-06-23 07:56 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=758910&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) >Assigned to: Martin v. Löwis (loewis) Summary: add thread flags to CXX, too (fixes build on FreeBSD) Initial Comment: FreeBSD 5.x fails to link Modules/ccpython.cc: Python/thread_pthread.h:217: undefined reference to `pthread_create' Python/thread_pthread.h:253: undefined reference to `pthread_detach' The attached patch tests of the detected CC threads flag (-pthread, -kthread, -Kpthread or none) also works for CXX. This fixes the above error for FreeBSD 5.x. (Tested on today's -current with today's Python 2.3/cvs.) ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-23 23:03 Message: Logged In: YES user_id=250749 tests Ok on both FreeBSD 4.8 (which was Ok without the patch) and FreeBSD 5.1. If applied, bug #745320 can be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=758910&group_id=5470 From noreply@sourceforge.net Mon Jun 23 14:06:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 23 Jun 2003 06:06:50 -0700 Subject: [Patches] [ python-Patches-757624 ] Fixing recursive problem in SRE Message-ID: Patches item #757624, was opened at 2003-06-20 11:42 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757624&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Fixing recursive problem in SRE Initial Comment: Here is a preview for the SRE change being discussed in python-dev mailing list. It also includes the changes in patch #572936 (groupref_exists). ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-23 23:06 Message: Logged In: YES user_id=250749 version 3 of the patch survives a full regression test run on both FreeBSD 4.8 & 5.1, with USE_RECURSION_LIMIT reverted to 10000. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-22 11:13 Message: Logged In: YES user_id=7887 Updated version of the patch. More on the mailing list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757624&group_id=5470 From noreply@sourceforge.net Mon Jun 23 14:10:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 23 Jun 2003 06:10:23 -0700 Subject: [Patches] [ python-Patches-749830 ] allow UNIX mmap size to default to current file size Message-ID: Patches item #749830, was opened at 2003-06-06 08:02 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749830&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: allow UNIX mmap size to default to current file size Initial Comment: This patch makes the UNIX mmap behave like the Windows mmap in that if you pass 0 as the mmap size, the map size will default to the current length of the file being mmapped. This allows avoids a call to os.stat if you want to map the entire file. It also makes code using this feature of the Windows mmap to be portable to UNIX. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-23 23:10 Message: Logged In: YES user_id=250749 Tested on FreeBSD 4.8 & 5.1 - updated test_mmap passes. I don't have any mmap reliant code to check more thoroughly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749830&group_id=5470 From noreply@sourceforge.net Mon Jun 23 14:13:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 23 Jun 2003 06:13:26 -0700 Subject: [Patches] [ python-Patches-755683 ] 700827: Compiler Limits (indentation) Message-ID: Patches item #755683, was opened at 2003-06-16 23:05 Message generated for change (Comment added) made by blunck2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755683&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Nobody/Anonymous (nobody) Summary: 700827: Compiler Limits (indentation) Initial Comment: Add docs to state that certain platforms have different max indentation levels, and that should be noted by the developer. ---------------------------------------------------------------------- >Comment By: Christopher Blunck (blunck2) Date: 2003-06-23 08:13 Message: Logged In: YES user_id=531881 Thanks Martin. -c ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 08:40 Message: Logged In: YES user_id=21627 Thanks, committed as ref2.tex 1.48 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755683&group_id=5470 From noreply@sourceforge.net Mon Jun 23 14:14:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 23 Jun 2003 06:14:32 -0700 Subject: [Patches] [ python-Patches-759208 ] curses has_key emulation fix Message-ID: Patches item #759208, was opened at 2003-06-23 07:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=759208&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mats Wichmann (mwichmann) Assigned to: Nobody/Anonymous (nobody) Summary: curses has_key emulation fix Initial Comment: curses/has_key.py provides emulation for the ncurses has_key routine for those that don't have it. Out-of- range has_key requests cause a KeyError exception. Note that the curses regression test makes such a request! The attached trivial patch makes has_key more robust. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=759208&group_id=5470 From noreply@sourceforge.net Mon Jun 23 14:38:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 23 Jun 2003 06:38:35 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 08:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-23 06:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 14:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-19 04:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 14:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-18 09:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 18:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 16:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 07:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 16:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 13:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Mon Jun 23 14:12:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 23 Jun 2003 06:12:39 -0700 Subject: [Patches] [ python-Patches-755677 ] 755617: better docs for os.chmod Message-ID: Patches item #755677, was opened at 2003-06-16 22:35 Message generated for change (Comment added) made by blunck2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Nobody/Anonymous (nobody) Summary: 755617: better docs for os.chmod Initial Comment: As per the discussion thread on c.l.p and summarized by Matthew Shomphe ---------------------------------------------------------------------- >Comment By: Christopher Blunck (blunck2) Date: 2003-06-23 08:12 Message: Logged In: YES user_id=531881 Sure- According to the discussion here: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=mailman.1055808030.15325.python-list%40python.org&rnum=1&prev=/groups%3Fq%3Dos.chmod%2Bgroup:comp.lang.python.*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.python.*%26selm%3Dmailman.1055808030.15325.python-list%2540python.org%26rnum%3D1 there was confusion as the behavior of os.chmod() on non-Unix platforms. Discussion led to a recommendation for a documentation change, which was submitted as an attachment to the bug report located here: http://www.python.org/sf/755617 The submitter of the bug report didn't know how to submit a patch. I decided to capture the documentation, add it to the appropriate tex file, produce a patch, and submit it to sf. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 08:33 Message: Logged In: YES user_id=21627 Can you give the rationale for this change, for those of us that don't know which thread you are referring to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 From noreply@sourceforge.net Tue Jun 24 15:18:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 24 Jun 2003 07:18:02 -0700 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From MAILER-DAEMON@rizolit.ru Tue Jun 24 20:49:11 2003 From: MAILER-DAEMON@rizolit.ru (MAILER-DAEMON@rizolit.ru) Date: 24 Jun 2003 19:49:11 -0000 Subject: [Patches] failure notice Message-ID: Hi. This is the qmail-send program at rizolit.ru. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : 165.212.8.32 does not like recipient. Remote host said: 550 ... User not known Giving up on 165.212.8.32. --- Below this line is a copy of the message. Return-Path: Received: (qmail 11727 invoked by uid 515); 24 Jun 2003 19:49:10 -0000 Delivered-To: kkutukov-vkutukov@business2business.ru Received: (qmail 11719 invoked by uid 102); 24 Jun 2003 19:49:10 -0000 Received: from 200-206-186-140.dsl.telesp.net.br (HELO compuserve.com) (200.206.186.140) by www2.rizolit.ru with SMTP; 24 Jun 2003 19:49:08 -0000 Date: Tue, 24 Jun 2003 18:58:51 +0000 From: patches@python.org Subject: Re: Åñòü êðóïíûå çàêàç÷èêè.. -- cyjAtwKhrmuHIZedTWrViYWdMLYcnmBpLLQUtDbBPvtAvmDnjV To: Vkutukov References: In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1251 Content-Transfer-Encoding: 8bit Ñòðîèòåëüíûå îáúåêòû ÌîñêâûÂîçüìèòå ñàìûõ êðóïíûõ êëèåíòîâ -
áûñòðåå êîíêóðåíòîâ!

Ó Âàñ åñòü ÷òî ïðåäëîæèòü êîìïàíèÿì,
âåäóùèì ñòðîèòåëüñòâî êðóïíûõ îáúåêòîâ â Ìîñêâå!

Âñå ñòðîèòåëüíûå îáúåêòû Ìîñêâû ïî ñîñòîÿíèþ íà ìàé 2003 ã. - â áàçå
Ìîñêâà. Ñòðîèòåëüíûå îáúåêòû:

  • 3300 ñòðîèòåëüíûõ îáúåêòîâ,
  • 1300 ñòðîÿùèõ êîìïàíèé,
  • àäðåñà, òåëåôîíû, êîíòàêòíûå ëèöà,
  • èíôîðìàöèÿ î õàðàêòåðå îáúåêòà (æèëîé äîì, îôèñíûé öåíòð, è ò.ä.)

    Ñòîèìîñòü áàçû 300 ó.å. Ôîðìà îïëàòû ëþáàÿ.
    Åñëè Âû õîòèòå ïðèîáðåñòè âûáîðêó èç áàçû (íàïðèìåð òîëüêî ñòðîÿùèåñÿ ñêëàäû), òî öåíà îïðåäåëÿåòñÿ ïðîïîðöèîíàëüíî îò ñòîèìîñòè âñåé áàçû, ñîãëàñíî êîëè÷åñòâó âûáðàííûõ çàïèñåé.

    Çàêàæèòå ñåé÷àñ!
    Íå äàéòå Âàøèì êîíêóðåíòàì Âàñ îïåðåäèòü!
    Çàêàçàòü



    • TrhXnvVhvqYGiObzKujAtJyJljYVCmovFwtURncmGaTOPUnBoz From noreply@sourceforge.net Wed Jun 25 05:55:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 24 Jun 2003 21:55:42 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 21:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Nobody/Anonymous (nobody) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Wed Jun 25 22:35:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 25 Jun 2003 14:35:34 -0700 Subject: [Patches] [ python-Patches-760792 ] "wo" in "word" now valid but not documented as such Message-ID: Patches item #760792, was opened at 2003-06-25 23:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760792&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: "wo" in "word" now valid but not documented as such Initial Comment: http://www.python.org/dev/doc/devel/ref/comparisons.html states: """For the Unicode and string types, x in y is true if and only if there exists an index i such that x == y[i] is true. If x is not a string or Unicode object of length 1, a TypeError exception is raised.""" However, as of Python 2.3, this is no longer True, as stated in http://www.python.org/doc/2.3b1/whatsnew/node17.html#SECTION0001710000000000000000: """The in operator now works differently for strings. Previously, when evaluating X in Y where X and Y are strings, X could only be a single character. That's now changed; X can be a string of any length, and X in Y will return True if X is a substring of Y. If X is the empty string, the result is always True.""" This patch fixes the reference documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760792&group_id=5470 From noreply@sourceforge.net Thu Jun 26 07:52:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 25 Jun 2003 23:52:56 -0700 Subject: [Patches] [ python-Patches-760990 ] add time elapsed to gc debug output Message-ID: Patches item #760990, was opened at 2003-06-26 06:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760990&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jeske (jeske) Assigned to: Nobody/Anonymous (nobody) Summary: add time elapsed to gc debug output Initial Comment: In debugging Python GC actions, it's really useful to know the amount of time Python spends doing the GC cycle (i.e. the pause time). I made a quick change to do this, and I've attached the patch. It needs to be fixed to be portable. I wanted to just call floattime() from timemodule.c, but it wasn't clear how to do this from gcmodule.c. It didn't seem like the right thing to do to copy the floattime() code from timemodule.c. I figured I would leave this simple detail to the experts. My patch adds the gc time and the max gc time to the "done" line when debugging is enabled, making it look like this: gc: collecting generation 0... gc: objects in each generation: 702 5608 72421 gc: done. (0.000267006 s, max 0.151359 s) I'd like to see this adopted in the gc module. I also think it would be useful if there were a debugging mode to print out gc sweeps which take longer than a certain pause time, but I didn't make this change. However, it's possible to derive this from the logs. (i.e. gc.debug_pauses(0.2) would print out a line for each gc pause over 0.2 seconds) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760990&group_id=5470 From noreply@sourceforge.net Thu Jun 26 11:15:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 03:15:25 -0700 Subject: [Patches] [ python-Patches-761104 ] adding BaseSet.filter and Set.filter_update Message-ID: Patches item #761104, was opened at 2003-06-26 12:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761104&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: adding BaseSet.filter and Set.filter_update Initial Comment: Hi, as proposed in [0], this patch adds a method 'filter' to BaseSet and a method 'filter_update' to Set. I often see myself doing "newset = sets.Set(filter(f, someset))" or "someset = sets.Set(filter(f, someset))". This is now no longer necessary. I think this method is a good solution to this problem. I'm not sure whether it is correct to add my name to the code history since it is a small change. If this is not correct feel free to remove it. This patch also corrects the docstring: the docstring says _TemporarilyImmutableSet is not a subset of BaseSet, but it is. Gerrit. [0] http://groups.google.nl/groups?dq=&hl=nl&lr=&ie=UTF-8&oe=UTF-8&group=comp.lang.python&selm=mailman.1056577245.15021.python-list%40python.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761104&group_id=5470 From noreply@sourceforge.net Thu Jun 26 14:44:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 06:44:49 -0700 Subject: [Patches] [ python-Patches-736413 ] DESTDIR improvement Message-ID: Patches item #736413, was opened at 2003-05-12 12:30 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736413&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: DESTDIR improvement Initial Comment: Byte compile correctly with DESTDIR. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2003-06-26 15:44 Message: Logged In: YES user_id=192186 Yes, you're right, sorry for posting bad patch.... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 15:27 Message: Logged In: YES user_id=21627 The patch is incorrect: setting -d to DESTDIR will cause DESTDIR to be hard-coded. Correct is to use LIBDEST, committed as Makefile.pre.in 1.134 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-05-19 11:51 Message: Logged In: YES user_id=192186 I forgot to mention, that the patch was larger before, but I saw many simmilar things applied in CVS, so this _should_ work with CVS version. However I will test it today... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-16 23:42 Message: Logged In: YES user_id=21627 Please test this on your machine. The byte code of __init__.py will still point to /home/users/user/tmp/python-2.3b1-root-user/usr/lib/python2.3/logging/__init__.py with your patch applied. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2003-05-16 10:52 Message: Logged In: YES user_id=387193 A simple test, to describe the problem, below. DESTDIR is set to "/home/users/user/tmp/python-2.3b1-root-user". ----------------- import logging class X: pass logging.setLoggerClass(X) ------------------- Code above gives following exception: Traceback (most recent call last): File "tracedir.py", line 6, in ? logging.setLoggerClass(X) File "/home/users/user/tmp/python-2.3b1-root-user/usr/lib/python2.3/logging/__init__.py", line 729, in setLoggerClass TypeError: logger not derived from logging.Logger: X I _suppose_ that, after applying the patch the exception will look like: Traceback (most recent call last): File "tracedir.py", line 6, in ? logging.setLoggerClass(X) File "/usr/lib/python2.3/logging/__init__.py", line 729, in setLoggerClass TypeError: logger not derived from logging.Logger: X There will be no DESTDIR part in the module filepath. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-16 08:09 Message: Logged In: YES user_id=21627 What is the rationale of this patch? If I set DESTDIR to, say, /tmp/py, why is passing -d /tmp/py to compileall desirable? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736413&group_id=5470 From noreply@sourceforge.net Thu Jun 26 15:47:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 07:47:15 -0700 Subject: [Patches] [ python-Patches-756032 ] re reads an uninitialized memory Message-ID: Patches item #756032, was opened at 2003-06-17 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re reads an uninitialized memory Initial Comment: With this script, re reads from an address beyond the end of the string. >>> import re >>> r = re.compile(r"\b1") >>> print r.search('a', 1) See assert() in the attached patch to see where incorrect memory reading occurs. This patch looks fix the problem, but I'm not sure this is correct answer. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-26 14:47 Message: Logged In: YES user_id=7887 Fixed in Modules/_sre.c:2.99. Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-22 20:33 Message: Logged In: YES user_id=7887 Now I can see the problem. The current test doesn't contemplate a broken ptr/end pair. Your code is addressing the right problem, but the right way to fix this seems to be to avoid that branch completely, unless pattern[3] > 1 (unlike the current > 0). Thank you very much for your patch and your insistence! ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-06-22 02:14 Message: Logged In: YES user_id=463672 Sorry for my lack of infomation. While ptr outside the boundaries is legal, but fetching from there is not. One example of problem is using SRE for mmap object. This script causes an application error under my w2k box. open("tstfile", "wb").write('a'*4096) import mmap f = open("tstfile", "rb") xx = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) import re r = re.compile(r"\b1") r.search(xx, len(xx)) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-21 23:28 Message: Logged In: YES user_id=7887 Atsuo, can you please describe what problem you're trying to fix!? In other words, can you provide some code which breaks SRE? Your assertion doesn't seem to make sense in this place, since having ptr outside the boundaries of beginning/end *is* accepted. Notice how "ptr < state->end" is checked before using ptr[0]. I'm closing this bug as invalid. If you have something you belive to prove there's a bug in this place, please reopen this bug. Thank you very much for taking the time to fill this bug. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 13:30 Message: Logged In: YES user_id=21627 Gustavo, can your review this code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 From noreply@sourceforge.net Thu Jun 26 15:55:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 07:55:55 -0700 Subject: [Patches] [ python-Patches-757624 ] Fixing recursive problem in SRE Message-ID: Patches item #757624, was opened at 2003-06-20 01:42 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757624&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Fixing recursive problem in SRE Initial Comment: Here is a preview for the SRE change being discussed in python-dev mailing list. It also includes the changes in patch #572936 (groupref_exists). ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-26 14:55 Message: Logged In: YES user_id=7887 Thanks for testing it! Here is another implementation (version 4), using a different approach. Unlike the other implementations, this one doesn't recurse at all, and introduce no new opcodes in the engine. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-23 13:06 Message: Logged In: YES user_id=250749 version 3 of the patch survives a full regression test run on both FreeBSD 4.8 & 5.1, with USE_RECURSION_LIMIT reverted to 10000. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-22 01:13 Message: Logged In: YES user_id=7887 Updated version of the patch. More on the mailing list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757624&group_id=5470 From noreply@sourceforge.net Thu Jun 26 17:52:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 09:52:58 -0700 Subject: [Patches] [ python-Patches-757624 ] Fixing recursive problem in SRE Message-ID: Patches item #757624, was opened at 2003-06-20 01:42 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757624&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Fixing recursive problem in SRE Initial Comment: Here is a preview for the SRE change being discussed in python-dev mailing list. It also includes the changes in patch #572936 (groupref_exists). ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-26 16:52 Message: Logged In: YES user_id=7887 Version 5 fixes a minor bug due to a variable being used inside a macro and a submacro. Now submacro allocates it internally to avoid further problems. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-26 14:55 Message: Logged In: YES user_id=7887 Thanks for testing it! Here is another implementation (version 4), using a different approach. Unlike the other implementations, this one doesn't recurse at all, and introduce no new opcodes in the engine. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-23 13:06 Message: Logged In: YES user_id=250749 version 3 of the patch survives a full regression test run on both FreeBSD 4.8 & 5.1, with USE_RECURSION_LIMIT reverted to 10000. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-22 01:13 Message: Logged In: YES user_id=7887 Updated version of the patch. More on the mailing list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757624&group_id=5470 From noreply@sourceforge.net Thu Jun 26 18:05:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 10:05:07 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-06-26 13:05 Message: Logged In: YES user_id=11375 Shouldn't block devices also be excluded from the size check? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 10:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 10:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-22 23:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 14:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 13:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 19:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Thu Jun 26 19:18:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 11:18:20 -0700 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 08:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-23 06:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 14:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-19 04:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 14:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-18 09:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 18:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 16:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-17 07:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 16:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 14:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 13:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Thu Jun 26 19:45:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 11:45:01 -0700 Subject: [Patches] [ python-Patches-761104 ] adding BaseSet.filter and Set.filter_update Message-ID: Patches item #761104, was opened at 2003-06-26 05:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761104&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: adding BaseSet.filter and Set.filter_update Initial Comment: Hi, as proposed in [0], this patch adds a method 'filter' to BaseSet and a method 'filter_update' to Set. I often see myself doing "newset = sets.Set(filter(f, someset))" or "someset = sets.Set(filter(f, someset))". This is now no longer necessary. I think this method is a good solution to this problem. I'm not sure whether it is correct to add my name to the code history since it is a small change. If this is not correct feel free to remove it. This patch also corrects the docstring: the docstring says _TemporarilyImmutableSet is not a subset of BaseSet, but it is. Gerrit. [0] http://groups.google.nl/groups?dq=&hl=nl&lr=&ie=UTF-8&oe=UTF-8&group=comp.lang.python&selm=mailman.1056577245.15021.python-list%40python.org ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-26 13:45 Message: Logged In: YES user_id=80475 * I don't think this should be added to the API. filter() is a builtin because it can be used with many datatypes as an input. Most container contructors have a list format that is suitable for use with filter. It is not unduly burdensome to write: newset=Set(filter(f, oldset)). The existing approach is also more flexible because the user can opt for a list comprehension, itertools.ifilter, itertools.ifilterfalse, or any other suitable expression. * If this ends up getting accepted, consider using itertools and a simpler, factored implementation: def filter(self, f): return Set(ifilter(f, self._data)) * Also, a documentation patch and news item would be needed. * I agree with docstring patch and will apply just that piece. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761104&group_id=5470 From noreply@sourceforge.net Thu Jun 26 20:33:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 12:33:23 -0700 Subject: [Patches] [ python-Patches-760792 ] "wo" in "word" now valid but not documented as such Message-ID: Patches item #760792, was opened at 2003-06-25 16:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760792&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: "wo" in "word" now valid but not documented as such Initial Comment: http://www.python.org/dev/doc/devel/ref/comparisons.html states: """For the Unicode and string types, x in y is true if and only if there exists an index i such that x == y[i] is true. If x is not a string or Unicode object of length 1, a TypeError exception is raised.""" However, as of Python 2.3, this is no longer True, as stated in http://www.python.org/doc/2.3b1/whatsnew/node17.html#SECTION0001710000000000000000: """The in operator now works differently for strings. Previously, when evaluating X in Y where X and Y are strings, X could only be a single character. That's now changed; X can be a string of any length, and X in Y will return True if X is a substring of Y. If X is the empty string, the result is always True.""" This patch fixes the reference documentation. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-26 14:33 Message: Logged In: YES user_id=80475 Revised wording and applied as Doc/ref/ref5.tex 1.75 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760792&group_id=5470 From noreply@sourceforge.net Thu Jun 26 20:53:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 12:53:44 -0700 Subject: [Patches] [ python-Patches-761401 ] DISTUTILS_DEBUG undocumented Message-ID: Patches item #761401, was opened at 2003-06-26 21:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761401&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: DISTUTILS_DEBUG undocumented Initial Comment: The DISTUTILS_DEBUG environment variable is undocumented, but it is very helpful when a setup script doesn't do what the developer wants. This patch adds a small section to the Distributing Python Modules manual, section 3: writing the setup script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761401&group_id=5470 From noreply@sourceforge.net Thu Jun 26 23:53:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 15:53:16 -0700 Subject: [Patches] [ python-Patches-761519 ] Fixes for bugs 760703 and 757821 Message-ID: Patches item #761519, was opened at 2003-06-26 22:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761519&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes for bugs 760703 and 757821 Initial Comment: Patched __init__.py - added new function makeLogRecord (for bug report 760703). Patched handlers.py - updated some docstrings and deleted some old commented-out code. Patched test_logging.py to make use of makeLogRecord. Patched liblogging.tex to fill documentation gaps (both 760703 and bug 757821). test_logging runs OK after these changes - on my system, anyway :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761519&group_id=5470 From noreply@sourceforge.net Thu Jun 26 23:55:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 15:55:38 -0700 Subject: [Patches] [ python-Patches-761519 ] Fixes for bugs 760703 and 757821 Message-ID: Patches item #761519, was opened at 2003-06-26 22:53 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761519&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Vinay Sajip (vsajip) >Assigned to: Raymond Hettinger (rhettinger) Summary: Fixes for bugs 760703 and 757821 Initial Comment: Patched __init__.py - added new function makeLogRecord (for bug report 760703). Patched handlers.py - updated some docstrings and deleted some old commented-out code. Patched test_logging.py to make use of makeLogRecord. Patched liblogging.tex to fill documentation gaps (both 760703 and bug 757821). test_logging runs OK after these changes - on my system, anyway :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761519&group_id=5470 From noreply@sourceforge.net Fri Jun 27 01:47:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 17:47:09 -0700 Subject: [Patches] [ python-Patches-760990 ] add time elapsed to gc debug output Message-ID: Patches item #760990, was opened at 2003-06-26 02:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760990&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jeske (jeske) Assigned to: Nobody/Anonymous (nobody) Summary: add time elapsed to gc debug output Initial Comment: In debugging Python GC actions, it's really useful to know the amount of time Python spends doing the GC cycle (i.e. the pause time). I made a quick change to do this, and I've attached the patch. It needs to be fixed to be portable. I wanted to just call floattime() from timemodule.c, but it wasn't clear how to do this from gcmodule.c. It didn't seem like the right thing to do to copy the floattime() code from timemodule.c. I figured I would leave this simple detail to the experts. My patch adds the gc time and the max gc time to the "done" line when debugging is enabled, making it look like this: gc: collecting generation 0... gc: objects in each generation: 702 5608 72421 gc: done. (0.000267006 s, max 0.151359 s) I'd like to see this adopted in the gc module. I also think it would be useful if there were a debugging mode to print out gc sweeps which take longer than a certain pause time, but I didn't make this change. However, it's possible to derive this from the logs. (i.e. gc.debug_pauses(0.2) would print out a line for each gc pause over 0.2 seconds) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-26 20:47 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. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. 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=305470&aid=760990&group_id=5470 From noreply@sourceforge.net Fri Jun 27 04:19:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2003 20:19:48 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-26 23:19 Message: Logged In: YES user_id=33168 Yes, the check for block devices should go in now as a bug fix I think. Can anyone test on windows? I attached a patch for just this minimal change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-06-26 13:05 Message: Logged In: YES user_id=11375 Shouldn't block devices also be excluded from the size check? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 10:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 10:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-22 23:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 14:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 13:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 19:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Fri Jun 27 12:15:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 04:15:08 -0700 Subject: [Patches] [ python-Patches-751916 ] Handle keyboard interrupts in SSL module Message-ID: Patches item #751916, was opened at 2003-06-10 08:36 Message generated for change (Settings changed) made by jacobs99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751916&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Jacobs (jacobs99) >Assigned to: Martin v. Löwis (loewis) Summary: Handle keyboard interrupts in SSL module Initial Comment: As of Python 2.3 beta 1 (and current CVS), the SSL module does not check to see if a keyboard interrupt occurred after waiting on connections, reads, and writes. This results in long delays (seconds or even minutes) before the KeyboardInterrupt is finally raised, causing problematic pauses for interactive processes. This does not happen in Python 2.2.2, though I have not looked into what has changed. My next step is to look into httplib, the use-case that brought this to my attention, since some of the buffering code is not exception safe. i.e., a KeyboardInterrupt can cause data to be lost on subsequent reads. I suspect that it is also possible to lose data on due to socket timeouts as well, so I consider this issue a distinct bug. I did not include a new unit test, since it is a little tricky to produce. It requires a large SSL transfer and a network timing-sensitive threshold test to detect. Also included in the attached patch are some error handling fixes and cleanups related to time-out operations that I happened to notice. This module deserves more attention, since the timeout changes don't look like they were integrated as carefully as they could have been and other similar errors are possible. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-17 16:04 Message: Logged In: YES user_id=21627 The patch looks fine to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751916&group_id=5470 From noreply@sourceforge.net Fri Jun 27 12:32:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 04:32:11 -0700 Subject: [Patches] [ python-Patches-750008 ] 'compiler' module bug with 'import foo.bar as baz' Message-ID: Patches item #750008, was opened at 2003-06-06 10:47 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750008&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ronny Wikh (mrpr) >Assigned to: Michael Hudson (mwh) Summary: 'compiler' module bug with 'import foo.bar as baz' Initial Comment: Python package 'compiler' generates incorrect code for statements on the format 'import foo.bar as baz'. Code to illustrate this follows: ----------------------- program = ''' import foo.bar as baz ''' code1 = compile(program, 'foobar', 'exec') code2 = compiler.compile(program, 'foobar', 'exec') print 'CODE builtin' dis.disassemble(code1) print print 'CODE compiler package' dis.disassemble(code2) ----------------------- With the output: ----------------------- CODE builtin 0 SET_LINENO 0 3 SET_LINENO 2 6 LOAD_CONST 0 (None) 9 IMPORT_NAME 0 (foo.bar) 12 LOAD_ATTR 1 (bar) 15 STORE_NAME 2 (baz) 18 LOAD_CONST 0 (None) 21 RETURN_VALUE CODE compiler package 0 SET_LINENO 0 3 SET_LINENO 2 6 LOAD_CONST 0 (None) 9 IMPORT_NAME 0 (foo.bar) 12 STORE_NAME 1 (baz) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE ----------------------- The attached patch fixes this bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750008&group_id=5470 From noreply@sourceforge.net Fri Jun 27 13:33:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 05:33:17 -0700 Subject: [Patches] [ python-Patches-750008 ] 'compiler' module bug with 'import foo.bar as baz' Message-ID: Patches item #750008, was opened at 2003-06-06 10:47 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750008&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronny Wikh (mrpr) Assigned to: Michael Hudson (mwh) Summary: 'compiler' module bug with 'import foo.bar as baz' Initial Comment: Python package 'compiler' generates incorrect code for statements on the format 'import foo.bar as baz'. Code to illustrate this follows: ----------------------- program = ''' import foo.bar as baz ''' code1 = compile(program, 'foobar', 'exec') code2 = compiler.compile(program, 'foobar', 'exec') print 'CODE builtin' dis.disassemble(code1) print print 'CODE compiler package' dis.disassemble(code2) ----------------------- With the output: ----------------------- CODE builtin 0 SET_LINENO 0 3 SET_LINENO 2 6 LOAD_CONST 0 (None) 9 IMPORT_NAME 0 (foo.bar) 12 LOAD_ATTR 1 (bar) 15 STORE_NAME 2 (baz) 18 LOAD_CONST 0 (None) 21 RETURN_VALUE CODE compiler package 0 SET_LINENO 0 3 SET_LINENO 2 6 LOAD_CONST 0 (None) 9 IMPORT_NAME 0 (foo.bar) 12 STORE_NAME 1 (baz) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE ----------------------- The attached patch fixes this bug ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-06-27 13:33 Message: Logged In: YES user_id=6656 Yup. Lib/compiler/pycodegen.py revision 1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750008&group_id=5470 From noreply@sourceforge.net Fri Jun 27 15:08:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 07:08:05 -0700 Subject: [Patches] [ python-Patches-756032 ] re reads an uninitialized memory Message-ID: Patches item #756032, was opened at 2003-06-17 12:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 Category: Modules Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re reads an uninitialized memory Initial Comment: With this script, re reads from an address beyond the end of the string. >>> import re >>> r = re.compile(r"\b1") >>> print r.search('a', 1) See assert() in the attached patch to see where incorrect memory reading occurs. This patch looks fix the problem, but I'm not sure this is correct answer. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-27 10:08 Message: Logged In: YES user_id=33168 Gustavo, can you add a test case as well? Thanks. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-26 10:47 Message: Logged In: YES user_id=7887 Fixed in Modules/_sre.c:2.99. Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-22 16:33 Message: Logged In: YES user_id=7887 Now I can see the problem. The current test doesn't contemplate a broken ptr/end pair. Your code is addressing the right problem, but the right way to fix this seems to be to avoid that branch completely, unless pattern[3] > 1 (unlike the current > 0). Thank you very much for your patch and your insistence! ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-06-21 22:14 Message: Logged In: YES user_id=463672 Sorry for my lack of infomation. While ptr outside the boundaries is legal, but fetching from there is not. One example of problem is using SRE for mmap object. This script causes an application error under my w2k box. open("tstfile", "wb").write('a'*4096) import mmap f = open("tstfile", "rb") xx = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) import re r = re.compile(r"\b1") r.search(xx, len(xx)) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-06-21 19:28 Message: Logged In: YES user_id=7887 Atsuo, can you please describe what problem you're trying to fix!? In other words, can you provide some code which breaks SRE? Your assertion doesn't seem to make sense in this place, since having ptr outside the boundaries of beginning/end *is* accepted. Notice how "ptr < state->end" is checked before using ptr[0]. I'm closing this bug as invalid. If you have something you belive to prove there's a bug in this place, please reopen this bug. Thank you very much for taking the time to fill this bug. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 09:30 Message: Logged In: YES user_id=21627 Gustavo, can your review this code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756032&group_id=5470 From noreply@sourceforge.net Fri Jun 27 15:22:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 07:22:29 -0700 Subject: [Patches] [ python-Patches-761863 ] readline module that checks signals Message-ID: Patches item #761863, was opened at 2003-06-27 07:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761863&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Keith Dart (kdart) Assigned to: Nobody/Anonymous (nobody) Summary: readline module that checks signals Initial Comment: Attached is a patch against the readline module that hooks the readline event hook to call the PyErr_CheckSignals(). This way, Python signal handlers get run even if you are sitting at a readline prompt (where they didn't before). this solves a long-standing annoyance for me. whew. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761863&group_id=5470 From noreply@sourceforge.net Fri Jun 27 15:24:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 07:24:32 -0700 Subject: [Patches] [ python-Patches-761865 ] patch against readline module to handle signals Message-ID: Patches item #761865, was opened at 2003-06-27 07:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761865&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Keith Dart (kdart) Assigned to: Nobody/Anonymous (nobody) Summary: patch against readline module to handle signals Initial Comment: Attached is a patch against the readline module that hooks the readline event hook to call the PyErr_CheckSignals(). This way, Python signal handlers get run even if you are sitting at a readline prompt (where they didn't before). this solves a long-standing annoyance for me. whew. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761865&group_id=5470 From noreply@sourceforge.net Fri Jun 27 16:09:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 08:09:00 -0700 Subject: [Patches] [ python-Patches-672855 ] improve pydoc handling of extension types Message-ID: Patches item #672855, was opened at 2003-01-22 20:05 Message generated for change (Comment added) made by gtalvola You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672855&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Geoff Talvola (gtalvola) >Assigned to: Skip Montanaro (montanaro) Summary: improve pydoc handling of extension types Initial Comment: pydoc.HTMLRepr.repr1() generates an exception if you pass in an object x where type(x) has no __name__ attribute. The attached patch adds a test for this case and keeps repr1 from barfing. This is useful on Windows if you're using cgitb.py to try to get tracebacks that involve COM objects -- somewhere in the guts of the COM support code you get a type that has no __name__ attribute. ---------------------------------------------------------------------- >Comment By: Geoff Talvola (gtalvola) Date: 2003-06-27 11:09 Message: Logged In: YES user_id=88162 Assigning to Skip since he's done work with traceback code before. I'm hoping this gets into 2.3b2. It's really a no-brainer bugfix. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-05-21 17:02 Message: Logged In: YES user_id=88162 I'm uploading an improved version of this patch that fixes both the Text and HTML versions of the traceback. The previous patch only fixed the HTML version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672855&group_id=5470 From noreply@sourceforge.net Fri Jun 27 16:46:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 08:46:54 -0700 Subject: [Patches] [ python-Patches-672855 ] improve pydoc handling of extension types Message-ID: Patches item #672855, was opened at 2003-01-22 19:05 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672855&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Geoff Talvola (gtalvola) Assigned to: Skip Montanaro (montanaro) Summary: improve pydoc handling of extension types Initial Comment: pydoc.HTMLRepr.repr1() generates an exception if you pass in an object x where type(x) has no __name__ attribute. The attached patch adds a test for this case and keeps repr1 from barfing. This is useful on Windows if you're using cgitb.py to try to get tracebacks that involve COM objects -- somewhere in the guts of the COM support code you get a type that has no __name__ attribute. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-06-27 10:46 Message: Logged In: YES user_id=44345 Checked in as pydoc.py 1.86. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-06-27 10:09 Message: Logged In: YES user_id=88162 Assigning to Skip since he's done work with traceback code before. I'm hoping this gets into 2.3b2. It's really a no-brainer bugfix. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-05-21 16:02 Message: Logged In: YES user_id=88162 I'm uploading an improved version of this patch that fixes both the Text and HTML versions of the traceback. The previous patch only fixed the HTML version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672855&group_id=5470 From noreply@sourceforge.net Fri Jun 27 18:22:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 10:22:16 -0700 Subject: [Patches] [ python-Patches-761969 ] -DPIC should be added for the -fPIC case Message-ID: Patches item #761969, was opened at 2003-06-27 19:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: -DPIC should be added for the -fPIC case Initial Comment: AFAIK -DPIC should always added when compiling with -DPIC. At least that's what libtool does and shown in many FAQs (like http://www.netbsd.org/Documentation/elf.html). A quick glance on NetBSD-current and FreeBSD (4.8) shows that it's evaluated in machine/asm.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 From noreply@sourceforge.net Fri Jun 27 19:27:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 11:27:23 -0700 Subject: [Patches] [ python-Patches-756253 ] itertools roundrobin() and window() Message-ID: Patches item #756253, was opened at 2003-06-17 17:35 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Raymond Hettinger (rhettinger) Summary: itertools roundrobin() and window() Initial Comment: a patch to add the roundrobin() and window() objects to the itertools module. Hettinger has already seen the implementation of roundrobin, but not window. test_itertools.py in a seperate patch ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2003-06-27 14:27 Message: Logged In: YES user_id=591932 added Lib/test/test_itertools.py patch here, deleted old item that just had that patch in it ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 16:11 Message: Logged In: YES user_id=80475 *Please post the tests to this patch and close the other patch. *Add a documentation patch to this patch *Let's drop the addition of window(). The C code for it is less than beautiful and offers only a minimal performance gain over the pure python equivalent. I've added the pure python version to the docs so folks can cut and paste it if they need it. Sorry for the wild goose chase (I had expected the C version to be much cleaner and faster and that the python verions would've been harder -- actual code was needed for me to see it). * In roundrobin_next(), replace the % operator with: if (lz->iternum==lz->itersize) lz-iternum=0; * In roundrobin_next(), remove the extra blank line following "long listsize;" * Fixup the indentation, currently it is a mix of spaces and tabs. It should be just pure tabs. * Replace the variable name 'lz' with 'rr'. I should have changed that in other places too but for new code it should be fixed. * 'unti' is mispelled in the docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 From noreply@sourceforge.net Fri Jun 27 19:32:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 11:32:47 -0700 Subject: [Patches] [ python-Patches-675551 ] extending readline functionality Message-ID: Patches item #675551, was opened at 2003-01-27 10:52 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675551&group_id=5470 Category: Library (Lib) >Group: Python 2.3 >Status: Open Resolution: Invalid Priority: 5 Submitted By: Michal Vitecek (fufsource) >Assigned to: Skip Montanaro (montanaro) Summary: extending readline functionality Initial Comment: this patch against vanilla 2.2.2 adds three new functions to module readline: remove_history(pos) -- remove history entry specified by pos replace_history_entry(pos, line) -- replace history entry specified by pos with the given line get_history_buffer_size() -- get current number of history entries the libreadline.tex is also modified. thank you for your consideration. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-06-27 13:32 Message: Logged In: YES user_id=44345 Michal, Can you update this patch against the 2.3 (CVS) source? I'll take a look at it for addition after the 2.3 release. ---------------------------------------------------------------------- Comment By: Michal Vitecek (fufsource) Date: 2003-02-11 05:23 Message: Logged In: YES user_id=698198 this patch is invalid as no functionality extensions are allowed in a stable python version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675551&group_id=5470 From noreply@sourceforge.net Fri Jun 27 19:33:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 11:33:13 -0700 Subject: [Patches] [ python-Patches-756253 ] itertools roundrobin() and window() Message-ID: Patches item #756253, was opened at 2003-06-17 17:35 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 Category: Modules >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Raymond Hettinger (rhettinger) Summary: itertools roundrobin() and window() Initial Comment: a patch to add the roundrobin() and window() objects to the itertools module. Hettinger has already seen the implementation of roundrobin, but not window. test_itertools.py in a seperate patch ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2003-06-27 14:33 Message: Logged In: YES user_id=591932 pushed to 2.4 I'll put up patches that incorporate rhettinger's feedback soon, and definitely in time for the 2.4 branch. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-06-27 14:27 Message: Logged In: YES user_id=591932 added Lib/test/test_itertools.py patch here, deleted old item that just had that patch in it ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 16:11 Message: Logged In: YES user_id=80475 *Please post the tests to this patch and close the other patch. *Add a documentation patch to this patch *Let's drop the addition of window(). The C code for it is less than beautiful and offers only a minimal performance gain over the pure python equivalent. I've added the pure python version to the docs so folks can cut and paste it if they need it. Sorry for the wild goose chase (I had expected the C version to be much cleaner and faster and that the python verions would've been harder -- actual code was needed for me to see it). * In roundrobin_next(), replace the % operator with: if (lz->iternum==lz->itersize) lz-iternum=0; * In roundrobin_next(), remove the extra blank line following "long listsize;" * Fixup the indentation, currently it is a mix of spaces and tabs. It should be just pure tabs. * Replace the variable name 'lz' with 'rr'. I should have changed that in other places too but for new code it should be fixed. * 'unti' is mispelled in the docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 From noreply@sourceforge.net Fri Jun 27 19:25:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 11:25:55 -0700 Subject: [Patches] [ python-Patches-756255 ] test_itertools for roundrobin() and window() Message-ID: Patches item #756255, was opened at 2003-06-17 17:37 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756255&group_id=5470 Category: Tests Group: Python 2.3 >Status: Deleted Resolution: None Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Nobody/Anonymous (nobody) Summary: test_itertools for roundrobin() and window() Initial Comment: patch to add test to Lib/test/test_itertools.py for roundrobin and window ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2003-06-27 14:25 Message: Logged In: YES user_id=591932 moved to the matching patch that adds the funcs to itertoolsmodule.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756255&group_id=5470 From noreply@sourceforge.net Fri Jun 27 20:14:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 12:14:18 -0700 Subject: [Patches] [ python-Patches-736730 ] Trivial improvement to NameError message Message-ID: Patches item #736730, was opened at 2003-05-12 17:52 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736730&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Trivial improvement to NameError message Initial Comment: This is a trivial change, but since code may depend on the exact wording, I'm submitting a patch for review. The compiler knows when there's no locally bound name and generates LOAD_GLOBAL. If a NameError is raised during that instruction, it generates an error message like global name 'XYZ' is not defined This can be misleading to new users. The fact that the name is not found by LOAD_GLOBAL is strictly an optimization detail. I think something like the attached patch would be better. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-06-27 14:14 Message: Logged In: YES user_id=44345 Nobody seemed to like it, so I'm closing. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-12 20:37 Message: Logged In: YES user_id=44345 That's also fine. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 20:27 Message: Logged In: YES user_id=31435 Well, that same user also knew he hadn't defined the name in the locals or the builtins either, right? Telling him three confusing things isn't obviously better than telling him just one . If you think this is helpful, then I suggest name 'XYZ' is not defined would be more accurate (it doesn't omit the possibility of enclosing lexical scopes) and more pleasant (it's shorter). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-12 19:57 Message: Logged In: YES user_id=44345 The distinction between LOAD_NAME, LOAD_FAST and LOAD_GLOBAL is just an implementation detail. By saying name 'XYZ' not found in locals, globals or builtins you tell the user, "I looked in the locals, the globals and the builtins but didn't find XYZ." By saying global name 'XYZ' is not defined all you're telling the user is that you didn't find it in the globals. Look at it another way. The program would be correct if all the LOAD_FAST and LOAD_GLOBAL instructions were replaced by LOAD_NAME instructions (perhaps ignoring nested scopes). LOAD_NAME looks everywhere. The fact that the compiler can detect that XYZ isn't in the locals and can generate a LOAD_GLOBAL instruction instead doesn't mean all three scopes weren't searched. This arose by confusion from a user on c.l.py who had defined an object at class scope but then failed to reference it as "self.B". The NameError said the usual thing, which confused the user because he knew he hadn't defined the object at module scope. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 18:16 Message: Logged In: YES user_id=31435 For those who'd rather not read the patch first, the msg becomes name 'XYZ' not found in locals, globals or builtins I'm afraid I don't see in what sense that's an improvement! It gives less information, and glosses over the possibility of enclosing lexical scopes. When I see 'global' in the current msg, I know at once that the name isn't known in the local scope, or in any non-local but enclosing lexical scope. So unless I'm missing something, I'm -1 on this change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 18:05 Message: Logged In: YES user_id=357491 +0 from me. Didn't we once agree that people depending on the exact text of an exception cause their own pain when the message gets changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736730&group_id=5470 From noreply@sourceforge.net Fri Jun 27 22:46:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 14:46:06 -0700 Subject: [Patches] [ python-Patches-761519 ] Fixes for bugs 760703 and 757821 Message-ID: Patches item #761519, was opened at 2003-06-26 17:53 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761519&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Raymond Hettinger (rhettinger) Summary: Fixes for bugs 760703 and 757821 Initial Comment: Patched __init__.py - added new function makeLogRecord (for bug report 760703). Patched handlers.py - updated some docstrings and deleted some old commented-out code. Patched test_logging.py to make use of makeLogRecord. Patched liblogging.tex to fill documentation gaps (both 760703 and bug 757821). test_logging runs OK after these changes - on my system, anyway :-) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-27 16:46 Message: Logged In: YES user_id=80475 Applied patch with some minor fixups and a NEWS item. See: /cvsroot/python/python/dist/src/Misc/NEWS 1.791 /cvsroot/python/python/dist/src/Doc/lib/liblogging.tex 1.9 /cvsroot/python/python/dist/src/Lib/logging/__init__.py 1.11 /cvsroot/python/python/dist/src/Lib/logging/handlers.py 1.7 /cvsroot/python/python/dist/src/Lib/test/test_logging.py 1.9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761519&group_id=5470 From noreply@sourceforge.net Fri Jun 27 22:51:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 14:51:25 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 23:55 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) >Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Fri Jun 27 22:54:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 14:54:02 -0700 Subject: [Patches] [ python-Patches-756996 ] Bare except in ZipFile.testzip() Message-ID: Patches item #756996, was opened at 2003-06-18 21:49 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756996&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) >Assigned to: Raymond Hettinger (rhettinger) Summary: Bare except in ZipFile.testzip() Initial Comment: ZipFile.testzip tries to call self.read, and reports the first file in the archive for which this raises an exception. Since a bare except is used, way too many kinds of exception are caught. This causes weirdness such as >>> import zipfile >>> z = zipfile.ZipFile('foo.zip') >>> z.close() >>> z.testzip() 'nt.to.png' When the ZipFile has been closed, .read raises a RuntimeError; .testzip reports this as a problem with the first file in the archive, which is misleading in the extreme. Propagating the RuntimeError would be better. Similarly IOErrors while reading the file are swallowed, as are KeyboardInterrupts, SystemExits, RuntimeErrors due to the absence of zlib... The patch changes the except clause to catch only BadZipfile, which is explicitly raised in .read for checksum failures. The docs indicate that that's what .testzip tests. (This exception is also raised for unsupported compression methods. I'm not sure how .testzip should treat those; perhaps the two conditions should have different exception types.) (A different bare except in this module received attention in bug 411881.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756996&group_id=5470 From noreply@sourceforge.net Fri Jun 27 23:26:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 27 Jun 2003 15:26:25 -0700 Subject: [Patches] [ python-Patches-756996 ] Bare except in ZipFile.testzip() Message-ID: Patches item #756996, was opened at 2003-06-18 21:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756996&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Raymond Hettinger (rhettinger) Summary: Bare except in ZipFile.testzip() Initial Comment: ZipFile.testzip tries to call self.read, and reports the first file in the archive for which this raises an exception. Since a bare except is used, way too many kinds of exception are caught. This causes weirdness such as >>> import zipfile >>> z = zipfile.ZipFile('foo.zip') >>> z.close() >>> z.testzip() 'nt.to.png' When the ZipFile has been closed, .read raises a RuntimeError; .testzip reports this as a problem with the first file in the archive, which is misleading in the extreme. Propagating the RuntimeError would be better. Similarly IOErrors while reading the file are swallowed, as are KeyboardInterrupts, SystemExits, RuntimeErrors due to the absence of zlib... The patch changes the except clause to catch only BadZipfile, which is explicitly raised in .read for checksum failures. The docs indicate that that's what .testzip tests. (This exception is also raised for unsupported compression methods. I'm not sure how .testzip should treat those; perhaps the two conditions should have different exception types.) (A different bare except in this module received attention in bug 411881.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-27 17:26 Message: Logged In: YES user_id=80475 Applied as: /cvsroot/python/python/dist/src/Misc/NEWS 1.792 /cvsroot/python/python/dist/src/Lib/zipfile.py 1.31 /cvsroot/python/python/dist/src/Lib/test/test_zipfile.py 1.10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756996&group_id=5470 From noreply@sourceforge.net Sat Jun 28 08:40:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 00:40:48 -0700 Subject: [Patches] [ python-Patches-751916 ] Handle keyboard interrupts in SSL module Message-ID: Patches item #751916, was opened at 2003-06-10 15:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751916&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Kevin Jacobs (jacobs99) Assigned to: Martin v. Löwis (loewis) Summary: Handle keyboard interrupts in SSL module Initial Comment: As of Python 2.3 beta 1 (and current CVS), the SSL module does not check to see if a keyboard interrupt occurred after waiting on connections, reads, and writes. This results in long delays (seconds or even minutes) before the KeyboardInterrupt is finally raised, causing problematic pauses for interactive processes. This does not happen in Python 2.2.2, though I have not looked into what has changed. My next step is to look into httplib, the use-case that brought this to my attention, since some of the buffering code is not exception safe. i.e., a KeyboardInterrupt can cause data to be lost on subsequent reads. I suspect that it is also possible to lose data on due to socket timeouts as well, so I consider this issue a distinct bug. I did not include a new unit test, since it is a little tricky to produce. It requires a large SSL transfer and a network timing-sensitive threshold test to detect. Also included in the attached patch are some error handling fixes and cleanups related to time-out operations that I happened to notice. This module deserves more attention, since the timeout changes don't look like they were integrated as carefully as they could have been and other similar errors are possible. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-28 09:40 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as _ssl.c 1.12 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-17 23:04 Message: Logged In: YES user_id=21627 The patch looks fine to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751916&group_id=5470 From noreply@sourceforge.net Sat Jun 28 08:47:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 00:47:14 -0700 Subject: [Patches] [ python-Patches-758910 ] add thread flags to CXX, too (fixes build on FreeBSD) Message-ID: Patches item #758910, was opened at 2003-06-22 23:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=758910&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Martin v. Löwis (loewis) Summary: add thread flags to CXX, too (fixes build on FreeBSD) Initial Comment: FreeBSD 5.x fails to link Modules/ccpython.cc: Python/thread_pthread.h:217: undefined reference to `pthread_create' Python/thread_pthread.h:253: undefined reference to `pthread_detach' The attached patch tests of the detected CC threads flag (-pthread, -kthread, -Kpthread or none) also works for CXX. This fixes the above error for FreeBSD 5.x. (Tested on today's -current with today's Python 2.3/cvs.) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-06-28 09:47 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure 1.408 configure.in 1.419 ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-23 15:03 Message: Logged In: YES user_id=250749 tests Ok on both FreeBSD 4.8 (which was Ok without the patch) and FreeBSD 5.1. If applied, bug #745320 can be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=758910&group_id=5470 From noreply@sourceforge.net Sat Jun 28 15:06:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 07:06:18 -0700 Subject: [Patches] [ python-Patches-754632 ] Enhance xrange description by mentioning itertools.repeat Message-ID: Patches item #754632, was opened at 2003-06-14 14:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754632&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance xrange description by mentioning itertools.repeat Initial Comment: This patch lets the description of the xrange builtin function include the recently by Alex Martelli on python-dev described notion that itertools.repeat(None, n) may be a lot faster than range() or xrange(). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 09:06 Message: Logged In: YES user_id=80475 Though "for _ in itertools.repeat(None, n):" offers a small speed advantage, it is not as readable as "for i in xrange(n):" which should remain the preferred looping idiom. The purpose of itertools.repeat() is to supply repeated arguments to imap() and izip(). Its secondary purpose is to provide a memory friendly version of "[obj] * n". Using it as a speedup for xrange() should only be used in rare situations where a slight performance gain is essential. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754632&group_id=5470 From noreply@sourceforge.net Sat Jun 28 15:09:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 07:09:12 -0700 Subject: [Patches] [ python-Patches-728815 ] test_timeout updates Message-ID: Patches item #728815, was opened at 2003-04-28 05:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) >Assigned to: Walter Dörwald (doerwalter) Summary: test_timeout updates Initial Comment: Changes: - code refactoring; - now we catch only exceptions with proper errno codes (also see bug #708927); - addr_remote changed, ('www.google.com', 80) not always works for me since we use transparent proxy; - attempt to implement testSend(), testSendto(), testSendall(); ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 09:09 Message: Logged In: YES user_id=80475 Walter, are you interested in working this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 From noreply@sourceforge.net Sat Jun 28 15:15:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 07:15:14 -0700 Subject: [Patches] [ python-Patches-703666 ] Several objects don't decref tmp on failure in subtype_new Message-ID: Patches item #703666, was opened at 2003-03-14 10:08 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=703666&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) >Assigned to: Raymond Hettinger (rhettinger) Summary: Several objects don't decref tmp on failure in subtype_new Initial Comment: Several objects have a something_subtype_new which creates a new object of a given subtype that if the subtype creation routine fails for any reason, returns NULL but leaves a temporary variable with a reference. The only normal reason this would occur is if you ran out of memory (in which case it wouldn't matter), but I don't think the core can predict that it knows that to be the only reason an unknown subtype might return NULL in it's alloc. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 16:34 Message: Logged In: YES user_id=33168 All of these look correct. Moving to patches. ---------------------------------------------------------------------- Comment By: Christopher A. Craig (ccraig) Date: 2003-03-17 10:18 Message: Logged In: YES user_id=135050 Apparently upload didn't take the first time ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=703666&group_id=5470 From noreply@sourceforge.net Sat Jun 28 21:07:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 13:07:12 -0700 Subject: [Patches] [ python-Patches-703666 ] Several objects don't decref tmp on failure in subtype_new Message-ID: Patches item #703666, was opened at 2003-03-14 10:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=703666&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Raymond Hettinger (rhettinger) Summary: Several objects don't decref tmp on failure in subtype_new Initial Comment: Several objects have a something_subtype_new which creates a new object of a given subtype that if the subtype creation routine fails for any reason, returns NULL but leaves a temporary variable with a reference. The only normal reason this would occur is if you ran out of memory (in which case it wouldn't matter), but I don't think the core can predict that it knows that to be the only reason an unknown subtype might return NULL in it's alloc. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:07 Message: Logged In: YES user_id=80475 Committed (with minor modifications) as: Objects/floatobject.c 2.124 Objects/intobject.c 2.105 Objects/longobject.c 1.161 Objects/unicodeobject.c 2.189 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 16:34 Message: Logged In: YES user_id=33168 All of these look correct. Moving to patches. ---------------------------------------------------------------------- Comment By: Christopher A. Craig (ccraig) Date: 2003-03-17 10:18 Message: Logged In: YES user_id=135050 Apparently upload didn't take the first time ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=703666&group_id=5470 From noreply@sourceforge.net Sat Jun 28 21:19:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 13:19:38 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 23:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sat Jun 28 21:21:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 13:21:08 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 23:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sat Jun 28 21:28:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 13:28:12 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 23:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sat Jun 28 22:17:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 14:17:54 -0700 Subject: [Patches] [ python-Patches-761104 ] adding BaseSet.filter and Set.filter_update Message-ID: Patches item #761104, was opened at 2003-06-26 12:15 Message generated for change (Comment added) made by gerrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761104&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: adding BaseSet.filter and Set.filter_update Initial Comment: Hi, as proposed in [0], this patch adds a method 'filter' to BaseSet and a method 'filter_update' to Set. I often see myself doing "newset = sets.Set(filter(f, someset))" or "someset = sets.Set(filter(f, someset))". This is now no longer necessary. I think this method is a good solution to this problem. I'm not sure whether it is correct to add my name to the code history since it is a small change. If this is not correct feel free to remove it. This patch also corrects the docstring: the docstring says _TemporarilyImmutableSet is not a subset of BaseSet, but it is. Gerrit. [0] http://groups.google.nl/groups?dq=&hl=nl&lr=&ie=UTF-8&oe=UTF-8&group=comp.lang.python&selm=mailman.1056577245.15021.python-list%40python.org ---------------------------------------------------------------------- >Comment By: Gerrit Holl (gerrit) Date: 2003-06-28 23:17 Message: Logged In: YES user_id=13298 Who decides whether it's rejected or accepted? If it's going to be rejected I won't put work in it, but if there's a chance of accept I will meet to those demands... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-26 20:45 Message: Logged In: YES user_id=80475 * I don't think this should be added to the API. filter() is a builtin because it can be used with many datatypes as an input. Most container contructors have a list format that is suitable for use with filter. It is not unduly burdensome to write: newset=Set(filter(f, oldset)). The existing approach is also more flexible because the user can opt for a list comprehension, itertools.ifilter, itertools.ifilterfalse, or any other suitable expression. * If this ends up getting accepted, consider using itertools and a simpler, factored implementation: def filter(self, f): return Set(ifilter(f, self._data)) * Also, a documentation patch and news item would be needed. * I agree with docstring patch and will apply just that piece. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761104&group_id=5470 From noreply@sourceforge.net Sat Jun 28 22:16:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 14:16:32 -0700 Subject: [Patches] [ python-Patches-762502 ] pep-283 outdated Message-ID: Patches item #762502, was opened at 2003-06-28 23:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762502&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: pep-283 outdated Initial Comment: Because py2.3b2 was delayed by a month, pep-283 is outdated. I'm not sure whether this patch is correct, but an update is necessary anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762502&group_id=5470 From noreply@sourceforge.net Sun Jun 29 03:58:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 19:58:13 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 21:55 Message generated for change (Comment added) made by rthalley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Bob Halley (rthalley) Date: 2003-06-28 19:58 Message: Logged In: YES user_id=671513 I don't think the patch can be much simpler than it is. We can't raise the exception inside of internal_select(), because we don't have the interpreter lock then. It's a good thing that we do not attempt the I/O after we know we have a timeout, since we don't want to actually do the I/O have it succeed after all, and then return "timeout". The other changes make sure result variables from the I/O are always initialized, to keep the compiler from issuing warnings. (There's no chance we'd actually use one of those variables in the timeout case, but some compilers can't figure that out.) I'll recheck things and post a followup message. I'll see what I can do about docs + unittests, though timezones aren't working in our favor at the moment (I'm in Australia right now). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sun Jun 29 04:04:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 20:04:45 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 23:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 22:04 Message: Logged In: YES user_id=80475 Guido has given me the go ahead to put it in eventhough we haven't had a chance for thorough review. I've looked at the code again and agree it cannot be further simplified -- that was just wishful thinking. The best thing to do right now is for you to desk check your patch one more time. I'll work on the doc update and newsitem. After your desk check, a couple of unittests would be very helpful. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:58 Message: Logged In: YES user_id=671513 I don't think the patch can be much simpler than it is. We can't raise the exception inside of internal_select(), because we don't have the interpreter lock then. It's a good thing that we do not attempt the I/O after we know we have a timeout, since we don't want to actually do the I/O have it succeed after all, and then return "timeout". The other changes make sure result variables from the I/O are always initialized, to keep the compiler from issuing warnings. (There's no chance we'd actually use one of those variables in the timeout case, but some compilers can't figure that out.) I'll recheck things and post a followup message. I'll see what I can do about docs + unittests, though timezones aren't working in our favor at the moment (I'm in Australia right now). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sun Jun 29 04:50:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 20:50:31 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 21:55 Message generated for change (Comment added) made by rthalley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Bob Halley (rthalley) Date: 2003-06-28 20:50 Message: Logged In: YES user_id=671513 OK, I'll write some unit tests now, and do another check of the code. I uploaded a doc patch since I'd already done it before I read your reply :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 20:04 Message: Logged In: YES user_id=80475 Guido has given me the go ahead to put it in eventhough we haven't had a chance for thorough review. I've looked at the code again and agree it cannot be further simplified -- that was just wishful thinking. The best thing to do right now is for you to desk check your patch one more time. I'll work on the doc update and newsitem. After your desk check, a couple of unittests would be very helpful. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 19:58 Message: Logged In: YES user_id=671513 I don't think the patch can be much simpler than it is. We can't raise the exception inside of internal_select(), because we don't have the interpreter lock then. It's a good thing that we do not attempt the I/O after we know we have a timeout, since we don't want to actually do the I/O have it succeed after all, and then return "timeout". The other changes make sure result variables from the I/O are always initialized, to keep the compiler from issuing warnings. (There's no chance we'd actually use one of those variables in the timeout case, but some compilers can't figure that out.) I'll recheck things and post a followup message. I'll see what I can do about docs + unittests, though timezones aren't working in our favor at the moment (I'm in Australia right now). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sun Jun 29 05:14:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 21:14:36 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 21:55 Message generated for change (Comment added) made by rthalley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:14 Message: Logged In: YES user_id=671513 Here is a unit test patch ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 20:50 Message: Logged In: YES user_id=671513 OK, I'll write some unit tests now, and do another check of the code. I uploaded a doc patch since I'd already done it before I read your reply :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 20:04 Message: Logged In: YES user_id=80475 Guido has given me the go ahead to put it in eventhough we haven't had a chance for thorough review. I've looked at the code again and agree it cannot be further simplified -- that was just wishful thinking. The best thing to do right now is for you to desk check your patch one more time. I'll work on the doc update and newsitem. After your desk check, a couple of unittests would be very helpful. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 19:58 Message: Logged In: YES user_id=671513 I don't think the patch can be much simpler than it is. We can't raise the exception inside of internal_select(), because we don't have the interpreter lock then. It's a good thing that we do not attempt the I/O after we know we have a timeout, since we don't want to actually do the I/O have it succeed after all, and then return "timeout". The other changes make sure result variables from the I/O are always initialized, to keep the compiler from issuing warnings. (There's no chance we'd actually use one of those variables in the timeout case, but some compilers can't figure that out.) I'll recheck things and post a followup message. I'll see what I can do about docs + unittests, though timezones aren't working in our favor at the moment (I'm in Australia right now). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sun Jun 29 05:19:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 21:19:02 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 21:55 Message generated for change (Comment added) made by rthalley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:19 Message: Logged In: YES user_id=671513 Use the later unit test patch; the first one had a cut-and-paste error (mentioned "UDP" in the error messages for TCP failures) ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:14 Message: Logged In: YES user_id=671513 Here is a unit test patch ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 20:50 Message: Logged In: YES user_id=671513 OK, I'll write some unit tests now, and do another check of the code. I uploaded a doc patch since I'd already done it before I read your reply :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 20:04 Message: Logged In: YES user_id=80475 Guido has given me the go ahead to put it in eventhough we haven't had a chance for thorough review. I've looked at the code again and agree it cannot be further simplified -- that was just wishful thinking. The best thing to do right now is for you to desk check your patch one more time. I'll work on the doc update and newsitem. After your desk check, a couple of unittests would be very helpful. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 19:58 Message: Logged In: YES user_id=671513 I don't think the patch can be much simpler than it is. We can't raise the exception inside of internal_select(), because we don't have the interpreter lock then. It's a good thing that we do not attempt the I/O after we know we have a timeout, since we don't want to actually do the I/O have it succeed after all, and then return "timeout". The other changes make sure result variables from the I/O are always initialized, to keep the compiler from issuing warnings. (There's no chance we'd actually use one of those variables in the timeout case, but some compilers can't figure that out.) I'll recheck things and post a followup message. I'll see what I can do about docs + unittests, though timezones aren't working in our favor at the moment (I'm in Australia right now). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sun Jun 29 05:31:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 21:31:08 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 21:55 Message generated for change (Comment added) made by rthalley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:31 Message: Logged In: YES user_id=671513 OK, I have reviewed the changes again and they look good to me. My only regret is that I don't have a windows compiler so I can't test on windows. I think the changes should work fine on windows, however, since the only place they differ from POSIX is internal_connect(), and that should be OK. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:19 Message: Logged In: YES user_id=671513 Use the later unit test patch; the first one had a cut-and-paste error (mentioned "UDP" in the error messages for TCP failures) ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:14 Message: Logged In: YES user_id=671513 Here is a unit test patch ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 20:50 Message: Logged In: YES user_id=671513 OK, I'll write some unit tests now, and do another check of the code. I uploaded a doc patch since I'd already done it before I read your reply :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 20:04 Message: Logged In: YES user_id=80475 Guido has given me the go ahead to put it in eventhough we haven't had a chance for thorough review. I've looked at the code again and agree it cannot be further simplified -- that was just wishful thinking. The best thing to do right now is for you to desk check your patch one more time. I'll work on the doc update and newsitem. After your desk check, a couple of unittests would be very helpful. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 19:58 Message: Logged In: YES user_id=671513 I don't think the patch can be much simpler than it is. We can't raise the exception inside of internal_select(), because we don't have the interpreter lock then. It's a good thing that we do not attempt the I/O after we know we have a timeout, since we don't want to actually do the I/O have it succeed after all, and then return "timeout". The other changes make sure result variables from the I/O are always initialized, to keep the compiler from issuing warnings. (There's no chance we'd actually use one of those variables in the timeout case, but some compilers can't figure that out.) I'll recheck things and post a followup message. I'll see what I can do about docs + unittests, though timezones aren't working in our favor at the moment (I'm in Australia right now). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sun Jun 29 05:38:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 21:38:04 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 23:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 23:38 Message: Logged In: YES user_id=80475 I've got it from here (including testing the windows environment and checking the doc markup). ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 23:31 Message: Logged In: YES user_id=671513 OK, I have reviewed the changes again and they look good to me. My only regret is that I don't have a windows compiler so I can't test on windows. I think the changes should work fine on windows, however, since the only place they differ from POSIX is internal_connect(), and that should be OK. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 23:19 Message: Logged In: YES user_id=671513 Use the later unit test patch; the first one had a cut-and-paste error (mentioned "UDP" in the error messages for TCP failures) ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 23:14 Message: Logged In: YES user_id=671513 Here is a unit test patch ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 22:50 Message: Logged In: YES user_id=671513 OK, I'll write some unit tests now, and do another check of the code. I uploaded a doc patch since I'd already done it before I read your reply :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 22:04 Message: Logged In: YES user_id=80475 Guido has given me the go ahead to put it in eventhough we haven't had a chance for thorough review. I've looked at the code again and agree it cannot be further simplified -- that was just wishful thinking. The best thing to do right now is for you to desk check your patch one more time. I'll work on the doc update and newsitem. After your desk check, a couple of unittests would be very helpful. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:58 Message: Logged In: YES user_id=671513 I don't think the patch can be much simpler than it is. We can't raise the exception inside of internal_select(), because we don't have the interpreter lock then. It's a good thing that we do not attempt the I/O after we know we have a timeout, since we don't want to actually do the I/O have it succeed after all, and then return "timeout". The other changes make sure result variables from the I/O are always initialized, to keep the compiler from issuing warnings. (There's no chance we'd actually use one of those variables in the timeout case, but some compilers can't figure that out.) I'll recheck things and post a followup message. I'll see what I can do about docs + unittests, though timezones aren't working in our favor at the moment (I'm in Australia right now). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sun Jun 29 05:44:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 21:44:31 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 23:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 23:44 Message: Logged In: YES user_id=80475 Please confirm that using a call to setdefaulttimeout() with also enable socket.timeout. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 23:38 Message: Logged In: YES user_id=80475 I've got it from here (including testing the windows environment and checking the doc markup). ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 23:31 Message: Logged In: YES user_id=671513 OK, I have reviewed the changes again and they look good to me. My only regret is that I don't have a windows compiler so I can't test on windows. I think the changes should work fine on windows, however, since the only place they differ from POSIX is internal_connect(), and that should be OK. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 23:19 Message: Logged In: YES user_id=671513 Use the later unit test patch; the first one had a cut-and-paste error (mentioned "UDP" in the error messages for TCP failures) ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 23:14 Message: Logged In: YES user_id=671513 Here is a unit test patch ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 22:50 Message: Logged In: YES user_id=671513 OK, I'll write some unit tests now, and do another check of the code. I uploaded a doc patch since I'd already done it before I read your reply :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 22:04 Message: Logged In: YES user_id=80475 Guido has given me the go ahead to put it in eventhough we haven't had a chance for thorough review. I've looked at the code again and agree it cannot be further simplified -- that was just wishful thinking. The best thing to do right now is for you to desk check your patch one more time. I'll work on the doc update and newsitem. After your desk check, a couple of unittests would be very helpful. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:58 Message: Logged In: YES user_id=671513 I don't think the patch can be much simpler than it is. We can't raise the exception inside of internal_select(), because we don't have the interpreter lock then. It's a good thing that we do not attempt the I/O after we know we have a timeout, since we don't want to actually do the I/O have it succeed after all, and then return "timeout". The other changes make sure result variables from the I/O are always initialized, to keep the compiler from issuing warnings. (There's no chance we'd actually use one of those variables in the timeout case, but some compilers can't figure that out.) I'll recheck things and post a followup message. I'll see what I can do about docs + unittests, though timezones aren't working in our favor at the moment (I'm in Australia right now). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sun Jun 29 05:56:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 21:56:27 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 23:55 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 23:44 Message: Logged In: YES user_id=80475 Please confirm that using a call to setdefaulttimeout() with also enable socket.timeout. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 23:38 Message: Logged In: YES user_id=80475 I've got it from here (including testing the windows environment and checking the doc markup). ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 23:31 Message: Logged In: YES user_id=671513 OK, I have reviewed the changes again and they look good to me. My only regret is that I don't have a windows compiler so I can't test on windows. I think the changes should work fine on windows, however, since the only place they differ from POSIX is internal_connect(), and that should be OK. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 23:19 Message: Logged In: YES user_id=671513 Use the later unit test patch; the first one had a cut-and-paste error (mentioned "UDP" in the error messages for TCP failures) ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 23:14 Message: Logged In: YES user_id=671513 Here is a unit test patch ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 22:50 Message: Logged In: YES user_id=671513 OK, I'll write some unit tests now, and do another check of the code. I uploaded a doc patch since I'd already done it before I read your reply :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 22:04 Message: Logged In: YES user_id=80475 Guido has given me the go ahead to put it in eventhough we haven't had a chance for thorough review. I've looked at the code again and agree it cannot be further simplified -- that was just wishful thinking. The best thing to do right now is for you to desk check your patch one more time. I'll work on the doc update and newsitem. After your desk check, a couple of unittests would be very helpful. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:58 Message: Logged In: YES user_id=671513 I don't think the patch can be much simpler than it is. We can't raise the exception inside of internal_select(), because we don't have the interpreter lock then. It's a good thing that we do not attempt the I/O after we know we have a timeout, since we don't want to actually do the I/O have it succeed after all, and then return "timeout". The other changes make sure result variables from the I/O are always initialized, to keep the compiler from issuing warnings. (There's no chance we'd actually use one of those variables in the timeout case, but some compilers can't figure that out.) I'll recheck things and post a followup message. I'll see what I can do about docs + unittests, though timezones aren't working in our favor at the moment (I'm in Australia right now). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 15:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Sun Jun 29 07:16:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 28 Jun 2003 23:16:03 -0700 Subject: [Patches] [ python-Patches-760257 ] add socket.timeout exception Message-ID: Patches item #760257, was opened at 2003-06-24 21:55 Message generated for change (Comment added) made by rthalley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Raymond Hettinger (rhettinger) Summary: add socket.timeout exception Initial Comment: Here's a patch for bug 758239. It adds a socket.timeout exception to the socket module, and raises that exception whenever a timeout occurs. I have tried to use a light hand, making only (hopefully) correctness-preserving edits as opposed to attempting any more radical restructuring of the way internal_select() is used. The diff is against the CVS current version of socketmodule.c. I have tested this by hand on my x86 Red Hat 9 system, and it works correctly. I have also done "make test" and had no failures related to the socket module (though I too am seeing a failure of test_strptime). I do not have a Windows build environment available to me, so I have not tested my changes on Windows. /Bob ---------------------------------------------------------------------- >Comment By: Bob Halley (rthalley) Date: 2003-06-28 23:16 Message: Logged In: YES user_id=671513 Confirmed. If I set a default timeout > 0.0 seconds, the socket.timeout exception happens as expected. If I set the default timeout to 0.0 or to None, socket.timeout is not raised, again as expected. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 21:44 Message: Logged In: YES user_id=80475 Please confirm that using a call to setdefaulttimeout() with also enable socket.timeout. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 21:38 Message: Logged In: YES user_id=80475 I've got it from here (including testing the windows environment and checking the doc markup). ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:31 Message: Logged In: YES user_id=671513 OK, I have reviewed the changes again and they look good to me. My only regret is that I don't have a windows compiler so I can't test on windows. I think the changes should work fine on windows, however, since the only place they differ from POSIX is internal_connect(), and that should be OK. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:19 Message: Logged In: YES user_id=671513 Use the later unit test patch; the first one had a cut-and-paste error (mentioned "UDP" in the error messages for TCP failures) ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 21:14 Message: Logged In: YES user_id=671513 Here is a unit test patch ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 20:50 Message: Logged In: YES user_id=671513 OK, I'll write some unit tests now, and do another check of the code. I uploaded a doc patch since I'd already done it before I read your reply :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 20:04 Message: Logged In: YES user_id=80475 Guido has given me the go ahead to put it in eventhough we haven't had a chance for thorough review. I've looked at the code again and agree it cannot be further simplified -- that was just wishful thinking. The best thing to do right now is for you to desk check your patch one more time. I'll work on the doc update and newsitem. After your desk check, a couple of unittests would be very helpful. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2003-06-28 19:58 Message: Logged In: YES user_id=671513 I don't think the patch can be much simpler than it is. We can't raise the exception inside of internal_select(), because we don't have the interpreter lock then. It's a good thing that we do not attempt the I/O after we know we have a timeout, since we don't want to actually do the I/O have it succeed after all, and then return "timeout". The other changes make sure result variables from the I/O are always initialized, to keep the compiler from issuing warnings. (There's no chance we'd actually use one of those variables in the timeout case, but some compilers can't figure that out.) I'll recheck things and post a followup message. I'll see what I can do about docs + unittests, though timezones aren't working in our favor at the moment (I'm in Australia right now). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:28 Message: Logged In: YES user_id=80475 If you're up to it, please also submit a patch for the docs and unittests. The next beta goes out in the morning so we only have a short time to get this done and make it perfect. Please also do a second desk check of your work, it is important that we don't break anything in this critical module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:21 Message: Logged In: YES user_id=80475 On a separate note, can you email to me the traceback from the failure on strptime? I would like to fix it but it won't fail for me on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 13:19 Message: Logged In: YES user_id=80475 I haven't yet been able to review this in detail. Is a simpler implementation possible (changing socket.error to socket.timeout and changing nothing else)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760257&group_id=5470 From noreply@sourceforge.net Mon Jun 30 00:48:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 29 Jun 2003 16:48:53 -0700 Subject: [Patches] [ python-Patches-762920 ] API Functions for PyArray Message-ID: Patches item #762920, was opened at 2003-06-29 18:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762920&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralph (kohanman) Assigned to: Nobody/Anonymous (nobody) Summary: API Functions for PyArray Initial Comment: I'd rather send and recieve PyArrays into my C modules since I often end up with a foo(int count, type *data) call anyway. Sure, there's NumPy for this sort of dirtywork, but this is so much more convienient. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762920&group_id=5470 From noreply@sourceforge.net Mon Jun 30 01:44:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 29 Jun 2003 17:44:22 -0700 Subject: [Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2 Message-ID: Patches item #762934, was opened at 2003-06-30 10:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: address test_time.py failures under Redhat 6.2 Initial Comment: A mangled version of this patch is also in bug: http://www.python.org/sf/728051 Looks like tzset(3) is broken under Redhat 6.2 in a way that wasn't being detected by configure. This patch adds stricter tzset(3) checking to configure.in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 From noreply@sourceforge.net Mon Jun 30 02:25:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 29 Jun 2003 18:25:37 -0700 Subject: [Patches] [ python-Patches-762502 ] pep-283 outdated Message-ID: Patches item #762502, was opened at 2003-06-28 17:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762502&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: pep-283 outdated Initial Comment: Because py2.3b2 was delayed by a month, pep-283 is outdated. I'm not sure whether this patch is correct, but an update is necessary anyway. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-29 21:25 Message: Logged In: YES user_id=33168 Jeremy made the same changes, so I'm closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762502&group_id=5470 From noreply@sourceforge.net Mon Jun 30 02:29:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 29 Jun 2003 18:29:27 -0700 Subject: [Patches] [ python-Patches-761865 ] patch against readline module to handle signals Message-ID: Patches item #761865, was opened at 2003-06-27 10:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761865&group_id=5470 Category: Modules Group: Python 2.2.x >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Keith Dart (kdart) Assigned to: Nobody/Anonymous (nobody) Summary: patch against readline module to handle signals Initial Comment: Attached is a patch against the readline module that hooks the readline event hook to call the PyErr_CheckSignals(). This way, Python signal handlers get run even if you are sitting at a readline prompt (where they didn't before). this solves a long-standing annoyance for me. whew. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-29 21:29 Message: Logged In: YES user_id=33168 Closing as duplicate of 761863. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761865&group_id=5470 From noreply@sourceforge.net Mon Jun 30 03:18:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 29 Jun 2003 19:18:54 -0700 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-30 02:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Doug Quale (quale) Assigned to: Nobody/Anonymous (nobody) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply@sourceforge.net Mon Jun 30 04:25:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 29 Jun 2003 20:25:38 -0700 Subject: [Patches] [ python-Patches-754870 ] SSL crash interpreter on error Message-ID: Patches item #754870, was opened at 2003-06-15 09:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754870&group_id=5470 >Category: Modules >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: SSL crash interpreter on error Initial Comment: When testing bug 739909, I provoked this bug. To reproduce: # ./python # need to be root to listen on privileged port >>> from socket import * >>> s = socket(AF_INET, SOCK_STREAM) >>> s.bind(('', 993)) >>> s.listen(5) >>> s.accept() # now go to another window and do: $ ./python >>> import imaplib >>> imaplib.IMAP4_SSL('localhost') # this will wait for the first (root) interpreter # exit from first/root interpreter and SSL will crash There is a stack trace below. The problem is that in PySSL_SetError(), there is an assumption that obj->Socket exists, but it doesn't in this case. The attached patch fixes the crash, but I'm not certain it is correct. #0 0x4046eaba in PySSL_SetError (obj=0x81e0718, ret=-1) at /home/neal/build/python/2_3/Modules/_ssl.c:118 #1 0x4046efed in newPySSLObject (Sock=0x4013f9c8, key_file=0x0, cert_file=0x0) at /home/neal/build/python/2_3/Modules/_ssl.c:259 #2 0x4046f181 in PySocket_ssl (self=0x0, args=0x403e4df4) at /home/neal/build/python/2_3/Modules/_ssl.c:296 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-29 23:25 Message: Logged In: YES user_id=33168 Checked in a modified version of the patch as: * Modules/_ssl.c 1.13 * Lib/test/test_socket_ssl.py 1.7 I can't see any negative consequences of this patch and it fixes a crash. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-16 09:31 Message: Logged In: YES user_id=33168 Moved to patches ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-06-15 15:26 Message: Logged In: YES user_id=38388 Sorry, no time for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754870&group_id=5470 From noreply@sourceforge.net Mon Jun 30 04:27:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 29 Jun 2003 20:27:58 -0700 Subject: [Patches] [ python-Patches-707900 ] bug fix 702858: deepcopying reflexive objects Message-ID: Patches item #707900, was opened at 2003-03-21 23:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707900&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Neal Norwitz (nnorwitz) Summary: bug fix 702858: deepcopying reflexive objects Initial Comment: A fix for bug 702858, which concerns the inability of copy.deepcopy to correctly process reflexive new-style class instances, that is, instances referring to themselves. The fix is one line; the other 51 lines in the patch are altered and enhanced altered tests in test_copy.py for this kind of thing. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-29 23:27 Message: Logged In: YES user_id=33168 I'm working on this (slowly). It wasn't a simple backport. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-13 15:29 Message: Logged In: YES user_id=6380 Reopened - Neal, would you mind backporting this to 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-13 15:27 Message: Logged In: YES user_id=6380 Looks fine to me; classic instances already did the same thing. Thanks, Steven! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 11:28 Message: Logged In: YES user_id=31435 Assigned to Guido because he knows more about this and I'm out of time for the next two days. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 10:42 Message: Logged In: YES user_id=33168 This patch works on 2.3. I'm not sure if this is fixing a bug or a feature. The change seems reasonable, but I don't know enough about copy to know if there are any negative consequences. I can check in if someone else agrees. Tim? Guido? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707900&group_id=5470 From noreply@sourceforge.net Mon Jun 30 11:30:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 03:30:42 -0700 Subject: [Patches] [ python-Patches-761969 ] -DPIC should be added for the -fPIC case Message-ID: Patches item #761969, was opened at 2003-06-28 03:22 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: -DPIC should be added for the -fPIC case Initial Comment: AFAIK -DPIC should always added when compiling with -DPIC. At least that's what libtool does and shown in many FAQs (like http://www.netbsd.org/Documentation/elf.html). A quick glance on NetBSD-current and FreeBSD (4.8) shows that it's evaluated in machine/asm.h. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-30 20:30 Message: Logged In: YES user_id=250749 I tested this patch on both FreeBSD 48 & 5.1. AFAICT, this did not affect behaviour of the interpreter either way. I note that you've tagged quite a few platforms in this patch, thus it would need to be tested on all affected platforms to be accepted in full. At this time, it isn't clear to me what benefits this patch gets us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 From noreply@sourceforge.net Mon Jun 30 11:33:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 03:33:06 -0700 Subject: [Patches] [ python-Patches-763111 ] mbcs encoding should skip encodings package Message-ID: Patches item #763111, was opened at 2003-06-30 20:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763111&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: mbcs encoding should skip encodings package Initial Comment: PyUnicode_Decode and PyUnicode_AsEncodedString should have a "short circuit" for the 'mbcs' encoding, as already exists for "utf8" and "latin1" and "ascii". This prevents Win9x from using the encodings module for all os.* functions with unicode support. This also adds PyUnicode_AsMBCSString, which was declared but not implemented. If no objections within a few days, I will check this in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763111&group_id=5470 From noreply@sourceforge.net Mon Jun 30 13:37:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 05:37:09 -0700 Subject: [Patches] [ python-Patches-728815 ] test_timeout updates Message-ID: Patches item #728815, was opened at 2003-04-28 12:21 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) >Assigned to: Raymond Hettinger (rhettinger) Summary: test_timeout updates Initial Comment: Changes: - code refactoring; - now we catch only exceptions with proper errno codes (also see bug #708927); - addr_remote changed, ('www.google.com', 80) not always works for me since we use transparent proxy; - attempt to implement testSend(), testSendto(), testSendall(); ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 14:37 Message: Logged In: YES user_id=89016 I'm no expert in socket programming, so the final decision whether this is OK is your's. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 16:09 Message: Logged In: YES user_id=80475 Walter, are you interested in working this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 From noreply@sourceforge.net Mon Jun 30 14:48:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 06:48:26 -0700 Subject: [Patches] [ python-Patches-763201 ] 3 bugs fixed: handling of SyntaxErrors in symbol table build Message-ID: Patches item #763201, was opened at 2003-06-30 07:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763201&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: 3 bugs fixed: handling of SyntaxErrors in symbol table build Initial Comment: All three bugs found in both 2.2.3 and 2.3b2. It's one patch instead of three because the fixes share a refactoring of Python/compile.c:symtable_build. Bug 1: Wrong file name import symtable symtable.symtable('def foo(a): global a', 'spam', 'exec') The error message says '' instead of 'spam'. (Cause: PyNode_CompileSymtable doesn't set st_filename.) Bug 2: Memory leak while True: try: compile('def foo(a): global a', 'spam', 'exec') except SyntaxError: pass (Cause: symtable_build doesn't free c->c_symtable on error.) The patch is missing a test case for this one; I don't see how to write it. Bug 3: Exception clobbered def foo(a): global a # SyntaxError def bar(): b = 1 global b # SyntaxWarning Running this as a script, the SyntaxWarning is issued, and then the interpreter dies silently (that is, without printing a traceback reporting the SyntaxError). Compiling it with compile() causes a SystemError. (Cause: see below.) What to do about bugs 1 and 2 is obvious, but bug 3 (which was actually reported on c.l.py) is not so clear to me. Here's how the problem occurs: symtable_global() sees the global statement in foo(), raises a SyntaxError, increments st_errors, and returns. Processing continues. Later, symtable_global() sees the global statement in bar() and issues a warning by (indirectly) calling PyErr_WarnExplicit(). This call clears the SyntaxError, which is still pending at that time. (It's actually cleared during the attempt to import the warnings module, in PyImport_Import, which seems to think the exception was raised in PyEval_GetGlobals.) But st_errors is still > 0, as it should be, so symtable_build() returns -1 (resp. PyNode_CompileSymtable, NULL), its callers return their error values, etc., until eventually PyErr_Print tries to print the exception that isn't there. What the patch implements is this: Do not issue SyntaxWarnings if an exception is pending; fail instead and let that exception propagate. Also, as a defensive measure against other bugs of this type (present and future), when returning with error from symtable_build(), verify that there's an exception pending (and raise SystemError if not). Finally, refactor symtable_build() so PyNode_CompileSymtable can use it and thereby benefit from that defensive measure. Alternatives (and why I don't like them): 1. Do not try to continue processing after a SyntaxError is raised. (Seems like the Right Thing to me, but also seems to be contrary to the intent of the existing code. There are oodles of places in compile.c which call symtable_node without checking st_errors immediately afterwards.) 2. Put the check for a pending exception in PyErr_WarnExplicit() instead of in the helper function in compile.c. (Doesn't seem like a common enough coding error to merit a check there. In symtable_node etc we deliberately let SyntaxErrors, er, "pend" while we do a bit more compiling, so *there* it's worth checking. Note that jcompile() already has a check for something similar, though not for the symbol-table-building phase.) 3. Squirrel the pending exception away, issue the warning, then restore the exception. (Not worth the bother, IMO. And if the warning gets strengthened into an exception, should that exception or the squirrelled one propagate? Ick.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763201&group_id=5470 From noreply@sourceforge.net Mon Jun 30 15:52:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 07:52:35 -0700 Subject: [Patches] [ python-Patches-728815 ] test_timeout updates Message-ID: Patches item #728815, was opened at 2003-04-28 05:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Raymond Hettinger (rhettinger) Summary: test_timeout updates Initial Comment: Changes: - code refactoring; - now we catch only exceptions with proper errno codes (also see bug #708927); - addr_remote changed, ('www.google.com', 80) not always works for me since we use transparent proxy; - attempt to implement testSend(), testSendto(), testSendall(); ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 07:37 Message: Logged In: YES user_id=89016 I'm no expert in socket programming, so the final decision whether this is OK is your's. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 09:09 Message: Logged In: YES user_id=80475 Walter, are you interested in working this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 From noreply@sourceforge.net Mon Jun 30 15:52:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 07:52:45 -0700 Subject: [Patches] [ python-Patches-728815 ] test_timeout updates Message-ID: Patches item #728815, was opened at 2003-04-28 05:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Raymond Hettinger (rhettinger) Summary: test_timeout updates Initial Comment: Changes: - code refactoring; - now we catch only exceptions with proper errno codes (also see bug #708927); - addr_remote changed, ('www.google.com', 80) not always works for me since we use transparent proxy; - attempt to implement testSend(), testSendto(), testSendall(); ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 07:37 Message: Logged In: YES user_id=89016 I'm no expert in socket programming, so the final decision whether this is OK is your's. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 09:09 Message: Logged In: YES user_id=80475 Walter, are you interested in working this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 From noreply@sourceforge.net Mon Jun 30 15:52:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 07:52:50 -0700 Subject: [Patches] [ python-Patches-728815 ] test_timeout updates Message-ID: Patches item #728815, was opened at 2003-04-28 05:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Raymond Hettinger (rhettinger) Summary: test_timeout updates Initial Comment: Changes: - code refactoring; - now we catch only exceptions with proper errno codes (also see bug #708927); - addr_remote changed, ('www.google.com', 80) not always works for me since we use transparent proxy; - attempt to implement testSend(), testSendto(), testSendall(); ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 07:37 Message: Logged In: YES user_id=89016 I'm no expert in socket programming, so the final decision whether this is OK is your's. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 09:09 Message: Logged In: YES user_id=80475 Walter, are you interested in working this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 From noreply@sourceforge.net Mon Jun 30 15:55:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 07:55:21 -0700 Subject: [Patches] [ python-Patches-728815 ] test_timeout updates Message-ID: Patches item #728815, was opened at 2003-04-28 05:21 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 Category: Tests >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Raymond Hettinger (rhettinger) Summary: test_timeout updates Initial Comment: Changes: - code refactoring; - now we catch only exceptions with proper errno codes (also see bug #708927); - addr_remote changed, ('www.google.com', 80) not always works for me since we use transparent proxy; - attempt to implement testSend(), testSendto(), testSendall(); ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 07:37 Message: Logged In: YES user_id=89016 I'm no expert in socket programming, so the final decision whether this is OK is your's. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 09:09 Message: Logged In: YES user_id=80475 Walter, are you interested in working this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 From noreply@sourceforge.net Mon Jun 30 16:57:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 08:57:11 -0700 Subject: [Patches] [ python-Patches-763201 ] 3 bugs fixed: handling of SyntaxErrors in symbol table build Message-ID: Patches item #763201, was opened at 2003-06-30 13:48 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763201&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Steven Taschuk (staschuk) >Assigned to: Jeremy Hylton (jhylton) Summary: 3 bugs fixed: handling of SyntaxErrors in symbol table build Initial Comment: All three bugs found in both 2.2.3 and 2.3b2. It's one patch instead of three because the fixes share a refactoring of Python/compile.c:symtable_build. Bug 1: Wrong file name import symtable symtable.symtable('def foo(a): global a', 'spam', 'exec') The error message says '' instead of 'spam'. (Cause: PyNode_CompileSymtable doesn't set st_filename.) Bug 2: Memory leak while True: try: compile('def foo(a): global a', 'spam', 'exec') except SyntaxError: pass (Cause: symtable_build doesn't free c->c_symtable on error.) The patch is missing a test case for this one; I don't see how to write it. Bug 3: Exception clobbered def foo(a): global a # SyntaxError def bar(): b = 1 global b # SyntaxWarning Running this as a script, the SyntaxWarning is issued, and then the interpreter dies silently (that is, without printing a traceback reporting the SyntaxError). Compiling it with compile() causes a SystemError. (Cause: see below.) What to do about bugs 1 and 2 is obvious, but bug 3 (which was actually reported on c.l.py) is not so clear to me. Here's how the problem occurs: symtable_global() sees the global statement in foo(), raises a SyntaxError, increments st_errors, and returns. Processing continues. Later, symtable_global() sees the global statement in bar() and issues a warning by (indirectly) calling PyErr_WarnExplicit(). This call clears the SyntaxError, which is still pending at that time. (It's actually cleared during the attempt to import the warnings module, in PyImport_Import, which seems to think the exception was raised in PyEval_GetGlobals.) But st_errors is still > 0, as it should be, so symtable_build() returns -1 (resp. PyNode_CompileSymtable, NULL), its callers return their error values, etc., until eventually PyErr_Print tries to print the exception that isn't there. What the patch implements is this: Do not issue SyntaxWarnings if an exception is pending; fail instead and let that exception propagate. Also, as a defensive measure against other bugs of this type (present and future), when returning with error from symtable_build(), verify that there's an exception pending (and raise SystemError if not). Finally, refactor symtable_build() so PyNode_CompileSymtable can use it and thereby benefit from that defensive measure. Alternatives (and why I don't like them): 1. Do not try to continue processing after a SyntaxError is raised. (Seems like the Right Thing to me, but also seems to be contrary to the intent of the existing code. There are oodles of places in compile.c which call symtable_node without checking st_errors immediately afterwards.) 2. Put the check for a pending exception in PyErr_WarnExplicit() instead of in the helper function in compile.c. (Doesn't seem like a common enough coding error to merit a check there. In symtable_node etc we deliberately let SyntaxErrors, er, "pend" while we do a bit more compiling, so *there* it's worth checking. Note that jcompile() already has a check for something similar, though not for the symbol-table-building phase.) 3. Squirrel the pending exception away, issue the warning, then restore the exception. (Not worth the bother, IMO. And if the warning gets strengthened into an exception, should that exception or the squirrelled one propagate? Ick.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763201&group_id=5470 From noreply@sourceforge.net Mon Jun 30 17:11:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 09:11:22 -0700 Subject: [Patches] [ python-Patches-759208 ] curses has_key emulation fix Message-ID: Patches item #759208, was opened at 2003-06-23 09:14 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=759208&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Mats Wichmann (mwichmann) Assigned to: Nobody/Anonymous (nobody) Summary: curses has_key emulation fix Initial Comment: curses/has_key.py provides emulation for the ncurses has_key routine for those that don't have it. Out-of- range has_key requests cause a KeyError exception. Note that the curses regression test makes such a request! The attached trivial patch makes has_key more robust. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 12:11 Message: Logged In: YES user_id=6380 Looks harmless to me. Somebody please check this in. (Personally, I'd change the logic around so it reads: if not _capability_names.has_key(ch): return 0 ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=759208&group_id=5470 From noreply@sourceforge.net Mon Jun 30 17:13:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 09:13:25 -0700 Subject: [Patches] [ python-Patches-761104 ] adding BaseSet.filter and Set.filter_update Message-ID: Patches item #761104, was opened at 2003-06-26 06:15 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761104&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: adding BaseSet.filter and Set.filter_update Initial Comment: Hi, as proposed in [0], this patch adds a method 'filter' to BaseSet and a method 'filter_update' to Set. I often see myself doing "newset = sets.Set(filter(f, someset))" or "someset = sets.Set(filter(f, someset))". This is now no longer necessary. I think this method is a good solution to this problem. I'm not sure whether it is correct to add my name to the code history since it is a small change. If this is not correct feel free to remove it. This patch also corrects the docstring: the docstring says _TemporarilyImmutableSet is not a subset of BaseSet, but it is. Gerrit. [0] http://groups.google.nl/groups?dq=&hl=nl&lr=&ie=UTF-8&oe=UTF-8&group=comp.lang.python&selm=mailman.1056577245.15021.python-list%40python.org ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 12:13 Message: Logged In: YES user_id=6380 Raymond can decide to reject it. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-06-28 17:17 Message: Logged In: YES user_id=13298 Who decides whether it's rejected or accepted? If it's going to be rejected I won't put work in it, but if there's a chance of accept I will meet to those demands... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-26 14:45 Message: Logged In: YES user_id=80475 * I don't think this should be added to the API. filter() is a builtin because it can be used with many datatypes as an input. Most container contructors have a list format that is suitable for use with filter. It is not unduly burdensome to write: newset=Set(filter(f, oldset)). The existing approach is also more flexible because the user can opt for a list comprehension, itertools.ifilter, itertools.ifilterfalse, or any other suitable expression. * If this ends up getting accepted, consider using itertools and a simpler, factored implementation: def filter(self, f): return Set(ifilter(f, self._data)) * Also, a documentation patch and news item would be needed. * I agree with docstring patch and will apply just that piece. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761104&group_id=5470 From noreply@sourceforge.net Mon Jun 30 17:14:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 09:14:25 -0700 Subject: [Patches] [ python-Patches-763111 ] mbcs encoding should skip encodings package Message-ID: Patches item #763111, was opened at 2003-06-30 12:33 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763111&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: mbcs encoding should skip encodings package Initial Comment: PyUnicode_Decode and PyUnicode_AsEncodedString should have a "short circuit" for the 'mbcs' encoding, as already exists for "utf8" and "latin1" and "ascii". This prevents Win9x from using the encodings module for all os.* functions with unicode support. This also adds PyUnicode_AsMBCSString, which was declared but not implemented. If no objections within a few days, I will check this in. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-06-30 18:14 Message: Logged In: YES user_id=38388 Looks good. Please check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763111&group_id=5470 From noreply@sourceforge.net Mon Jun 30 17:14:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 09:14:54 -0700 Subject: [Patches] [ python-Patches-761401 ] DISTUTILS_DEBUG undocumented Message-ID: Patches item #761401, was opened at 2003-06-26 15:53 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761401&group_id=5470 Category: Distutils and setup.py Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: DISTUTILS_DEBUG undocumented Initial Comment: The DISTUTILS_DEBUG environment variable is undocumented, but it is very helpful when a setup script doesn't do what the developer wants. This patch adds a small section to the Distributing Python Modules manual, section 3: writing the setup script. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 12:14 Message: Logged In: YES user_id=6380 Good idea. Somebody check this in, please! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761401&group_id=5470 From noreply@sourceforge.net Mon Jun 30 17:22:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 09:22:03 -0700 Subject: [Patches] [ python-Patches-761863 ] readline module that checks signals Message-ID: Patches item #761863, was opened at 2003-06-27 10:22 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761863&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Keith Dart (kdart) Assigned to: Nobody/Anonymous (nobody) Summary: readline module that checks signals Initial Comment: Attached is a patch against the readline module that hooks the readline event hook to call the PyErr_CheckSignals(). This way, Python signal handlers get run even if you are sitting at a readline prompt (where they didn't before). this solves a long-standing annoyance for me. whew. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 12:22 Message: Logged In: YES user_id=6380 Sorry, I don't think this is correct. The code ignores errors from PyErr_CheckSignals(). What will happen to an exception raised by the handler call? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761863&group_id=5470 From noreply@sourceforge.net Mon Jun 30 17:27:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 09:27:43 -0700 Subject: [Patches] [ python-Patches-761969 ] -DPIC should be added for the -fPIC case Message-ID: Patches item #761969, was opened at 2003-06-27 13:22 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: -DPIC should be added for the -fPIC case Initial Comment: AFAIK -DPIC should always added when compiling with -DPIC. At least that's what libtool does and shown in many FAQs (like http://www.netbsd.org/Documentation/elf.html). A quick glance on NetBSD-current and FreeBSD (4.8) shows that it's evaluated in machine/asm.h. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 12:27 Message: Logged In: YES user_id=6380 Adding -DPIC just adds a preprocessor symbol, and not a very distinguished one. If FreeBSD really needs this particular #define to work correctly when compiling with -fPIC, perhaps a FreeBSD-specific patch would be acceptable. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-30 06:30 Message: Logged In: YES user_id=250749 I tested this patch on both FreeBSD 48 & 5.1. AFAICT, this did not affect behaviour of the interpreter either way. I note that you've tagged quite a few platforms in this patch, thus it would need to be tested on all affected platforms to be accepted in full. At this time, it isn't clear to me what benefits this patch gets us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 From noreply@sourceforge.net Mon Jun 30 20:34:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 12:34:07 -0700 Subject: [Patches] [ python-Patches-761401 ] DISTUTILS_DEBUG undocumented Message-ID: Patches item #761401, was opened at 2003-06-26 21:53 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761401&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: DISTUTILS_DEBUG undocumented Initial Comment: The DISTUTILS_DEBUG environment variable is undocumented, but it is very helpful when a setup script doesn't do what the developer wants. This patch adds a small section to the Distributing Python Modules manual, section 3: writing the setup script. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-06-30 21:34 Message: Logged In: YES user_id=11105 Checked in as dist.tex rev 1.55 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 18:14 Message: Logged In: YES user_id=6380 Good idea. Somebody check this in, please! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761401&group_id=5470