From noreply@sourceforge.net Thu May 1 05:43:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 21:43:59 -0700 Subject: [Patches] [ python-Patches-730594 ] assert from longobject.c, line 1215 Message-ID: Patches item #730594, was opened at 2003-05-01 14:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Johns (cjohns) Assigned to: Nobody/Anonymous (nobody) Summary: assert from longobject.c, line 1215 Initial Comment: RTEMS port running on the Coldfire (m5200) processor. RTEMS is version 4.6.0pre3 and the lastest RTEMS tool set. The target is m68k-rtems. GCC 3.2.2 and GCC 3.2.3 both cause the assert in the file: Objects/longmodule.c:1215 The assert test is in the function 'long_from_binary_base': assert(k < base); The assert and related code is valid, gcc is generating bad code. The bad code is related to the "digit" variable k being a short and the base being an int (32bit on Coldfire). GCC seems to get a little confused about which 16bit half to compare against. The simple fix is to make "k" an int and so be the same size as base. The 'k' variable is an int in the loop just above that figures out the total number of bits needed. This change also generated faster code for the Coldfire. I know a selection of one CPU is not a valid analysis, how-ever base and k being the same seemed to help gcc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470 From noreply@sourceforge.net Thu May 1 05:50:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 21:50:11 -0700 Subject: [Patches] [ python-Patches-730597 ] RTEMS does not have a popen Message-ID: Patches item #730597, was opened at 2003-05-01 14:50 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=730597&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Johns (cjohns) Assigned to: Nobody/Anonymous (nobody) Summary: RTEMS does not have a popen Initial Comment: RTEMS port of Python. RTEMS supports POSIX but does not have a popen. RTEMS is a realtime operating system and has a single address space and no MMU so no fork, vfork or popen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730597&group_id=5470 From noreply@sourceforge.net Thu May 1 05:51:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 21:51:45 -0700 Subject: [Patches] [ python-Patches-730594 ] assert from longobject.c, line 1215 Message-ID: Patches item #730594, was opened at 2003-05-01 14:43 Message generated for change (Comment added) made by cjohns You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Johns (cjohns) Assigned to: Nobody/Anonymous (nobody) Summary: assert from longobject.c, line 1215 Initial Comment: RTEMS port running on the Coldfire (m5200) processor. RTEMS is version 4.6.0pre3 and the lastest RTEMS tool set. The target is m68k-rtems. GCC 3.2.2 and GCC 3.2.3 both cause the assert in the file: Objects/longmodule.c:1215 The assert test is in the function 'long_from_binary_base': assert(k < base); The assert and related code is valid, gcc is generating bad code. The bad code is related to the "digit" variable k being a short and the base being an int (32bit on Coldfire). GCC seems to get a little confused about which 16bit half to compare against. The simple fix is to make "k" an int and so be the same size as base. The 'k' variable is an int in the loop just above that figures out the total number of bits needed. This change also generated faster code for the Coldfire. I know a selection of one CPU is not a valid analysis, how-ever base and k being the same seemed to help gcc. ---------------------------------------------------------------------- >Comment By: Chris Johns (cjohns) Date: 2003-05-01 14:51 Message: Logged In: YES user_id=197074 Be a good idea if I read the instructions and checked the patch attached box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470 From noreply@sourceforge.net Thu May 1 06:05:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 22:05:14 -0700 Subject: [Patches] [ python-Patches-730603 ] socketmodule inet_ntop built when IPV6 is disabled Message-ID: Patches item #730603, was opened at 2003-05-01 15:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730603&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Johns (cjohns) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule inet_ntop built when IPV6 is disabled Initial Comment: RTEMS does not support IPV6 and so does not define ENABLE_IPV6 for Python. RTEMS contains an aging port of the FreeBSD stack and the port contains some IPV6 things such as inet_ntop and inet_pton. This causes HAVE_INET_PTON to be defined to 1 causing the current socketmodule.c to compile the socket_inet_ntop code. The assumption being these functions are only present with IPV6 stacks. This assumption is valid, how-ever RTEMS breaks this assuption and fixing this in RTEMS is not pratical. Removing the HAVE_INET_PTON definition causes socketmodule.c to compile in a private version. The private versions have a slightly different prototype to RTEMS and so the compiler stops with an error. This patch seems the simplest solutions given it does not effect other platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730603&group_id=5470 From noreply@sourceforge.net Thu May 1 06:05:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 22:05:44 -0700 Subject: [Patches] [ python-Patches-727805 ] Remove extra line ending in CGI XML-RPC responses Message-ID: Patches item #727805, was opened at 2003-04-26 01:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727805&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Martin v. Löwis (loewis) Summary: Remove extra line ending in CGI XML-RPC responses Initial Comment: CGI XML-RPC output was being generated as follows: print 'Content-Type: text/xml' print 'Content-Length: %d' % len(response) print print response Since the print statement appends a line ending to its output, the content-length reported was incorrect. Some clients don't like this. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-01 07:05 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as DocXMLRPCServer.py 1.3 SimpleXMLRPCServer.py 1.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727805&group_id=5470 From noreply@sourceforge.net Thu May 1 06:23:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 22:23:38 -0700 Subject: [Patches] [ python-Patches-725942 ] Modules/addrinfo.h patch Message-ID: Patches item #725942, was opened at 2003-04-23 01:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725942&group_id=5470 Category: Modules Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David Wood (woodd) Assigned to: Martin v. Löwis (loewis) Summary: Modules/addrinfo.h patch Initial Comment: I've compiled / linked Python 2.2.2 on Solaris 2.6 for both of my Solaris releases (Solaris 2.6 & Solaris 8). Python works fine on Solaris 2.6; however, on Solaris 2.8 I get the following: File "/usr/local/lib/python2.2/SocketServer.py", line 340, in server_bind self.socket.bind(self.server_address) socket.gaierror: (3, 'getaddrinfo failed') Solaris 2.6 does not have getaddrinfo but Solaris 8 does. The failure occurs on Solaris 8 because Python finds getaddrinfo in /usr/lib/libsocket.so before /usr/local/lib/python2.2/lib-dynload/_socket.so. The return code of 3 (EAI_BADFLAGS) is a result of ai_flags mismatch: bsqa1.nyc:/u/woodd > grep 'define.AI_PASSIVE' Python-2.2.2/Modules/addrinfo.h #define AI_PASSIVE 0x00000001 /* get address to use bind() */ bsqa1.nyc:/u/woodd > grep 'define.AI_PASSIVE' /usr/include/netdb.h #define AI_PASSIVE 0x0008 /* intended for bind() + listen() */ The enclosed patch is simple: always "#define getaddrinfo fake_getaddrinfo" if we don't have getaddrinfo. The same applies for getnameinfo. The enclosed patch is against v2.2.2 Modules/addrinfo.h. David ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-01 07:23 Message: Logged In: YES user_id=21627 The patch in this form is insufficient; there are more functions that may clash if a getaddrinfo suddenly appears. I have committed a similar patch as socketmodule.c 1.261. As for whether there are other occurrences of that problem: it is asked too much to review the code base in this respect. However, feel free to submit patches correcting further occurrences if you find any. ---------------------------------------------------------------------- Comment By: David Wood (woodd) Date: 2003-04-26 00:00 Message: Logged In: YES user_id=62760 > Apparently, Sun cannot deliver what it promises: Here we > have a piece of software built for Solaris 2.6 which breaks > on later versions. Haha - you have me there :-). > In general, I think Python cannot guarantee that this won't > happen again: There might always be the need to emulate > some function not available on a certain operating system > which then gets added in later releases of the operating > system, in an incompatible fashion. I would never ask for a guarantee; however, would it be too much to ask that well know public interfaces such as getaddrinfo() be emulated with not so well known internal names? I wasn't the one who invented fake_getaddrinfo afterall - look at socketmodule.c (line 230 v2.2.2 MAC OS X). > I think there is a chance that some of the 300+ packages > show the same problem, and you just haven't noticed yet. Unlikely. > In any case, I'll consider the patch for inclusion after 2.3b1 Thanks. David ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-25 23:39 Message: Logged In: YES user_id=21627 Apparently, Sun cannot deliver what it promises: Here we have a piece of software built for Solaris 2.6 which breaks on later versions. In general, I think Python cannot guarantee that this won't happen again: There might always be the need to emulate some function not available on a certain operating system which then gets added in later releases of the operating system, in an incompatible fashion. I cannot even guarantee that this doesn't happen for your specific installation if the problem at hand is solved, and I think there is a chance that some of the 300+ packages show the same problem, and you just haven't noticed yet. In any case, I'll consider the patch for inclusion after 2.3b1 ---------------------------------------------------------------------- Comment By: David Wood (woodd) Date: 2003-04-25 22:50 Message: Logged In: YES user_id=62760 Let me ask a hypothetical (and admittedly facetious) question - if I had Solaris 2.5.1, 2.6, 7, 8, 9 would I need to maintain 5 installations of Python? Seriously though, I don't think it's unreasonable to expect backwards compatibility. Sun promises to deliver operating systems such that any piece of code compiled/linked on Solaris 2.6 for example will run without modification on Solaris 7, 8, 9, etc. If Python is going to break after Solaris release upgrades I'd rather not have it on my systems at all. Of the 300+ packages I have compiled/installed in /usr/local only 5 (sysinfo, scsiinfo, lsof, etc) require version specific installations. Notice Perl is not in that list ;-). The version specific installations are warranted as these packages operate at a very low level (directly with hardware device drivers). Python operates at a very high level using fairly standard library calls; therefore, this really shouldn't be necessary. David ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-25 21:07 Message: Logged In: YES user_id=21627 I'm not sure I want to support this. Shouldn't you build two installations of Python instead? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725942&group_id=5470 From noreply@sourceforge.net Thu May 1 16:48:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 08:48:42 -0700 Subject: [Patches] [ python-Patches-730826 ] Patch for NetBSD to activate all library features Message-ID: Patches item #730826, was opened at 2003-05-01 17: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=730826&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for NetBSD to activate all library features Initial Comment: NetBSD-current (as of last week), the upcoming 2.0, supports a define _NETBSD_SOURCE to activate all library features. It works similar to the _GNU_SOURCE define on Linux/glibc and the __EXTENSIONS__ define on Solaris. It is needed to compile the modules(/functions) that need functionaly that isn't available in a strict POSIX environment, eg. RPC, some socket related stuff (inet_[a|p]ton) and maybe more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730826&group_id=5470 From noreply@sourceforge.net Thu May 1 17:54:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 09:54:42 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 18:54 Message: Logged In: YES user_id=89016 I've changed test_support.run_unittest() to work like your run_classtests() and changed all test scripts to use this. (see diff2.txt) I compared the output of ./python Lib/test/regrtest.py -v 2>&1 | grep -v "Ran.*test.*in" and apart from the fact that test_csv seems to be more verbose now, there seem to be no regression bugs. Raymond, can you check, if this is OK? BTW, there's another check for memory leaks in test_datetime.py. Perhaps it would make sense to combine both and use them globally in regrtest.py (or test_support.py)? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-29 23:39 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_richcmp.py 1.8 Lib/test/output/test_richcmp delete which a few additional tests and comments. I'll probably work on using run_classtests() tomorrow, but wouldn't it be simpler to add the multiple arguments to the already existing function run_unittest() instead of introducing the new run_classtests()? > BTW, why is the int to int comparison labeled as useless? Because it would check whether comparing two ints gives the same result as comparing the same two ints. ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 21:10 Message: Logged In: YES user_id=80475 Yes. test_support.run_classtests() ought to be used everywhere it is applicable. There are a couple of places like test_sets.py where the "suite" variable is used again for other purposed (testing for memory leaks). In those cases, it ought to be left alone until I can write a function that encapsulates the essense of the combined test. test_richcmp.py looks good. Please add comment lines describing the point of classes and tests whose names are not self explanatory (i.e. misbehavin, weird, etc). BTW, why is the int to int comparison labeled as useless? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-28 20:42 Message: Logged In: YES user_id=89016 Here's the next one: test_richcmp.py with a few additional tests to increase code coverage in object.c and listobject.c. BTW, should we change all tests to use the new test_support.run_classtests()? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-25 13:40 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_bool.py 1.9 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 23:00 Message: Logged In: YES user_id=6380 I suggest not to mess with unittest.py; it is still externally maintained as PyUnit. Maybe ask the PyUnit developer. No time to review the test, sorry; if it works, I suggest to just check it in. ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 22:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 13:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-15 01:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 14:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 11:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Thu May 1 18:17:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 10:17:55 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 12:17 Message: Logged In: YES user_id=80475 My preference was to keep run_classtests() as a separate function. The run_unittest() function was unique in that it called run_suite() with two arguments instead of one. That accounts for the additional verbosity you are seeing. While I prefer the separate run_classtests(), it's up to you to do whichever seems best. Otherwise, all looks okay. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 11:54 Message: Logged In: YES user_id=89016 I've changed test_support.run_unittest() to work like your run_classtests() and changed all test scripts to use this. (see diff2.txt) I compared the output of ./python Lib/test/regrtest.py -v 2>&1 | grep -v "Ran.*test.*in" and apart from the fact that test_csv seems to be more verbose now, there seem to be no regression bugs. Raymond, can you check, if this is OK? BTW, there's another check for memory leaks in test_datetime.py. Perhaps it would make sense to combine both and use them globally in regrtest.py (or test_support.py)? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-29 16:39 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_richcmp.py 1.8 Lib/test/output/test_richcmp delete which a few additional tests and comments. I'll probably work on using run_classtests() tomorrow, but wouldn't it be simpler to add the multiple arguments to the already existing function run_unittest() instead of introducing the new run_classtests()? > BTW, why is the int to int comparison labeled as useless? Because it would check whether comparing two ints gives the same result as comparing the same two ints. ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 14:10 Message: Logged In: YES user_id=80475 Yes. test_support.run_classtests() ought to be used everywhere it is applicable. There are a couple of places like test_sets.py where the "suite" variable is used again for other purposed (testing for memory leaks). In those cases, it ought to be left alone until I can write a function that encapsulates the essense of the combined test. test_richcmp.py looks good. Please add comment lines describing the point of classes and tests whose names are not self explanatory (i.e. misbehavin, weird, etc). BTW, why is the int to int comparison labeled as useless? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-28 13:42 Message: Logged In: YES user_id=89016 Here's the next one: test_richcmp.py with a few additional tests to increase code coverage in object.c and listobject.c. BTW, should we change all tests to use the new test_support.run_classtests()? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-25 06:40 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_bool.py 1.9 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 16:00 Message: Logged In: YES user_id=6380 I suggest not to mess with unittest.py; it is still externally maintained as PyUnit. Maybe ask the PyUnit developer. No time to review the test, sorry; if it works, I suggest to just check it in. ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 15:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 06:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-14 18:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 07:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 04:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 20:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 04:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 03:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 14:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 10:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 08:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 12:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 08:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-20 22:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 13:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 04:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 15:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 06:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 03:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 13:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 18:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Thu May 1 18:58:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 10:58:07 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 19:58 Message: Logged In: YES user_id=89016 OK, I've changed the new run_unittest() to call run_suite() with a second argument if exactly one testcase is passed. I hope that's OK. Checked in as: test_StringIO.py 1.16 test___all__.py 1.30 test_base64.py 1.6 test_bisect.py 1.9 test_bool.py 1.12 test_builtin.py 1.19 test_bz2.py 1.14 test_calendar.py 1.5 test_call.py 1.4 test_cfgparser.py 1.20 test_charmapcodec.py 1.7 test_codeccallbacks.py 1.12 test_codecs.py 1.9 test_copy.py 1.8 test_cpickle.py 1.15 test_csv.py 1.6 test_dummy_thread.py 1.4 test_enumerate.py 1.4 test_filecmp.py 1.2 test_getargs2.py 1.5 test_grp.py 1.16 test_hexoct.py 1.4 test_hmac.py 1.7 test_isinstance.py 1.7 test_itertools.py 1.6 test_optparse.py 1.2 test_os.py 1.18 test_parser.py 1.17 test_pep277.py 1.6 test_pickle.py 1.18 test_posix.py 1.6 test_pow.py 1.18 test_profilehooks.py 1.10 test_pwd.py 1.17 test_re.py 1.42 test_richcmp.py 1.9 test_sets.py 1.24 test_shelve.py 1.5 test_shutil.py 1.2 test_socket.py 1.64 test_str.py 1.3 test_string.py 1.25 test_strptime.py 1.13 test_support.py 1.52 test_sys.py 1.7 test_tarfile.py 1.8 test_tempfile.py 1.14 test_textwrap.py 1.19 test_timeout.py 1.14 test_trace.py 1.9 test_ucn.py 1.14 test_unicode.py 1.83 test_unicodedata.py 1.9 test_univnewlines.py 1.5 test_urllib.py 1.13 test_urllibnet.py 1.2 test_userdict.py 1.15 test_userlist.py 1.9 test_userstring.py 1.11 test_weakref.py 1.23 test_xpickle.py 1.4 test_zipimport.py 1.8 test_zlib.py 1.23 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 19:17 Message: Logged In: YES user_id=80475 My preference was to keep run_classtests() as a separate function. The run_unittest() function was unique in that it called run_suite() with two arguments instead of one. That accounts for the additional verbosity you are seeing. While I prefer the separate run_classtests(), it's up to you to do whichever seems best. Otherwise, all looks okay. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 18:54 Message: Logged In: YES user_id=89016 I've changed test_support.run_unittest() to work like your run_classtests() and changed all test scripts to use this. (see diff2.txt) I compared the output of ./python Lib/test/regrtest.py -v 2>&1 | grep -v "Ran.*test.*in" and apart from the fact that test_csv seems to be more verbose now, there seem to be no regression bugs. Raymond, can you check, if this is OK? BTW, there's another check for memory leaks in test_datetime.py. Perhaps it would make sense to combine both and use them globally in regrtest.py (or test_support.py)? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-29 23:39 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_richcmp.py 1.8 Lib/test/output/test_richcmp delete which a few additional tests and comments. I'll probably work on using run_classtests() tomorrow, but wouldn't it be simpler to add the multiple arguments to the already existing function run_unittest() instead of introducing the new run_classtests()? > BTW, why is the int to int comparison labeled as useless? Because it would check whether comparing two ints gives the same result as comparing the same two ints. ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 21:10 Message: Logged In: YES user_id=80475 Yes. test_support.run_classtests() ought to be used everywhere it is applicable. There are a couple of places like test_sets.py where the "suite" variable is used again for other purposed (testing for memory leaks). In those cases, it ought to be left alone until I can write a function that encapsulates the essense of the combined test. test_richcmp.py looks good. Please add comment lines describing the point of classes and tests whose names are not self explanatory (i.e. misbehavin, weird, etc). BTW, why is the int to int comparison labeled as useless? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-28 20:42 Message: Logged In: YES user_id=89016 Here's the next one: test_richcmp.py with a few additional tests to increase code coverage in object.c and listobject.c. BTW, should we change all tests to use the new test_support.run_classtests()? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-25 13:40 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_bool.py 1.9 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 23:00 Message: Logged In: YES user_id=6380 I suggest not to mess with unittest.py; it is still externally maintained as PyUnit. Maybe ask the PyUnit developer. No time to review the test, sorry; if it works, I suggest to just check it in. ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 22:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 13:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-15 01:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 14:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 11:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Thu May 1 23:44:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 15:44:33 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-26 03:09 Message generated for change (Comment added) made by jhylton 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: Open Resolution: None 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: Jeremy Hylton (jhylton) Date: 2003-05-01 22: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 17: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 16: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 16: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 09: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 19: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 17: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 16: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 15: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 08: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 08: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 21: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 17: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 15: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 09: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 15: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 11: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 21: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 21: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-26 04: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 Fri May 2 05:53:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 21:53:29 -0700 Subject: [Patches] [ python-Patches-731151 ] pimp.py has old URL for default database Message-ID: Patches item #731151, was opened at 2003-05-01 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=731151&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Nobody/Anonymous (nobody) Summary: pimp.py has old URL for default database Initial Comment: The default database in pimp.py points to an address on www.cwi.nl, which has been superceded by one on homepages.cwi.nl. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731151&group_id=5470 From noreply@sourceforge.net Fri May 2 05:58:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 21:58:05 -0700 Subject: [Patches] [ python-Patches-731153 ] redirect fails in urllib2 Message-ID: Patches item #731153, was opened at 2003-05-01 21:58 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=731153&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Nobody/Anonymous (nobody) Summary: redirect fails in urllib2 Initial Comment: There were two simple errors in urllib2's redirection code. In two cases, req.method was being invoked when the author meant req.get_method. The second error was the failure to make the redirected URL available to the redirect handler; I passed it as a parameter, but it could have been added as another instance variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731153&group_id=5470 From noreply@sourceforge.net Fri May 2 09:19:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 01:19:25 -0700 Subject: [Patches] [ python-Patches-731209 ] restore socketmodule's all-numeric address behaviour Message-ID: Patches item #731209, was opened at 2003-05-02 18:19 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=731209&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: restore socketmodule's all-numeric address behaviour Initial Comment: As requested by Guido on python-dev, the following restores the socketmodule's behaviour with all-numeric IP addresses to no longer do name resolution. It's not quite done, though - all-numeric addresses still go through the idna encoding module, which is a bit of unnecessary overhead it would be good to avoid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731209&group_id=5470 From noreply@sourceforge.net Fri May 2 11:27:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 03:27:52 -0700 Subject: [Patches] [ python-Patches-731209 ] restore socketmodule's all-numeric address behaviour Message-ID: Patches item #731209, was opened at 2003-05-02 18:19 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731209&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: restore socketmodule's all-numeric address behaviour Initial Comment: As requested by Guido on python-dev, the following restores the socketmodule's behaviour with all-numeric IP addresses to no longer do name resolution. It's not quite done, though - all-numeric addresses still go through the idna encoding module, which is a bit of unnecessary overhead it would be good to avoid. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-05-02 20:27 Message: Logged In: YES user_id=29957 MvL pointed out that this is not actually the case except where the IP address is given as a unicode string, so ignore the caveat -- this is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731209&group_id=5470 From noreply@sourceforge.net Fri May 2 13:53:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 05:53:20 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-26 00:16 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2003-05-02 14:53 Message: Logged In: YES user_id=34209 Well, I just re-used the call-profiling stuff that Jeremy (I think) already put in, but I don't see much use for getting people to run it. It shows the expected number of CALL_ATTR uses in e.g. pystone, no unexpected overheads inside modules or anything. The problem with the code isn't mispredicted branches, but general slowdown if *none* of the branches are taken. The only result I can think of of having people run with call-profiling on would be to find out we need to special-case other common tp_getattro functions -- which would result in more code and thus likely more general slowdown. However, patch with CALL_PROFILEing atatched. The call profile code changed somewhat, as this code returns a dict of counters, instead of a tuple. I found a 21-element tuple somewhat unwieldy :) I use a code snippet like: print "Call stats:" items = sys.callstats().items() items = [(value, key) for key, value in items] items.sort() items.reverse() for value,key in items: print "%30s: %30s"%(key, value) at the end of testing code (pystone, regrtest, etc.) Don't forget to #define CALL_PROFILE somewhere. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 20:11 Message: Logged In: YES user_id=6380 A suggestion: put some static global counters in the new code that count how many times each of the significant branches are taken, and a little routine that prints out the counts on exit. Then people can run various benchmarks and report the numbers, and that may help you decide which paths are worth more work... ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-23 13:43 Message: Logged In: YES user_id=34209 I'd not be proud in any case; neither the concept nor most of the implementation was my idea :-) But my questions still stand; the 3% slowdown in pystone is a lot if all you see is a 1.5% gain in Zope3 startup time, but I can't think of any ways to fix that before next friday, or before 2.3 is released. (The problem is either code size or switch length, which can be 'fixed' by culling code, re-ordering the switch again or changing the switch into a computed-goto.) And I'd need to find me a machine with less cache to actually notice the slowdown :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 14:38 Message: Logged In: YES user_id=6380 However, you should be proud of yourself nevertheless. On the same Zope3 startup "benchmark", Raymond Hettinger's bytecode optimizations scored 0% improvement. Python -O didn't make any difference either. So it's a touch benchmark! (And yes, I did remove the .pyc/.pyo files each time.) (And no, I can't test -OO because Zope uses the docstrings.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 14:20 Message: Logged In: YES user_id=6380 OK, I did a more realistic benchmark: startup time of Zope3. With more or less current CVS Python 2.3 (but not Raymond H's bytecode optimizations), it took 3.52 seconds. With your patch (and all .pyc files rebuilt) it took 3.47 seconds. That's about a percent and a half. (With Python 2.2 it took 4.08 seconds.) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-22 00:48 Message: Logged In: YES user_id=34209 Pystone is not likely to show much speedup, as it contains exactly 2 instances of CALL_ATTR, only barely in the main loop. However, it should not slow down because of CALL_ATTR either; the two CALL_ATTRs are of the most optimized sort, old-style instance methods, and none of the other code paths have changed *at all* (in the fast-and-ugly mode of the patch, which is the default.) There are only two reasons I can think of that explain a slower pystone: code cache and the switch statement layout. This apparently does not influence my (somewhat high-end-ish) test machines, but does yours (and others.) Both are more or less outside my control. They might be fixed by switch reordering or rearranging of the code so the compiler optimizes it better, but that's very platform specific and lacking a proper test-bed for that situation, I can't do it. Alternatively, there may be some funk with regards to bytecode version. If bytecode wasn't properly regenerated, I can imagine not seeing *any* speedup. Have you tried something as simple as ./python timeit.py -s 'class X:' -s ' def spam(self): pass' -s 'x = X()' 'x.spam()' ? This gives a good 30% speedup on my home PC. Bytecode problems wouldn't influence pystone though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 20:42 Message: Logged In: YES user_id=6380 Alas, like others, I see a tiny slowdown on pystone (maybe 3 percent). This is with the default version of patch version 4 (fixed). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:48 Message: Logged In: YES user_id=34209 Oops, that patch contained a C++-ism, ceval.c:3504 and 3505 needed to be swapped. Uploaded a new version. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all .() occurances. What and are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where resulted in an (old-style) instance, and one where resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 02:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 02:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 01:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-26 00:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Fri May 2 13:56:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 05:56:47 -0700 Subject: [Patches] [ python-Patches-731328 ] AssertionError when building rpm under RedHat 9.1 Message-ID: Patches item #731328, was opened at 2003-05-02 09: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=731328&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ricardo Niederberger Cabral (niederberger) Assigned to: Nobody/Anonymous (nobody) Summary: AssertionError when building rpm under RedHat 9.1 Initial Comment: When trying to build an rpm on RH 9: >From distutils __version__ = "1.0.3": File "distutils/command/bdist_rpm.py", line 316, in run assert len(rpms) == 1, \ AssertionError: unexpected number of RPM files found: ['build/bdist. linux-i686/rpm/RPMS/i386/imgSeek-0.7-1.i386.rpm', 'build/bdist. linux-i686/rpm/RPMS/i386/imgSeek-debuginfo-0.7-1.i386.rpm'] I had to remove the assert statement on bdist_rpm.py:316 in order to build my rpm since rpmbuild from RH always seems to generate this extra -debuginfo rpm. So attached is a patch (cvs rev 1.37) to simply copy all generated RPM's to the dist/ directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731328&group_id=5470 From noreply@sourceforge.net Fri May 2 16:20:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 08:20:16 -0700 Subject: [Patches] [ python-Patches-731209 ] restore socketmodule's all-numeric address behaviour Message-ID: Patches item #731209, was opened at 2003-05-02 04:19 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731209&group_id=5470 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: restore socketmodule's all-numeric address behaviour Initial Comment: As requested by Guido on python-dev, the following restores the socketmodule's behaviour with all-numeric IP addresses to no longer do name resolution. It's not quite done, though - all-numeric addresses still go through the idna encoding module, which is a bit of unnecessary overhead it would be good to avoid. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-02 11:20 Message: Logged In: YES user_id=6380 Looks good. Please apply! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-05-02 06:27 Message: Logged In: YES user_id=29957 MvL pointed out that this is not actually the case except where the IP address is given as a unicode string, so ignore the caveat -- this is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731209&group_id=5470 From noreply@sourceforge.net Fri May 2 16:44:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 08:44:10 -0700 Subject: [Patches] [ python-Patches-731209 ] restore socketmodule's all-numeric address behaviour Message-ID: Patches item #731209, was opened at 2003-05-02 18:19 Message generated for change (Settings changed) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731209&group_id=5470 >Category: Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: restore socketmodule's all-numeric address behaviour Initial Comment: As requested by Guido on python-dev, the following restores the socketmodule's behaviour with all-numeric IP addresses to no longer do name resolution. It's not quite done, though - all-numeric addresses still go through the idna encoding module, which is a bit of unnecessary overhead it would be good to avoid. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-05-03 01:43 Message: Logged In: YES user_id=29957 Applied as socketmodule.c 1.262 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-03 01:20 Message: Logged In: YES user_id=6380 Looks good. Please apply! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-05-02 20:27 Message: Logged In: YES user_id=29957 MvL pointed out that this is not actually the case except where the IP address is given as a unicode string, so ignore the caveat -- this is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731209&group_id=5470 From noreply@sourceforge.net Fri May 2 18:59:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 10:59:36 -0700 Subject: [Patches] [ python-Patches-731504 ] Typo in datetimemodule.c comment Message-ID: Patches item #731504, was opened at 2003-05-02 11:59 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=731504&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in datetimemodule.c comment Initial Comment: It's not spelled "isofomat". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731504&group_id=5470 From noreply@sourceforge.net Fri May 2 19:00:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 11:00:53 -0700 Subject: [Patches] [ python-Patches-731504 ] Typo in datetimemodule.c comment Message-ID: Patches item #731504, was opened at 2003-05-02 11:59 Message generated for change (Settings changed) made by staschuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731504&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None >Priority: 1 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in datetimemodule.c comment Initial Comment: It's not spelled "isofomat". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731504&group_id=5470 From noreply@sourceforge.net Fri May 2 19:12:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 11:12:57 -0700 Subject: [Patches] [ python-Patches-731514 ] Fix for outdated paragraph in re documentation. Message-ID: Patches item #731514, was opened at 2003-05-02 18: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=731514&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for outdated paragraph in re documentation. Initial Comment: With recent changes to the re module, a section of the manual has become out-of-date. The end of the Example section has a warning about exceeding the recursion limit, but the given example no longer does so. This patch provides a new, not *too* contrived, example which does hit the recursion limit, and like the original doc, proposes a restructuring of it which avoids the recursion limit. It provides a "New in 2.3" sentence to show what's new. It also renames the section from "Avoiding backtracking" to "Avoiding recursion" since it has nothing to do with backtracking (and never did). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731514&group_id=5470 From noreply@sourceforge.net Fri May 2 19:40:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 11:40:40 -0700 Subject: [Patches] [ python-Patches-731504 ] Typo in datetimemodule.c comment Message-ID: Patches item #731504, was opened at 2003-05-02 13:59 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731504&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 1 Submitted By: Steven Taschuk (staschuk) >Assigned to: Tim Peters (tim_one) Summary: Typo in datetimemodule.c comment Initial Comment: It's not spelled "isofomat". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-02 14:40 Message: Logged In: YES user_id=31435 Thanks! Patch applied, in Modules/datetimemodule.c new revision: 1.61 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731504&group_id=5470 From noreply@sourceforge.net Fri May 2 22:19:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 14:19:24 -0700 Subject: [Patches] [ python-Patches-731607 ] make threading join() method return a value Message-ID: Patches item #731607, was opened at 2003-05-02 17:19 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=731607&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: make threading join() method return a value Initial Comment: This patch makes the join() method of a threading module Thread return the value that was returned by the callable that is running in the thread. It came about because I needed to split a process into a number of threads, join them all, and then check what each of them returned before proceeding. It against the current CVS tree, tested on Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 From noreply@sourceforge.net Fri May 2 22:35:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 14:35:30 -0700 Subject: [Patches] [ python-Patches-731607 ] make threading join() method return a value Message-ID: Patches item #731607, was opened at 2003-05-02 14:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: make threading join() method return a value Initial Comment: This patch makes the join() method of a threading module Thread return the value that was returned by the callable that is running in the thread. It came about because I needed to split a process into a number of threads, join them all, and then check what each of them returned before proceeding. It against the current CVS tree, tested on Linux. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-02 14:35 Message: Logged In: YES user_id=357491 I don't think this is truly necessary. If you needed to know what they would return just insert it into a Queue and when the 'join' calls finish check the Queue to see what was added. It also deviates from Java's threading setup which 'threading' is based on. I'm -1 on this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 From noreply@sourceforge.net Fri May 2 23:01:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 15:01:53 -0700 Subject: [Patches] [ python-Patches-731621 ] Fix for outdated paragraph in re documentation. Message-ID: Patches item #731621, was opened at 2003-05-02 22:01 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=731621&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for outdated paragraph in re documentation. Initial Comment: With recent changes to the re module, a section of the manual has become out-of-date. The end of the Example section has a warning about exceeding the recursion limit, but the given example no longer does so. This patch provides a new, not *too* contrived, example which does hit the recursion limit, and like the original doc, proposes a restructuring of it which avoids the recursion limit. It provides a "New in 2.3" sentence to show what's new. It also renames the section from "Avoiding backtracking" to "Avoiding recursion" since it has nothing to do with backtracking (and never did). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731621&group_id=5470 From noreply@sourceforge.net Fri May 2 23:13:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 15:13:55 -0700 Subject: [Patches] [ python-Patches-731621 ] Fix for outdated paragraph in re documentation. Message-ID: Patches item #731621, was opened at 2003-05-02 22:01 Message generated for change (Comment added) made by herron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731621&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for outdated paragraph in re documentation. Initial Comment: With recent changes to the re module, a section of the manual has become out-of-date. The end of the Example section has a warning about exceeding the recursion limit, but the given example no longer does so. This patch provides a new, not *too* contrived, example which does hit the recursion limit, and like the original doc, proposes a restructuring of it which avoids the recursion limit. It provides a "New in 2.3" sentence to show what's new. It also renames the section from "Avoiding backtracking" to "Avoiding recursion" since it has nothing to do with backtracking (and never did). ---------------------------------------------------------------------- >Comment By: Gary Herron (herron) Date: 2003-05-02 22:13 Message: Logged In: YES user_id=395736 Somehow this patch got submitted twice, once as #731514 and again as this one #731621. So I have marked this as duplicate. Please see #731514 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731621&group_id=5470 From noreply@sourceforge.net Sat May 3 00:12:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 16:12:38 -0700 Subject: [Patches] [ python-Patches-729305 ] Compiler warning on Solaris 8 Message-ID: Patches item #729305, was opened at 2003-04-28 19:42 Message generated for change (Comment added) made by gnn 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: Open Resolution: None 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: George Neville-Neil (gnn) Date: 2003-05-02 16: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 04: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-28 21: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 May 3 00:57:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 16:57:30 -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: Open Resolution: None 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-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 May 3 03:38:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 19:38:03 -0700 Subject: [Patches] [ python-Patches-731701 ] SpawnedGenerator class for threading module Message-ID: Patches item #731701, was opened at 2003-05-02 20:38 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=731701&group_id=5470 Category: Modules Group: None Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731701&group_id=5470 From noreply@sourceforge.net Sat May 3 10:09:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 02:09:29 -0700 Subject: [Patches] [ python-Patches-711902 ] Cause pydoc to show data descriptor __doc__ strings Message-ID: Patches item #711902, was opened at 2003-03-29 20:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711902&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Martin v. Löwis (loewis) Summary: Cause pydoc to show data descriptor __doc__ strings Initial Comment: Data descriptors (descriptors having both a __get__ and a __set__ method) often have __doc__ strings. Pydoc displays these for descriptors of type property, but not for other types (e.g., getsets). The attached patch will display __doc__ strings for data descriptors (if available) in the "Data and non-method functions" section of the type description. This patch is intended to be a minimal change. It's possible that inspect.classify_class_attrs should return a new kind for data descriptors (or possibly the "property" kind should include all data descriptors (not just properties)), which could then be handled differently from other non-classified data. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:09 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libinspect.tex 1.12 inspect.py 1.43 pydoc.py 1.82 test_inspect.py 1.10 NEWS 1.755 ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-04-21 18:34 Message: Logged In: YES user_id=86307 Apparently, Sourceforge won't let me delete the old patch file (I get a permission denied error), so, to avoid confusion, here is the new patch in a file named pydoc_patch2.txt. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-04-21 18:31 Message: Logged In: YES user_id=86307 Attaching new patch with docs and a couple of tests. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 22:32 Message: Logged In: YES user_id=21627 The patch looks fine. Can you please also provide a patch for the documentation (libinspect.tex), and the test suite (test_inspect.py)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711902&group_id=5470 From noreply@sourceforge.net Sat May 3 10:15:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 02:15:28 -0700 Subject: [Patches] [ python-Patches-708495 ] OpenVMS complementary patches Message-ID: Patches item #708495, was opened at 2003-03-23 21:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708495&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Piéronne Jean-François (pieronne) Assigned to: Martin v. Löwis (loewis) Summary: OpenVMS complementary patches Initial Comment: Explanations of the various patches: fcntlmodule.c Under VMS the third argument is declared as void * expat.h VMS C compiler can optionally mangle name longer than 31 characters, so it not necessary to change long name fileobject.c As the comment indicate this solve a problem into test_fileinput, but I don't understand why... fpectlmodule.c Enable SIGFPE handler import.c Support of VMS filesystem ODS-5 mmapmodule.c VMS need a fsync before a call to fstat to return accurate information myreadline.c Use of vms__StdioReadline posixmodule.c I have move some initialisation part to a specific VMS file, so I have remove it form posixmodule.c pyexpat.c Convert VMS filename to a UNIX style filename. socketmodule.c This patch is the only one which is not delimited by #ifdef __VMS #endif because IMHO it fix a bug into the original code socketmodule.h need to include socket.h and not sys/socket.h sysmodule.c Convert VMS filename to a UNIX style filename. Regards, Jean-François ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:15 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as bz2module.c 1.19 fcntlmodule.c 2.39 fpectlmodule.c 2.19 grpmodule.c 2.21 mmapmodule.c 2.45 posixmodule.c 2.299 socketmodule.c 1.263 socketmodule.h 1.9 myreadline.c 2.29 dynload_shlib.c 2.15 sysmodule.c 2.118 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-24 00:11 Message: Logged In: YES user_id=21627 Can you please explain the expat.h change? This is an imported source, so I don't want to modify it unless there is a really good reason. The fileobject.c modification needs better analysis. "corrects a test case problem" is not enough reason to make such a change. Does the test case make assumptions that are not supported by the relevant standards? Is there a bug in VMS? etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-23 21:28 Message: Logged In: YES user_id=21627 Can you please combine the patches into a single patch, which can be applied using patch -p0 ??? You can use "diff -ur" or "cvs diff" to create a recursive patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708495&group_id=5470 From noreply@sourceforge.net Sat May 3 11:00:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:00:48 -0700 Subject: [Patches] [ python-Patches-684981 ] fix for bug 501716 Message-ID: Patches item #684981, was opened at 2003-02-12 00:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684981&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Martin v. Löwis (loewis) Summary: fix for bug 501716 Initial Comment: Fixes bug described there: "es#" parser marker leaks memory Also fixes two other minor leaks involving strings with encoded NULL's and when a bad buffer_len pointer is passed to PyArg_Parse... Is a nicer version of the patch I pasted in to the comments on the 501716 bug report. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 12:00 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as getargs.c 2.100. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684981&group_id=5470 From noreply@sourceforge.net Sat May 3 11:15:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:15:38 -0700 Subject: [Patches] [ python-Patches-730826 ] Patch for NetBSD to activate all library features Message-ID: Patches item #730826, was opened at 2003-05-01 17:48 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730826&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: Patch for NetBSD to activate all library features Initial Comment: NetBSD-current (as of last week), the upcoming 2.0, supports a define _NETBSD_SOURCE to activate all library features. It works similar to the _GNU_SOURCE define on Linux/glibc and the __EXTENSIONS__ define on Solaris. It is needed to compile the modules(/functions) that need functionaly that isn't available in a strict POSIX environment, eg. RPC, some socket related stuff (inet_[a|p]ton) and maybe more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730826&group_id=5470 From noreply@sourceforge.net Sat May 3 11:32:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:32:50 -0700 Subject: [Patches] [ python-Patches-730826 ] Patch for NetBSD to activate all library features Message-ID: Patches item #730826, was opened at 2003-05-01 17:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730826&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: Patch for NetBSD to activate all library features Initial Comment: NetBSD-current (as of last week), the upcoming 2.0, supports a define _NETBSD_SOURCE to activate all library features. It works similar to the _GNU_SOURCE define on Linux/glibc and the __EXTENSIONS__ define on Solaris. It is needed to compile the modules(/functions) that need functionaly that isn't available in a strict POSIX environment, eg. RPC, some socket related stuff (inet_[a|p]ton) and maybe more. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 12:32 Message: Logged In: YES user_id=21627 Very cool! Committed as configure 1.392 configure.in 1.403 pyconfig.h.in 1.78 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730826&group_id=5470 From noreply@sourceforge.net Sat May 3 11:54:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:54:23 -0700 Subject: [Patches] [ python-Patches-708604 ] unchecked return values - compile.c Message-ID: Patches item #708604, was opened at 2003-03-24 04:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708604&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Harper (jasonharper) Assigned to: Martin v. Löwis (loewis) Summary: unchecked return values - compile.c Initial Comment: Various cleanups in Python/compile.c - mainly unchecked return values. Also an unchecked memory allocation in PyList_SetSlice that's called by compile.c. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 12:54 Message: Logged In: YES user_id=21627 Thanks for the patches. Committed as listobject.c 2.151 compile.c 2.283 listobject.c 2.103.6.6 compile.c 2.234.4.7 ---------------------------------------------------------------------- Comment By: Jason Harper (jasonharper) Date: 2003-03-24 04:19 Message: Logged In: YES user_id=392021 aaarrrrggghhh.... SF isn't letting me attach the files, clicking Submit simply clears the entered filename??? Will try later from another system. ---------------------------------------------------------------------- Comment By: Jason Harper (jasonharper) Date: 2003-03-24 04:18 Message: Logged In: YES user_id=392021 aaarrrrggghhh.... SF isn't letting me attach the files, clicking Submit simply clears the entered filename??? Will try later from another system. ---------------------------------------------------------------------- Comment By: Jason Harper (jasonharper) Date: 2003-03-24 04:05 Message: Logged In: YES user_id=392021 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708604&group_id=5470 From noreply@sourceforge.net Sat May 3 11:55:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:55:17 -0700 Subject: [Patches] [ python-Patches-731621 ] Fix for outdated paragraph in re documentation. Message-ID: Patches item #731621, was opened at 2003-05-03 00:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731621&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for outdated paragraph in re documentation. Initial Comment: With recent changes to the re module, a section of the manual has become out-of-date. The end of the Example section has a warning about exceeding the recursion limit, but the given example no longer does so. This patch provides a new, not *too* contrived, example which does hit the recursion limit, and like the original doc, proposes a restructuring of it which avoids the recursion limit. It provides a "New in 2.3" sentence to show what's new. It also renames the section from "Avoiding backtracking" to "Avoiding recursion" since it has nothing to do with backtracking (and never did). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 12:55 Message: Logged In: YES user_id=21627 Closing the duplicate. ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-05-03 00:13 Message: Logged In: YES user_id=395736 Somehow this patch got submitted twice, once as #731514 and again as this one #731621. So I have marked this as duplicate. Please see #731514 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731621&group_id=5470 From noreply@sourceforge.net Sat May 3 11:59:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:59:46 -0700 Subject: [Patches] [ python-Patches-731514 ] Fix for outdated paragraph in re documentation. Message-ID: Patches item #731514, was opened at 2003-05-02 20:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731514&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for outdated paragraph in re documentation. Initial Comment: With recent changes to the re module, a section of the manual has become out-of-date. The end of the Example section has a warning about exceeding the recursion limit, but the given example no longer does so. This patch provides a new, not *too* contrived, example which does hit the recursion limit, and like the original doc, proposes a restructuring of it which avoids the recursion limit. It provides a "New in 2.3" sentence to show what's new. It also renames the section from "Avoiding backtracking" to "Avoiding recursion" since it has nothing to do with backtracking (and never did). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 12:59 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libre.tex 1.98. Notice that there are special \versionadded,\versionchanged commands in Python-Tex to generate these "New/Changed in x.y" sections. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731514&group_id=5470 From noreply@sourceforge.net Sat May 3 12:01:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 04:01:36 -0700 Subject: [Patches] [ python-Patches-731328 ] AssertionError when building rpm under RedHat 9.1 Message-ID: Patches item #731328, was opened at 2003-05-02 14:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731328&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ricardo Niederberger Cabral (niederberger) Assigned to: Nobody/Anonymous (nobody) Summary: AssertionError when building rpm under RedHat 9.1 Initial Comment: When trying to build an rpm on RH 9: >From distutils __version__ = "1.0.3": File "distutils/command/bdist_rpm.py", line 316, in run assert len(rpms) == 1, \ AssertionError: unexpected number of RPM files found: ['build/bdist. linux-i686/rpm/RPMS/i386/imgSeek-0.7-1.i386.rpm', 'build/bdist. linux-i686/rpm/RPMS/i386/imgSeek-debuginfo-0.7-1.i386.rpm'] I had to remove the assert statement on bdist_rpm.py:316 in order to build my rpm since rpmbuild from RH always seems to generate this extra -debuginfo rpm. So attached is a patch (cvs rev 1.37) to simply copy all generated RPM's to the dist/ directory. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 13:01 Message: Logged In: YES user_id=21627 Can you provide more information? What rpm gets generated, and what files does it contain? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731328&group_id=5470 From noreply@sourceforge.net Sat May 3 12:28:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 04:28:04 -0700 Subject: [Patches] [ python-Patches-730170 ] fix for bug #727051 Message-ID: Patches item #730170, was opened at 2003-04-30 15:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730170&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug #727051 Initial Comment: The fix for configure.in makes it look for sem_init() first in the library pthread, before it tries the Solaris rt and posix4. The trouble is that on Linux sem_init() seems to be defined both in libpthread and in librt, making linking with librt unnecessary on Linux where we generally link with libpthread anyway. Linking with librt has the additional burden of making Python no longer valgrind-friendly, which is the cause for the reported bug http://www.python.org/sf/727501 Let me know if there is any difference I am not aware of between the rt and the pthread versions of sem_init(). A full recompile and 'make test' worked fine on my Linux machine. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 13:28 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure 1.393 configure.in 1.404 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730170&group_id=5470 From noreply@sourceforge.net Sat May 3 19:07:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 11:07:27 -0700 Subject: [Patches] [ python-Patches-604210 ] release GIL around getaddrinfo() Message-ID: Patches item #604210, was opened at 2002-09-03 23:48 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: release GIL around getaddrinfo() Initial Comment: If getaddrinfo() is thread-safe, then we should release the interpreter lock before calling it. There is every reason to believe that this operation will be slow. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-03 20:07 Message: Logged In: YES user_id=92689 FWIW, I opened a bug regarding this very same issue (I didn't know if this item): python.org/sf/731644. That item now also contains a new patch that takes care of locking. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-05 10:38 Message: Logged In: YES user_id=21627 RFC 2553 specifies that getaddrinfo, getipnodebyname, and all the other new netdb functions must be thread-safe - hence the BSD man pages document it as a bug that they are not. So adding an additional lock, in general, might be overkill. I'd suggest a strategy that assumes, in general, that getaddrinfo is thread-safe. If it isn't (by hard-coded knowledge), I'd propose just to continue using the interpreter lock - those systems deserve to lose. As for the fallback implementation - feel free to do anything about it that you can find the time for. Recording it as thread-unsafe might be fine, adding a lock is another option, using the thread-safe API inside the fallback (where available) is a third option. I would not care too much, except that this is used on Windows. Notice that it won't be used on Windows if Python is compiled with VC.NET, since that provides a "native" getaddrinfo (and Python knows that it does). So if Python 2.3 is going to be compiled with VC.NET, I would not worry about the fallback implementation at all. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-04 22:18 Message: Logged In: YES user_id=33168 I looked on OpenBSD (I think, may have been NetBSD) and FreeBSD. The man pages were the same, both old (circa 1995), but they said their implementation was not thread-safe. I did a man on Dec UNIX and it said it conformed to POSIX.1g Draft 6.6, but didn't indicate if it was thread safe. Solaris 8 doesn't say anything in the man page. Here's a NetBSD 1.6 man page dated 2002/05/14 and it's still not thread-safe: http://216.239.37.100/search?q=cache:4bTvQQqcwq4C:www.tac.eu.org/cgi-bin/man-cgi%3Fgetaddrinfo%2B3+getaddrinfo+thread+safe&hl=en&ie=UTF-8 This: http://216.239.33.100/search?q=cache:q5egqJ5_mv4C:mail.gnu.org/pipermail/guile-devel/2001-October/004039.html+getaddrinfo+thread+safe&hl=en&ie=UTF-8 says "getaddrinfo and getnameinfo are the recommended APIs. They avoid hidden static data; they're supposed to be thread-safe; they handle multiple address families." It seems safest to do what Jeremy proposes and add a lock. There can always be a define if getaddrinfo is thread safe or not. Maybe we can even determine with autoconf. Note: I get much better performance with this patch under linux. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-04 21:20 Message: Logged In: YES user_id=31392 The getaddrinfo() on Linux says it thread-safe. It's a name-fangled call. Is it part of some standard? It would certainly be possible to make the fallback implementation thread-safe. Or, if we don't believe it is thread-safe, we could add a separate lock to protect it. The socket module of 2.1 vintage had a separate lock for this purpose. And the 2.1 vintage Python performs much better when a multi-threaded app does DNS lookups. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 08:25 Message: Logged In: YES user_id=21627 How do you know getaddrinfo is thread-safe? In particular, when using the getaddrinfo emulation, it is not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 From noreply@sourceforge.net Sun May 4 00:04:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 16:04:43 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-03 16:04 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=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 4 12:29:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 04:29:53 -0700 Subject: [Patches] [ python-Patches-732143 ] exit status of latex2html "ignored" Message-ID: Patches item #732143, was opened at 2003-05-04 11:29 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=732143&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: exit status of latex2html "ignored" Initial Comment: latex2html discovered an error building the lib html docs. It correctly prints: *** Session transcript and error messages are in /build/packages/python2.3/python2.3-2.2.102/Doc/html/lib/lib.how. *** Exited with status 25. The relevant lines from the transcript are: [...] but then exits with an exit status of 1, which lets make continue and makes it harder to find the actual error. Not sure, if this is the correct fix, but why not exit with the error you show the user? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732143&group_id=5470 From noreply@sourceforge.net Sun May 4 13:29:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:29:09 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-04 01:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 4 14:47:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 06:47:51 -0700 Subject: [Patches] [ python-Patches-732174 ] build of html docs broken (liboptparse.tex) Message-ID: Patches item #732174, was opened at 2003-05-04 13: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=732174&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: build of html docs broken (liboptparse.tex) Initial Comment: The last known working versions is 1.6. 1.7 doesn't build anymore. latex2html returns [...] Reading aux file: /build/packages/python2.3/python2.3-2.2.102/Doc/lib.aux ... Processing macros ...,,,,++................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Subroutine do_cmd_leftmargin redefined at (eval 732) line 1. defining handler for \leftmargin using \leftmargini .............Undefined subroutine &main::do_cmd_leftmargini called at (eval 732) line 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 From noreply@sourceforge.net Sun May 4 18:16:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 10:16:21 -0700 Subject: [Patches] [ python-Patches-732234 ] configure gets threads wrong sometimes Message-ID: Patches item #732234, was opened at 2003-05-04 10: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=732234&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: configure gets threads wrong sometimes Initial Comment: This patch fixes the compiler options for threads on UnixWare 7 Without it you get this warning. UX:cc: WARNING: Use -Kthread instead of -lthread when linking with threads library; using -lthread directly may cause incorrect execution behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732234&group_id=5470 From noreply@sourceforge.net Sun May 4 18:50:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 10:50:44 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-03 16:04 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-04 10:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 4 19:56:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 11:56:02 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-04 01:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 20:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 19:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 4 19:58:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 11:58:54 -0700 Subject: [Patches] [ python-Patches-732284 ] UnixWare 7 build patch Message-ID: Patches item #732284, was opened at 2003-05-04 11:58 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=732284&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7 build patch Initial Comment: Here is a patch to fix the build on UnixWare 7 & OpenUNIX 8 without taking the simple route of define_xopen_source=no. This patch depends on patches 731191 and 732234 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 From noreply@sourceforge.net Sun May 4 20:05:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 12:05:25 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-03 16:04 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 11:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 10:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 4 20:11:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 12:11:08 -0700 Subject: [Patches] [ python-Patches-732234 ] configure gets threads wrong sometimes Message-ID: Patches item #732234, was opened at 2003-05-04 19:16 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732234&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) >Assigned to: Martin v. Löwis (loewis) Summary: configure gets threads wrong sometimes Initial Comment: This patch fixes the compiler options for threads on UnixWare 7 Without it you get this warning. UX:cc: WARNING: Use -Kthread instead of -lthread when linking with threads library; using -lthread directly may cause incorrect execution behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732234&group_id=5470 From noreply@sourceforge.net Sun May 4 20:15:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 12:15:39 -0700 Subject: [Patches] [ python-Patches-732284 ] UnixWare 7 build patch Message-ID: Patches item #732284, was opened at 2003-05-04 20:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7 build patch Initial Comment: Here is a patch to fix the build on UnixWare 7 & OpenUNIX 8 without taking the simple route of define_xopen_source=no. This patch depends on patches 731191 and 732234 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:15 Message: Logged In: YES user_id=21627 Is there absolutely no way to get to these types when _XOPEN_SOURCE is defined? Not by including some obscure header file? Not by defining some obscure macro? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 From noreply@sourceforge.net Sun May 4 20:18:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 12:18:35 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-04 01:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:18 Message: Logged In: YES user_id=21627 Why do you say "is needed for the socklen_t test"? Are you referring to the test in your patch? In this test, u_int is not *used* at all, it is only defined. So not defining it should not cause problems. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 21:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 20:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 19:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 4 20:29:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 12:29:45 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-03 16:04 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:29 Message: Logged In: YES user_id=618097 Without u_short and u_int the soclklen_t test can NEVER suceed on OpenServer because of a syntax error in sys/socket.h whthout them. Ugly, but you don't seem to like the option of seting define_xopen_source=no on platforms that puilt fine prior to 2.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:18 Message: Logged In: YES user_id=21627 Why do you say "is needed for the socklen_t test"? Are you referring to the test in your patch? In this test, u_int is not *used* at all, it is only defined. So not defining it should not cause problems. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 11:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 10:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 4 20:51:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 12:51:25 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-04 01:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:51 Message: Logged In: YES user_id=21627 Now we are getting closer. What is the specific line in sys/socket.h that gives the syntax error? Are there alternative definitions of the (function, I suppose), either in socket.h or in another file? Why is u_int not defined when _XOPEN_SOURCE is? IOW: Are you absolutely, definitely, 100% certain that there is no way to compile sys/socket.h when _XOPEN_SOURCE is defined? That would be a serious bug in the system. Now, if we can establish with certainty that the system is broken beyond repair, it is acceptable to work around the bugs, by not defining _XOPEN_SOURCE. We then need to record the specific release of the system that we found is broken, and we need to document what specifically we found broken about it. For better reproducability, we also want to record the name of the person who determined the system being broken. We do all this in the hope that future system releases will be fixed by the system vendors, and that our work-arounds won't be needed anymore when we stop supporting old releases of the system (at a time when nobody uses those old releases anymore). I am not opposed to setting _define_xopen_source=no in principle (I once was, but am not any longer). I only want a convincing analysis that this is necessary to get essential parts of Python (such as sockets) to work. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 21:29 Message: Logged In: YES user_id=618097 Without u_short and u_int the soclklen_t test can NEVER suceed on OpenServer because of a syntax error in sys/socket.h whthout them. Ugly, but you don't seem to like the option of seting define_xopen_source=no on platforms that puilt fine prior to 2.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:18 Message: Logged In: YES user_id=21627 Why do you say "is needed for the socklen_t test"? Are you referring to the test in your patch? In this test, u_int is not *used* at all, it is only defined. So not defining it should not cause problems. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 21:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 20:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 19:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 4 21:08:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 13:08:46 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-03 16:04 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-04 13:08 Message: Logged In: YES user_id=618097 There may be a way. Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:51 Message: Logged In: YES user_id=21627 Now we are getting closer. What is the specific line in sys/socket.h that gives the syntax error? Are there alternative definitions of the (function, I suppose), either in socket.h or in another file? Why is u_int not defined when _XOPEN_SOURCE is? IOW: Are you absolutely, definitely, 100% certain that there is no way to compile sys/socket.h when _XOPEN_SOURCE is defined? That would be a serious bug in the system. Now, if we can establish with certainty that the system is broken beyond repair, it is acceptable to work around the bugs, by not defining _XOPEN_SOURCE. We then need to record the specific release of the system that we found is broken, and we need to document what specifically we found broken about it. For better reproducability, we also want to record the name of the person who determined the system being broken. We do all this in the hope that future system releases will be fixed by the system vendors, and that our work-arounds won't be needed anymore when we stop supporting old releases of the system (at a time when nobody uses those old releases anymore). I am not opposed to setting _define_xopen_source=no in principle (I once was, but am not any longer). I only want a convincing analysis that this is necessary to get essential parts of Python (such as sockets) to work. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:29 Message: Logged In: YES user_id=618097 Without u_short and u_int the soclklen_t test can NEVER suceed on OpenServer because of a syntax error in sys/socket.h whthout them. Ugly, but you don't seem to like the option of seting define_xopen_source=no on platforms that puilt fine prior to 2.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:18 Message: Logged In: YES user_id=21627 Why do you say "is needed for the socklen_t test"? Are you referring to the test in your patch? In this test, u_int is not *used* at all, it is only defined. So not defining it should not cause problems. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 11:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 10:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 4 21:09:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 13:09:32 -0700 Subject: [Patches] [ python-Patches-732284 ] UnixWare 7 build patch Message-ID: Patches item #732284, was opened at 2003-05-04 11:58 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7 build patch Initial Comment: Here is a patch to fix the build on UnixWare 7 & OpenUNIX 8 without taking the simple route of define_xopen_source=no. This patch depends on patches 731191 and 732234 ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-04 13:09 Message: Logged In: YES user_id=618097 There may be a way Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:15 Message: Logged In: YES user_id=21627 Is there absolutely no way to get to these types when _XOPEN_SOURCE is defined? Not by including some obscure header file? Not by defining some obscure macro? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 From noreply@sourceforge.net Sun May 4 22:39:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 14:39:40 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-03 16:04 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=618097 That was a waste of time. I mis read sys/types.h on OpenServer u_int and u_short are not defined because they are warped inside #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) #endif /* !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) */ The error is "/usr/include/sys/socket.h", line 171: error: Syntax error before or at: u_short "/usr/include/sys/socket.h", line 171: error: cannot recover from previous errors .... 167:/* 168: * Structure used by kernel to store most addresses. 169: */ 170:struct sockaddr { 171: u_short sa_family; /* address family */ 172: char sa_data[14]; /* up to 14 bytes of direct address */ 173:}; 174: .... I've modified the patch to be less obtrusive my undefing _XOPEN_SOURCE on OpenServer only. We may end up removing the confdefs2.h parts later if we end up using define_xopen_source=no for OpenServer. As it stands now, with or without this patch, OpenServer doesn't build. This patch is really for SVR4.2 and SVR5 systems. (Ie. UnixWare) ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 13:08 Message: Logged In: YES user_id=618097 There may be a way. Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:51 Message: Logged In: YES user_id=21627 Now we are getting closer. What is the specific line in sys/socket.h that gives the syntax error? Are there alternative definitions of the (function, I suppose), either in socket.h or in another file? Why is u_int not defined when _XOPEN_SOURCE is? IOW: Are you absolutely, definitely, 100% certain that there is no way to compile sys/socket.h when _XOPEN_SOURCE is defined? That would be a serious bug in the system. Now, if we can establish with certainty that the system is broken beyond repair, it is acceptable to work around the bugs, by not defining _XOPEN_SOURCE. We then need to record the specific release of the system that we found is broken, and we need to document what specifically we found broken about it. For better reproducability, we also want to record the name of the person who determined the system being broken. We do all this in the hope that future system releases will be fixed by the system vendors, and that our work-arounds won't be needed anymore when we stop supporting old releases of the system (at a time when nobody uses those old releases anymore). I am not opposed to setting _define_xopen_source=no in principle (I once was, but am not any longer). I only want a convincing analysis that this is necessary to get essential parts of Python (such as sockets) to work. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:29 Message: Logged In: YES user_id=618097 Without u_short and u_int the soclklen_t test can NEVER suceed on OpenServer because of a syntax error in sys/socket.h whthout them. Ugly, but you don't seem to like the option of seting define_xopen_source=no on platforms that puilt fine prior to 2.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:18 Message: Logged In: YES user_id=21627 Why do you say "is needed for the socklen_t test"? Are you referring to the test in your patch? In this test, u_int is not *used* at all, it is only defined. So not defining it should not cause problems. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 11:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 10:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 4 22:59:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 14:59:11 -0700 Subject: [Patches] [ python-Patches-732284 ] UnixWare 7 build patch Message-ID: Patches item #732284, was opened at 2003-05-04 11:58 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7 build patch Initial Comment: Here is a patch to fix the build on UnixWare 7 & OpenUNIX 8 without taking the simple route of define_xopen_source=no. This patch depends on patches 731191 and 732234 ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-04 14:59 Message: Logged In: YES user_id=618097 If I define _POSIX_SOURCE the data types are available but I get a whole new set of errors in posixmodule.c .... cc -Kthread -K pentium,host,inline,loop_unroll,alloca -DNDEBUG -O -I. -I/opt/src/utils/python/python/dist/src/Include -DPy_BUILD_CORE -c /opt/src/utils/python/python/dist/src/Modules/posixmodule.c -o Modules/posixmodule.o UX:acomp: ERROR: "/usr/include/sys/wait.h", line 141: Syntax error before or at: siginfo_t UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 874: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 875: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 876: improper member use: tv_nsec gmake: *** [Modules/posixmodule.o] Error 1 .... I'm attaching a new patch that has the data type checks from patch 731991. With this patch (which still depends on patches 731991 & 732234) UnixWare 7 builds. It's kind of ugly and I don't like it much. The simple alternative is to use this patch -------------------------- --- configure.in.old 2003-04-17 13:16:42.000000000 -0700 +++ configure.in 2003-04-22 15:26:13.450080095 -0700 @@ -124,6 +124,8 @@ # of union __?sigval. Reported by Stuart Bishop. SunOS/5.6) define_xopen_source=no;; + OpenUNIX/8.* | UnixWare/7.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes -------------------------- ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 13:09 Message: Logged In: YES user_id=618097 There may be a way Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:15 Message: Logged In: YES user_id=21627 Is there absolutely no way to get to these types when _XOPEN_SOURCE is defined? Not by including some obscure header file? Not by defining some obscure macro? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 From noreply@sourceforge.net Mon May 5 00:09:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 16:09:52 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 16: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=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Mon May 5 00:20:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 16:20:45 -0700 Subject: [Patches] [ python-Patches-732401 ] Allows os.forkpty to work on more platforms (Solaris!) Message-ID: Patches item #732401, was opened at 2003-05-04 23: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=732401&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: Allows os.forkpty to work on more platforms (Solaris!) Initial Comment: Recent changes to os.openpty() make it much more portable than earlier versions. Unfortunately, os.forkpty() was not also upgraded. This patch to posixpath.c allows os.forkpty() to run on any platform that supports os.openpty(). This new os.forkpty() will use the C system call forkpty() if available. If not available, then it will do it the old fashioned way with openpty and fork (and only if those too are available, otherwise forkpty remains undefined as before). Other benefits: Since the pty module is based on os.forkpty() this patch will automatically allow pty.fork() to work properly on more platforms. The pty module does not need to be changed. The logic for supporting pty's on multiple platforms can be maintained in one spot instead of in both the posix_module.c and pty.py One of the more notable platforms that does not support the forkpty system call is Solaris. Most importantly to me, this patch will allow os.forkpty() to be available under Solaris. I am testing it with my Pexpect module which makes heavy use of the pty module. With this patch Pexpect passes all my unit tests on Solaris. Pexpect has been tested on Linux, OpenBSD, Solaris, and Cygwin. I'm looking for an OS X server to test with. The code for forkpty should be quite portable and is based on the pty code in OpenSSH and the example in Stevens' "Advanced Programming in the UNIX Environment". I have included a test script, test_forkpty.py. Yours, Noah 
# Test to see if forkpty works. (But don't worry if it
isn't available.)

import os, time
from test.test_support import verbose, TestFailed,
TestSkipped

try:
    if verbose:
        print 'Calling os.forkpty()'
    pid, fd = os.forkpty()
except AttributeError:
    raise TestSkipped, 'No os.forkpty() available.'

if pid == 0: # child
    print 'I am not a robot!'
else:
    if verbose:
        print '(pid, fd) = (%d, %d)' % (pid, fd)
    time.sleep(1) # Give the child a chance to print.
    print 'Robots always say:', os.read(fd,100)
    os.close(fd)
---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 From noreply@sourceforge.net Mon May 5 01:03:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 17:03:35 -0700 Subject: [Patches] [ python-Patches-731607 ] make threading join() method return a value Message-ID: Patches item #731607, was opened at 2003-05-02 17:19 Message generated for change (Comment added) made by mboedick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: make threading join() method return a value Initial Comment: This patch makes the join() method of a threading module Thread return the value that was returned by the callable that is running in the thread. It came about because I needed to split a process into a number of threads, join them all, and then check what each of them returned before proceeding. It against the current CVS tree, tested on Linux. ---------------------------------------------------------------------- >Comment By: Matthew Boedicker (mboedick) Date: 2003-05-04 20:03 Message: Logged In: YES user_id=119895 The problem with using a Queue is that it requires whatever is running in the thread to be aware it is running in a thread. It would force non-threaded programs using that method to deal with Queues. With the patch, there would be a standard, intuitive way to return data to the caller that worked whether the method was running in a separate thread or not. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-02 17:35 Message: Logged In: YES user_id=357491 I don't think this is truly necessary. If you needed to know what they would return just insert it into a Queue and when the 'join' calls finish check the Queue to see what was added. It also deviates from Java's threading setup which 'threading' is based on. I'm -1 on this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 From noreply@sourceforge.net Mon May 5 01:22:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 17:22:32 -0700 Subject: [Patches] [ python-Patches-731607 ] make threading join() method return a value Message-ID: Patches item #731607, was opened at 2003-05-02 14:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: make threading join() method return a value Initial Comment: This patch makes the join() method of a threading module Thread return the value that was returned by the callable that is running in the thread. It came about because I needed to split a process into a number of threads, join them all, and then check what each of them returned before proceeding. It against the current CVS tree, tested on Linux. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-04 17:22 Message: Logged In: YES user_id=357491 But don't you have the requirement that the code know that it is running in a thread when you made your subclass of threading.thread? And even if you didn't, why can't you just wrap the code to catch the return value and push it into the queue in a threading class? I am not going to reject this patch, Matthew, until someone else with commit privs comes in and says they don't like the patch either, so no need to worry... yet. =) ---------------------------------------------------------------------- Comment By: Matthew Boedicker (mboedick) Date: 2003-05-04 17:03 Message: Logged In: YES user_id=119895 The problem with using a Queue is that it requires whatever is running in the thread to be aware it is running in a thread. It would force non-threaded programs using that method to deal with Queues. With the patch, there would be a standard, intuitive way to return data to the caller that worked whether the method was running in a separate thread or not. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-02 14:35 Message: Logged In: YES user_id=357491 I don't think this is truly necessary. If you needed to know what they would return just insert it into a Queue and when the 'join' calls finish check the Queue to see what was added. It also deviates from Java's threading setup which 'threading' is based on. I'm -1 on this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 From noreply@sourceforge.net Mon May 5 04:23:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 20:23:43 -0700 Subject: [Patches] [ python-Patches-731607 ] make threading join() method return a value Message-ID: Patches item #731607, was opened at 2003-05-02 17:19 Message generated for change (Comment added) made by mboedick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: make threading join() method return a value Initial Comment: This patch makes the join() method of a threading module Thread return the value that was returned by the callable that is running in the thread. It came about because I needed to split a process into a number of threads, join them all, and then check what each of them returned before proceeding. It against the current CVS tree, tested on Linux. ---------------------------------------------------------------------- >Comment By: Matthew Boedicker (mboedick) Date: 2003-05-04 23:23 Message: Logged In: YES user_id=119895 I wasn't subclassing Thread, just instantiating it and passing in a target. I didn't think of writing a wrapper, but that would work for me. I still think having join() return something that might be useful in some circumstances is better than having it return something which is always useless (None), and easier than dealing with Queues or wrappers. Anyway, thanks for feedback. I'll probably use the wrapper approach for now. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-04 20:22 Message: Logged In: YES user_id=357491 But don't you have the requirement that the code know that it is running in a thread when you made your subclass of threading.thread? And even if you didn't, why can't you just wrap the code to catch the return value and push it into the queue in a threading class? I am not going to reject this patch, Matthew, until someone else with commit privs comes in and says they don't like the patch either, so no need to worry... yet. =) ---------------------------------------------------------------------- Comment By: Matthew Boedicker (mboedick) Date: 2003-05-04 20:03 Message: Logged In: YES user_id=119895 The problem with using a Queue is that it requires whatever is running in the thread to be aware it is running in a thread. It would force non-threaded programs using that method to deal with Queues. With the patch, there would be a standard, intuitive way to return data to the caller that worked whether the method was running in a separate thread or not. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-02 17:35 Message: Logged In: YES user_id=357491 I don't think this is truly necessary. If you needed to know what they would return just insert it into a Queue and when the 'join' calls finish check the Queue to see what was added. It also deviates from Java's threading setup which 'threading' is based on. I'm -1 on this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 From noreply@sourceforge.net Mon May 5 05:08:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 21:08:59 -0700 Subject: [Patches] [ python-Patches-732479 ] configure buglets Message-ID: Patches item #732479, was opened at 2003-05-05 04: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=732479&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: configure buglets Initial Comment: On OS X, at least, the test for inet_pton fails because sys/types.h is not included before socket.h. The test for setgroups fails because there is a typo in the configure script: #include Additionally, the failure to detect inet_pton causes compile errors due to a conflicting definition of the inet_pton emulation in socketmodule.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732479&group_id=5470 From noreply@sourceforge.net Mon May 5 05:15:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 21:15:14 -0700 Subject: [Patches] [ python-Patches-732479 ] configure buglets Message-ID: Patches item #732479, was opened at 2003-05-05 04:08 Message generated for change (Comment added) made by brianl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732479&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: configure buglets Initial Comment: On OS X, at least, the test for inet_pton fails because sys/types.h is not included before socket.h. The test for setgroups fails because there is a typo in the configure script: #include Additionally, the failure to detect inet_pton causes compile errors due to a conflicting definition of the inet_pton emulation in socketmodule.c. ---------------------------------------------------------------------- >Comment By: Brian Lenihan (brianl) Date: 2003-05-05 04:15 Message: Logged In: YES user_id=17671 Hmm, SF seems to be reluctant to let my patch upload. Trying again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732479&group_id=5470 From noreply@sourceforge.net Mon May 5 05:58:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 21:58:41 -0700 Subject: [Patches] [ python-Patches-732284 ] UnixWare 7 build patch Message-ID: Patches item #732284, was opened at 2003-05-04 20:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7 build patch Initial Comment: Here is a patch to fix the build on UnixWare 7 & OpenUNIX 8 without taking the simple route of define_xopen_source=no. This patch depends on patches 731191 and 732234 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 06:58 Message: Logged In: YES user_id=21627 When I asked "is there no way to get these types", I didn't expect that the answer would be "sure, Python can define them itself". By that approach, you wouldn't need any system headers, but could include any declaration literally in Python, with #ifdef UW7. This is clearly not the right solution: I meant to ask "is there no way to get these types *from the system headers*" If the answer to that question is "no", then I'm still curious what the answer to the question "Why *specifically* do we need u_int in the first place?" is. By "specifically", I mean what *specific* other declaration from the system headers relies on it, saying that sys/socket.h needs it is too general. I'm willing to go with the simple patch, provided it is changed in the following way: 1. A comment is added indicating what the specific reason for this patch is. 2. The system check is strengthened to not include future system releases. I.e. saying OpenUNIX/8.*|UnixWare/7.* is too generic: include a list of minor system releases so far. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 23:59 Message: Logged In: YES user_id=618097 If I define _POSIX_SOURCE the data types are available but I get a whole new set of errors in posixmodule.c .... cc -Kthread -K pentium,host,inline,loop_unroll,alloca -DNDEBUG -O -I. -I/opt/src/utils/python/python/dist/src/Include -DPy_BUILD_CORE -c /opt/src/utils/python/python/dist/src/Modules/posixmodule.c -o Modules/posixmodule.o UX:acomp: ERROR: "/usr/include/sys/wait.h", line 141: Syntax error before or at: siginfo_t UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 874: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 875: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 876: improper member use: tv_nsec gmake: *** [Modules/posixmodule.o] Error 1 .... I'm attaching a new patch that has the data type checks from patch 731991. With this patch (which still depends on patches 731991 & 732234) UnixWare 7 builds. It's kind of ugly and I don't like it much. The simple alternative is to use this patch -------------------------- --- configure.in.old 2003-04-17 13:16:42.000000000 -0700 +++ configure.in 2003-04-22 15:26:13.450080095 -0700 @@ -124,6 +124,8 @@ # of union __?sigval. Reported by Stuart Bishop. SunOS/5.6) define_xopen_source=no;; + OpenUNIX/8.* | UnixWare/7.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes -------------------------- ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 22:09 Message: Logged In: YES user_id=618097 There may be a way Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:15 Message: Logged In: YES user_id=21627 Is there absolutely no way to get to these types when _XOPEN_SOURCE is defined? Not by including some obscure header file? Not by defining some obscure macro? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 From noreply@sourceforge.net Mon May 5 06:06:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 22:06:02 -0700 Subject: [Patches] [ python-Patches-732234 ] configure gets threads wrong sometimes Message-ID: Patches item #732234, was opened at 2003-05-04 19:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732234&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Martin v. Löwis (loewis) Summary: configure gets threads wrong sometimes Initial Comment: This patch fixes the compiler options for threads on UnixWare 7 Without it you get this warning. UX:cc: WARNING: Use -Kthread instead of -lthread when linking with threads library; using -lthread directly may cause incorrect execution behavior. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 07:06 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure 1.395 configure.in 1.406 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732234&group_id=5470 From noreply@sourceforge.net Mon May 5 06:15:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 22:15:29 -0700 Subject: [Patches] [ python-Patches-732284 ] UnixWare 7 build patch Message-ID: Patches item #732284, was opened at 2003-05-04 20:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7 build patch Initial Comment: Here is a patch to fix the build on UnixWare 7 & OpenUNIX 8 without taking the simple route of define_xopen_source=no. This patch depends on patches 731191 and 732234 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 07:15 Message: Logged In: YES user_id=21627 I have now disabled _XOPEN_SOURCE in configure 1.396 configure.in 1.407 I have used the information provided in 731991, and assumed that the patch is necessary for UnixWare 7.1.[123], where 7.1.2 identifies itself as OpenUNIX 8.0. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 06:58 Message: Logged In: YES user_id=21627 When I asked "is there no way to get these types", I didn't expect that the answer would be "sure, Python can define them itself". By that approach, you wouldn't need any system headers, but could include any declaration literally in Python, with #ifdef UW7. This is clearly not the right solution: I meant to ask "is there no way to get these types *from the system headers*" If the answer to that question is "no", then I'm still curious what the answer to the question "Why *specifically* do we need u_int in the first place?" is. By "specifically", I mean what *specific* other declaration from the system headers relies on it, saying that sys/socket.h needs it is too general. I'm willing to go with the simple patch, provided it is changed in the following way: 1. A comment is added indicating what the specific reason for this patch is. 2. The system check is strengthened to not include future system releases. I.e. saying OpenUNIX/8.*|UnixWare/7.* is too generic: include a list of minor system releases so far. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 23:59 Message: Logged In: YES user_id=618097 If I define _POSIX_SOURCE the data types are available but I get a whole new set of errors in posixmodule.c .... cc -Kthread -K pentium,host,inline,loop_unroll,alloca -DNDEBUG -O -I. -I/opt/src/utils/python/python/dist/src/Include -DPy_BUILD_CORE -c /opt/src/utils/python/python/dist/src/Modules/posixmodule.c -o Modules/posixmodule.o UX:acomp: ERROR: "/usr/include/sys/wait.h", line 141: Syntax error before or at: siginfo_t UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 874: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 875: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 876: improper member use: tv_nsec gmake: *** [Modules/posixmodule.o] Error 1 .... I'm attaching a new patch that has the data type checks from patch 731991. With this patch (which still depends on patches 731991 & 732234) UnixWare 7 builds. It's kind of ugly and I don't like it much. The simple alternative is to use this patch -------------------------- --- configure.in.old 2003-04-17 13:16:42.000000000 -0700 +++ configure.in 2003-04-22 15:26:13.450080095 -0700 @@ -124,6 +124,8 @@ # of union __?sigval. Reported by Stuart Bishop. SunOS/5.6) define_xopen_source=no;; + OpenUNIX/8.* | UnixWare/7.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes -------------------------- ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 22:09 Message: Logged In: YES user_id=618097 There may be a way Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:15 Message: Logged In: YES user_id=21627 Is there absolutely no way to get to these types when _XOPEN_SOURCE is defined? Not by including some obscure header file? Not by defining some obscure macro? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 From noreply@sourceforge.net Mon May 5 06:18:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 22:18:09 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-04 01:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 07:18 Message: Logged In: YES user_id=21627 I have now disabled _XOPEN_SOURCE for this system. Before applying a patch like this one, I'd like to know a) how it works (see my first comment) b) what specific error it fixes on UnixWare. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 23:39 Message: Logged In: YES user_id=618097 That was a waste of time. I mis read sys/types.h on OpenServer u_int and u_short are not defined because they are warped inside #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) #endif /* !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) */ The error is "/usr/include/sys/socket.h", line 171: error: Syntax error before or at: u_short "/usr/include/sys/socket.h", line 171: error: cannot recover from previous errors .... 167:/* 168: * Structure used by kernel to store most addresses. 169: */ 170:struct sockaddr { 171: u_short sa_family; /* address family */ 172: char sa_data[14]; /* up to 14 bytes of direct address */ 173:}; 174: .... I've modified the patch to be less obtrusive my undefing _XOPEN_SOURCE on OpenServer only. We may end up removing the confdefs2.h parts later if we end up using define_xopen_source=no for OpenServer. As it stands now, with or without this patch, OpenServer doesn't build. This patch is really for SVR4.2 and SVR5 systems. (Ie. UnixWare) ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 22:08 Message: Logged In: YES user_id=618097 There may be a way. Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:51 Message: Logged In: YES user_id=21627 Now we are getting closer. What is the specific line in sys/socket.h that gives the syntax error? Are there alternative definitions of the (function, I suppose), either in socket.h or in another file? Why is u_int not defined when _XOPEN_SOURCE is? IOW: Are you absolutely, definitely, 100% certain that there is no way to compile sys/socket.h when _XOPEN_SOURCE is defined? That would be a serious bug in the system. Now, if we can establish with certainty that the system is broken beyond repair, it is acceptable to work around the bugs, by not defining _XOPEN_SOURCE. We then need to record the specific release of the system that we found is broken, and we need to document what specifically we found broken about it. For better reproducability, we also want to record the name of the person who determined the system being broken. We do all this in the hope that future system releases will be fixed by the system vendors, and that our work-arounds won't be needed anymore when we stop supporting old releases of the system (at a time when nobody uses those old releases anymore). I am not opposed to setting _define_xopen_source=no in principle (I once was, but am not any longer). I only want a convincing analysis that this is necessary to get essential parts of Python (such as sockets) to work. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 21:29 Message: Logged In: YES user_id=618097 Without u_short and u_int the soclklen_t test can NEVER suceed on OpenServer because of a syntax error in sys/socket.h whthout them. Ugly, but you don't seem to like the option of seting define_xopen_source=no on platforms that puilt fine prior to 2.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:18 Message: Logged In: YES user_id=21627 Why do you say "is needed for the socklen_t test"? Are you referring to the test in your patch? In this test, u_int is not *used* at all, it is only defined. So not defining it should not cause problems. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 21:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 20:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 19:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Mon May 5 21:21:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 13:21:06 -0700 Subject: [Patches] [ python-Patches-729395 ] Dictionary tuning Message-ID: Patches item #729395, was opened at 2003-04-29 03:03 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary tuning Initial Comment: The idea is to make dictionaries more sparse on average (decreasing the density between 0 and 50%). This results in fewer collisions, faster collision resolution, fewer memory accesses, and better cache performance. A small side-benefit is halving the number of expensive resize operations as the dictionary grows and reducing the cost of the resize operations. The patch helps both smaller sized dictionaries and large ones. It entails a one line change to dictobject.c resulting in a new schedule of dictionary sizes for a given number of entries: Number of Current size Proposed size Filled Entries of dictionary of dictionary -------------- ------------- ------------- 0 to 5 8 8 6 to 10 16 32 11 to 21 32 32 22 to 42 64 128 43 to 85 128 128 86 to 170 256 512 171 to 341 512 512 and so on until 100,000 entries where the old schedule takes over. The 100,000 entry limit was added because of python-dev feedback about memory consumption in the presence of many large dictionaries. At 12 bytes per entry on a 32-bit box, the switchback occurs at 1.2 Mb for a single dict. This ought to allow hundreds of large dictionaries on common memory sizes. Performance improvements vary from application to application and across various hardware setups. So far, typical results are from 0 to 5%. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 15:21 Message: Logged In: YES user_id=44345 Using Guido's version I saw a consistent improvement in pystone numbers. I ran it five times each with and without the patch. Every "after" run was faster than every "before" run and comparing the fastest run of each showed a 5.4% improvement (13587 vs. 14326.6 pystones). I also ran the pystone benchmark using python -i and then used ps to examine the memory usage after completion. VM and RSS both increased modestly (VM by 0.2%, from 27936 to 27984 and 2.2%, RSS from 3520 to 3600). Not a big deal in my book, but I'm one of those people w/ 1GB of RAM Tim referred to. ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 05:56 Message: Logged In: YES user_id=6380 However note that I cannot reproduce the speedup on Zope 3 startup any more. It may have been something else in my system. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 05:49 Message: Logged In: YES user_id=6380 My preferred version, with code reordering suggested by Tim and further refinement by me (dict2.diff) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 From noreply@sourceforge.net Mon May 5 21:29:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 13:29:26 -0700 Subject: [Patches] [ python-Patches-729395 ] Dictionary tuning Message-ID: Patches item #729395, was opened at 2003-04-29 04:03 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Dictionary tuning Initial Comment: The idea is to make dictionaries more sparse on average (decreasing the density between 0 and 50%). This results in fewer collisions, faster collision resolution, fewer memory accesses, and better cache performance. A small side-benefit is halving the number of expensive resize operations as the dictionary grows and reducing the cost of the resize operations. The patch helps both smaller sized dictionaries and large ones. It entails a one line change to dictobject.c resulting in a new schedule of dictionary sizes for a given number of entries: Number of Current size Proposed size Filled Entries of dictionary of dictionary -------------- ------------- ------------- 0 to 5 8 8 6 to 10 16 32 11 to 21 32 32 22 to 42 64 128 43 to 85 128 128 86 to 170 256 512 171 to 341 512 512 and so on until 100,000 entries where the old schedule takes over. The 100,000 entry limit was added because of python-dev feedback about memory consumption in the presence of many large dictionaries. At 12 bytes per entry on a 32-bit box, the switchback occurs at 1.2 Mb for a single dict. This ought to allow hundreds of large dictionaries on common memory sizes. Performance improvements vary from application to application and across various hardware setups. So far, typical results are from 0 to 5%. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 16:29 Message: Logged In: YES user_id=6380 I say, check it in, it can't hurt. A comment in the code should explain the considerations though. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 16:21 Message: Logged In: YES user_id=44345 Using Guido's version I saw a consistent improvement in pystone numbers. I ran it five times each with and without the patch. Every "after" run was faster than every "before" run and comparing the fastest run of each showed a 5.4% improvement (13587 vs. 14326.6 pystones). I also ran the pystone benchmark using python -i and then used ps to examine the memory usage after completion. VM and RSS both increased modestly (VM by 0.2%, from 27936 to 27984 and 2.2%, RSS from 3520 to 3600). Not a big deal in my book, but I'm one of those people w/ 1GB of RAM Tim referred to. ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 06:56 Message: Logged In: YES user_id=6380 However note that I cannot reproduce the speedup on Zope 3 startup any more. It may have been something else in my system. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 06:49 Message: Logged In: YES user_id=6380 My preferred version, with code reordering suggested by Tim and further refinement by me (dict2.diff) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 From noreply@sourceforge.net Mon May 5 21:40:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 13:40:49 -0700 Subject: [Patches] [ python-Patches-730594 ] assert from longobject.c, line 1215 Message-ID: Patches item #730594, was opened at 2003-05-01 00:43 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470 Category: Core (C code) >Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Chris Johns (cjohns) >Assigned to: Tim Peters (tim_one) Summary: assert from longobject.c, line 1215 Initial Comment: RTEMS port running on the Coldfire (m5200) processor. RTEMS is version 4.6.0pre3 and the lastest RTEMS tool set. The target is m68k-rtems. GCC 3.2.2 and GCC 3.2.3 both cause the assert in the file: Objects/longmodule.c:1215 The assert test is in the function 'long_from_binary_base': assert(k < base); The assert and related code is valid, gcc is generating bad code. The bad code is related to the "digit" variable k being a short and the base being an int (32bit on Coldfire). GCC seems to get a little confused about which 16bit half to compare against. The simple fix is to make "k" an int and so be the same size as base. The 'k' variable is an int in the loop just above that figures out the total number of bits needed. This change also generated faster code for the Coldfire. I know a selection of one CPU is not a valid analysis, how-ever base and k being the same seemed to help gcc. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-05 16:40 Message: Logged In: YES user_id=31435 If you could try current CVS Python, that would be great. I don't mind changing the code here, but if k becomes signed in this loop then I don't want to continue forcing ch to be unsigned in this loop, so I changed more than just the one declaration. I'll leave the patch open until you can find out whether it worms around your gcc problem. Objects/longobject.c; new revision: 1.160 ---------------------------------------------------------------------- Comment By: Chris Johns (cjohns) Date: 2003-05-01 00:51 Message: Logged In: YES user_id=197074 Be a good idea if I read the instructions and checked the patch attached box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470 From noreply@sourceforge.net Mon May 5 21:48:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 13:48:47 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-05 22:48 Message: Logged In: YES user_id=89016 And now for something completely different: test_uu.py ported to PyUnit. Raymond can you check that this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 19:58 Message: Logged In: YES user_id=89016 OK, I've changed the new run_unittest() to call run_suite() with a second argument if exactly one testcase is passed. I hope that's OK. Checked in as: test_StringIO.py 1.16 test___all__.py 1.30 test_base64.py 1.6 test_bisect.py 1.9 test_bool.py 1.12 test_builtin.py 1.19 test_bz2.py 1.14 test_calendar.py 1.5 test_call.py 1.4 test_cfgparser.py 1.20 test_charmapcodec.py 1.7 test_codeccallbacks.py 1.12 test_codecs.py 1.9 test_copy.py 1.8 test_cpickle.py 1.15 test_csv.py 1.6 test_dummy_thread.py 1.4 test_enumerate.py 1.4 test_filecmp.py 1.2 test_getargs2.py 1.5 test_grp.py 1.16 test_hexoct.py 1.4 test_hmac.py 1.7 test_isinstance.py 1.7 test_itertools.py 1.6 test_optparse.py 1.2 test_os.py 1.18 test_parser.py 1.17 test_pep277.py 1.6 test_pickle.py 1.18 test_posix.py 1.6 test_pow.py 1.18 test_profilehooks.py 1.10 test_pwd.py 1.17 test_re.py 1.42 test_richcmp.py 1.9 test_sets.py 1.24 test_shelve.py 1.5 test_shutil.py 1.2 test_socket.py 1.64 test_str.py 1.3 test_string.py 1.25 test_strptime.py 1.13 test_support.py 1.52 test_sys.py 1.7 test_tarfile.py 1.8 test_tempfile.py 1.14 test_textwrap.py 1.19 test_timeout.py 1.14 test_trace.py 1.9 test_ucn.py 1.14 test_unicode.py 1.83 test_unicodedata.py 1.9 test_univnewlines.py 1.5 test_urllib.py 1.13 test_urllibnet.py 1.2 test_userdict.py 1.15 test_userlist.py 1.9 test_userstring.py 1.11 test_weakref.py 1.23 test_xpickle.py 1.4 test_zipimport.py 1.8 test_zlib.py 1.23 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 19:17 Message: Logged In: YES user_id=80475 My preference was to keep run_classtests() as a separate function. The run_unittest() function was unique in that it called run_suite() with two arguments instead of one. That accounts for the additional verbosity you are seeing. While I prefer the separate run_classtests(), it's up to you to do whichever seems best. Otherwise, all looks okay. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 18:54 Message: Logged In: YES user_id=89016 I've changed test_support.run_unittest() to work like your run_classtests() and changed all test scripts to use this. (see diff2.txt) I compared the output of ./python Lib/test/regrtest.py -v 2>&1 | grep -v "Ran.*test.*in" and apart from the fact that test_csv seems to be more verbose now, there seem to be no regression bugs. Raymond, can you check, if this is OK? BTW, there's another check for memory leaks in test_datetime.py. Perhaps it would make sense to combine both and use them globally in regrtest.py (or test_support.py)? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-29 23:39 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_richcmp.py 1.8 Lib/test/output/test_richcmp delete which a few additional tests and comments. I'll probably work on using run_classtests() tomorrow, but wouldn't it be simpler to add the multiple arguments to the already existing function run_unittest() instead of introducing the new run_classtests()? > BTW, why is the int to int comparison labeled as useless? Because it would check whether comparing two ints gives the same result as comparing the same two ints. ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 21:10 Message: Logged In: YES user_id=80475 Yes. test_support.run_classtests() ought to be used everywhere it is applicable. There are a couple of places like test_sets.py where the "suite" variable is used again for other purposed (testing for memory leaks). In those cases, it ought to be left alone until I can write a function that encapsulates the essense of the combined test. test_richcmp.py looks good. Please add comment lines describing the point of classes and tests whose names are not self explanatory (i.e. misbehavin, weird, etc). BTW, why is the int to int comparison labeled as useless? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-28 20:42 Message: Logged In: YES user_id=89016 Here's the next one: test_richcmp.py with a few additional tests to increase code coverage in object.c and listobject.c. BTW, should we change all tests to use the new test_support.run_classtests()? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-25 13:40 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_bool.py 1.9 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 23:00 Message: Logged In: YES user_id=6380 I suggest not to mess with unittest.py; it is still externally maintained as PyUnit. Maybe ask the PyUnit developer. No time to review the test, sorry; if it works, I suggest to just check it in. ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 22:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 13:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-15 01:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 14:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 11:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Mon May 5 23:01:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 15:01:06 -0700 Subject: [Patches] [ python-Patches-732479 ] configure buglets Message-ID: Patches item #732479, was opened at 2003-05-05 06:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732479&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: configure buglets Initial Comment: On OS X, at least, the test for inet_pton fails because sys/types.h is not included before socket.h. The test for setgroups fails because there is a typo in the configure script: #include Additionally, the failure to detect inet_pton causes compile errors due to a conflicting definition of the inet_pton emulation in socketmodule.c. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-06 00:01 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure 1.397 configure.in 1.408 ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2003-05-05 06:15 Message: Logged In: YES user_id=17671 Hmm, SF seems to be reluctant to let my patch upload. Trying again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732479&group_id=5470 From noreply@sourceforge.net Mon May 5 23:23:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 15:23:26 -0700 Subject: [Patches] [ python-Patches-729395 ] Dictionary tuning Message-ID: Patches item #729395, was opened at 2003-04-29 03:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Dictionary tuning Initial Comment: The idea is to make dictionaries more sparse on average (decreasing the density between 0 and 50%). This results in fewer collisions, faster collision resolution, fewer memory accesses, and better cache performance. A small side-benefit is halving the number of expensive resize operations as the dictionary grows and reducing the cost of the resize operations. The patch helps both smaller sized dictionaries and large ones. It entails a one line change to dictobject.c resulting in a new schedule of dictionary sizes for a given number of entries: Number of Current size Proposed size Filled Entries of dictionary of dictionary -------------- ------------- ------------- 0 to 5 8 8 6 to 10 16 32 11 to 21 32 32 22 to 42 64 128 43 to 85 128 128 86 to 170 256 512 171 to 341 512 512 and so on until 100,000 entries where the old schedule takes over. The 100,000 entry limit was added because of python-dev feedback about memory consumption in the presence of many large dictionaries. At 12 bytes per entry on a 32-bit box, the switchback occurs at 1.2 Mb for a single dict. This ought to allow hundreds of large dictionaries on common memory sizes. Performance improvements vary from application to application and across various hardware setups. So far, typical results are from 0 to 5%. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 17:23 Message: Logged In: YES user_id=80475 Applied to Objects/dictobject.c 2.145 Closing patch. Thanks to all who contributed, timed, or encouraged. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 15:29 Message: Logged In: YES user_id=6380 I say, check it in, it can't hurt. A comment in the code should explain the considerations though. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 15:21 Message: Logged In: YES user_id=44345 Using Guido's version I saw a consistent improvement in pystone numbers. I ran it five times each with and without the patch. Every "after" run was faster than every "before" run and comparing the fastest run of each showed a 5.4% improvement (13587 vs. 14326.6 pystones). I also ran the pystone benchmark using python -i and then used ps to examine the memory usage after completion. VM and RSS both increased modestly (VM by 0.2%, from 27936 to 27984 and 2.2%, RSS from 3520 to 3600). Not a big deal in my book, but I'm one of those people w/ 1GB of RAM Tim referred to. ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 05:56 Message: Logged In: YES user_id=6380 However note that I cannot reproduce the speedup on Zope 3 startup any more. It may have been something else in my system. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 05:49 Message: Logged In: YES user_id=6380 My preferred version, with code reordering suggested by Tim and further refinement by me (dict2.diff) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 From noreply@sourceforge.net Mon May 5 23:30:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 15:30:18 -0700 Subject: [Patches] [ python-Patches-671454 ] Optimize dictionary resizing Message-ID: Patches item #671454, was opened at 2003-01-20 18:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671454&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Optimize dictionary resizing Initial Comment: Revisiting Oren’s fastnames patch, I think a simpler approach is warranted. Using a setitem macro skips a function call but doesn’t get to the root of problem. Likewise, a pointer search is not helpful because lookupstring() already attempts a pointer comparison first and a hash comparison as a fallback (also, a pointer search fails to find non- interned comparisons). There is more promise in optimizing the search/fail/fallback sequence of looking for locals, globals, and builtins, but the approach of using custom look-ups and having negative entries is too invasive. The real issue is that the dictionaries are too full. Whenever, it hits 2/3’s full, a resize is triggered which doubles the size of the dictionary, still leaving it relatively full and relatively close to the next (expensive) resize operation. This patch makes the setitem resize operation quadruple the size of the dictionary. This leads to fewer total resize operations and leaves the dictionary more sparsely populated (not only leading to fewer collisions, but allowing immediate detection of NOT IN without doing *any* comparisons of pointers or hashcodes). The patch is minimally invasive. It is only one line! However, is does change the order of dictionaries, so doctest style test code will sense the change immediately. Four timing suites are attached. Two, directly measure speed-ups for accessing globals and __builtins__. The other two are real world apps which tap into all facets of python including subclassing, lambdas and functionals, large and small dicts, a wide array of data structures, heavy processing of strings, tuples, and numbers. Each of the suites shows improvements ranging from 5% to 25%. PyStone also shows a marginal improvement which is surprising because it is dominated by fast locals. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 17:30 Message: Logged In: YES user_id=80475 Discussed on python-dev. Added a limit at 50k entries. Applied as Objects/dictobject.c 2.145. Documented remaining research Objects/dictnotes.txt ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-11 20:59 Message: Logged In: YES user_id=80475 I timed many different dictionary tune-ups and found that the optimal combination varies depending on the benchmark and needs of the application (uniquifying is store intensive and membership testing is retrieve intensive). The results also vary from processor to processor, and they depend on the amount/type of cache memory available. The tuning options include varying the dict resize trigger ratio from 2/3, altering the size of smalldict, quadrupling space upon resize, and special casing smaller dictionaries. At some point, I'll post the best of these and everyone can try it with their own apps and machine. All of the above parameters can be set arbitrarily and there is no reason to think that the current settings are the optimum for most time critical applications. The attached patch is simple and gives some improvement to many applications. I hesitate to push it forward with more independent timings in different environments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671454&group_id=5470 From noreply@sourceforge.net Mon May 5 23:33:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 15:33:30 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 18:09 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 17:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Mon May 5 23:56:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 15:56:35 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 17:56 Message: Logged In: YES user_id=80475 Yes. It's fine. Hey, I think it's time to start a new patch for future changes. This one is getting huge. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-05 15:48 Message: Logged In: YES user_id=89016 And now for something completely different: test_uu.py ported to PyUnit. Raymond can you check that this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 12:58 Message: Logged In: YES user_id=89016 OK, I've changed the new run_unittest() to call run_suite() with a second argument if exactly one testcase is passed. I hope that's OK. Checked in as: test_StringIO.py 1.16 test___all__.py 1.30 test_base64.py 1.6 test_bisect.py 1.9 test_bool.py 1.12 test_builtin.py 1.19 test_bz2.py 1.14 test_calendar.py 1.5 test_call.py 1.4 test_cfgparser.py 1.20 test_charmapcodec.py 1.7 test_codeccallbacks.py 1.12 test_codecs.py 1.9 test_copy.py 1.8 test_cpickle.py 1.15 test_csv.py 1.6 test_dummy_thread.py 1.4 test_enumerate.py 1.4 test_filecmp.py 1.2 test_getargs2.py 1.5 test_grp.py 1.16 test_hexoct.py 1.4 test_hmac.py 1.7 test_isinstance.py 1.7 test_itertools.py 1.6 test_optparse.py 1.2 test_os.py 1.18 test_parser.py 1.17 test_pep277.py 1.6 test_pickle.py 1.18 test_posix.py 1.6 test_pow.py 1.18 test_profilehooks.py 1.10 test_pwd.py 1.17 test_re.py 1.42 test_richcmp.py 1.9 test_sets.py 1.24 test_shelve.py 1.5 test_shutil.py 1.2 test_socket.py 1.64 test_str.py 1.3 test_string.py 1.25 test_strptime.py 1.13 test_support.py 1.52 test_sys.py 1.7 test_tarfile.py 1.8 test_tempfile.py 1.14 test_textwrap.py 1.19 test_timeout.py 1.14 test_trace.py 1.9 test_ucn.py 1.14 test_unicode.py 1.83 test_unicodedata.py 1.9 test_univnewlines.py 1.5 test_urllib.py 1.13 test_urllibnet.py 1.2 test_userdict.py 1.15 test_userlist.py 1.9 test_userstring.py 1.11 test_weakref.py 1.23 test_xpickle.py 1.4 test_zipimport.py 1.8 test_zlib.py 1.23 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 12:17 Message: Logged In: YES user_id=80475 My preference was to keep run_classtests() as a separate function. The run_unittest() function was unique in that it called run_suite() with two arguments instead of one. That accounts for the additional verbosity you are seeing. While I prefer the separate run_classtests(), it's up to you to do whichever seems best. Otherwise, all looks okay. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 11:54 Message: Logged In: YES user_id=89016 I've changed test_support.run_unittest() to work like your run_classtests() and changed all test scripts to use this. (see diff2.txt) I compared the output of ./python Lib/test/regrtest.py -v 2>&1 | grep -v "Ran.*test.*in" and apart from the fact that test_csv seems to be more verbose now, there seem to be no regression bugs. Raymond, can you check, if this is OK? BTW, there's another check for memory leaks in test_datetime.py. Perhaps it would make sense to combine both and use them globally in regrtest.py (or test_support.py)? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-29 16:39 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_richcmp.py 1.8 Lib/test/output/test_richcmp delete which a few additional tests and comments. I'll probably work on using run_classtests() tomorrow, but wouldn't it be simpler to add the multiple arguments to the already existing function run_unittest() instead of introducing the new run_classtests()? > BTW, why is the int to int comparison labeled as useless? Because it would check whether comparing two ints gives the same result as comparing the same two ints. ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 14:10 Message: Logged In: YES user_id=80475 Yes. test_support.run_classtests() ought to be used everywhere it is applicable. There are a couple of places like test_sets.py where the "suite" variable is used again for other purposed (testing for memory leaks). In those cases, it ought to be left alone until I can write a function that encapsulates the essense of the combined test. test_richcmp.py looks good. Please add comment lines describing the point of classes and tests whose names are not self explanatory (i.e. misbehavin, weird, etc). BTW, why is the int to int comparison labeled as useless? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-28 13:42 Message: Logged In: YES user_id=89016 Here's the next one: test_richcmp.py with a few additional tests to increase code coverage in object.c and listobject.c. BTW, should we change all tests to use the new test_support.run_classtests()? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-25 06:40 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_bool.py 1.9 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 16:00 Message: Logged In: YES user_id=6380 I suggest not to mess with unittest.py; it is still externally maintained as PyUnit. Maybe ask the PyUnit developer. No time to review the test, sorry; if it works, I suggest to just check it in. ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 15:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 06:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-14 18:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 07:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 04:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 20:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 04:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 03:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 14:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 10:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 08:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 12:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 08:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-20 22:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 13:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 04:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 15:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 06:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 03:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 13:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 18:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Tue May 6 00:31:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 16:31:54 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 18:09 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 18:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 17:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Tue May 6 01:16:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 17:16:01 -0700 Subject: [Patches] [ python-Patches-729395 ] Dictionary tuning Message-ID: Patches item #729395, was opened at 2003-04-29 04:03 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Dictionary tuning Initial Comment: The idea is to make dictionaries more sparse on average (decreasing the density between 0 and 50%). This results in fewer collisions, faster collision resolution, fewer memory accesses, and better cache performance. A small side-benefit is halving the number of expensive resize operations as the dictionary grows and reducing the cost of the resize operations. The patch helps both smaller sized dictionaries and large ones. It entails a one line change to dictobject.c resulting in a new schedule of dictionary sizes for a given number of entries: Number of Current size Proposed size Filled Entries of dictionary of dictionary -------------- ------------- ------------- 0 to 5 8 8 6 to 10 16 32 11 to 21 32 32 22 to 42 64 128 43 to 85 128 128 86 to 170 256 512 171 to 341 512 512 and so on until 100,000 entries where the old schedule takes over. The 100,000 entry limit was added because of python-dev feedback about memory consumption in the presence of many large dictionaries. At 12 bytes per entry on a 32-bit box, the switchback occurs at 1.2 Mb for a single dict. This ought to allow hundreds of large dictionaries on common memory sizes. Performance improvements vary from application to application and across various hardware setups. So far, typical results are from 0 to 5%. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 20:16 Message: Logged In: YES user_id=6380 Should the other calls to dictresize() also be changed? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 18:23 Message: Logged In: YES user_id=80475 Applied to Objects/dictobject.c 2.145 Closing patch. Thanks to all who contributed, timed, or encouraged. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 16:29 Message: Logged In: YES user_id=6380 I say, check it in, it can't hurt. A comment in the code should explain the considerations though. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 16:21 Message: Logged In: YES user_id=44345 Using Guido's version I saw a consistent improvement in pystone numbers. I ran it five times each with and without the patch. Every "after" run was faster than every "before" run and comparing the fastest run of each showed a 5.4% improvement (13587 vs. 14326.6 pystones). I also ran the pystone benchmark using python -i and then used ps to examine the memory usage after completion. VM and RSS both increased modestly (VM by 0.2%, from 27936 to 27984 and 2.2%, RSS from 3520 to 3600). Not a big deal in my book, but I'm one of those people w/ 1GB of RAM Tim referred to. ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 06:56 Message: Logged In: YES user_id=6380 However note that I cannot reproduce the speedup on Zope 3 startup any more. It may have been something else in my system. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 06:49 Message: Logged In: YES user_id=6380 My preferred version, with code reordering suggested by Tim and further refinement by me (dict2.diff) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 From noreply@sourceforge.net Tue May 6 01:36:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 17:36:59 -0700 Subject: [Patches] [ python-Patches-729395 ] Dictionary tuning Message-ID: Patches item #729395, was opened at 2003-04-29 03:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Dictionary tuning Initial Comment: The idea is to make dictionaries more sparse on average (decreasing the density between 0 and 50%). This results in fewer collisions, faster collision resolution, fewer memory accesses, and better cache performance. A small side-benefit is halving the number of expensive resize operations as the dictionary grows and reducing the cost of the resize operations. The patch helps both smaller sized dictionaries and large ones. It entails a one line change to dictobject.c resulting in a new schedule of dictionary sizes for a given number of entries: Number of Current size Proposed size Filled Entries of dictionary of dictionary -------------- ------------- ------------- 0 to 5 8 8 6 to 10 16 32 11 to 21 32 32 22 to 42 64 128 43 to 85 128 128 86 to 170 256 512 171 to 341 512 512 and so on until 100,000 entries where the old schedule takes over. The 100,000 entry limit was added because of python-dev feedback about memory consumption in the presence of many large dictionaries. At 12 bytes per entry on a 32-bit box, the switchback occurs at 1.2 Mb for a single dict. This ought to allow hundreds of large dictionaries on common memory sizes. Performance improvements vary from application to application and across various hardware setups. So far, typical results are from 0 to 5%. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 19:36 Message: Logged In: YES user_id=80475 Most likely, yes, but I would like a day to think about the use cases and implications before saying for certain. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 19:16 Message: Logged In: YES user_id=6380 Should the other calls to dictresize() also be changed? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 17:23 Message: Logged In: YES user_id=80475 Applied to Objects/dictobject.c 2.145 Closing patch. Thanks to all who contributed, timed, or encouraged. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 15:29 Message: Logged In: YES user_id=6380 I say, check it in, it can't hurt. A comment in the code should explain the considerations though. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 15:21 Message: Logged In: YES user_id=44345 Using Guido's version I saw a consistent improvement in pystone numbers. I ran it five times each with and without the patch. Every "after" run was faster than every "before" run and comparing the fastest run of each showed a 5.4% improvement (13587 vs. 14326.6 pystones). I also ran the pystone benchmark using python -i and then used ps to examine the memory usage after completion. VM and RSS both increased modestly (VM by 0.2%, from 27936 to 27984 and 2.2%, RSS from 3520 to 3600). Not a big deal in my book, but I'm one of those people w/ 1GB of RAM Tim referred to. ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 05:56 Message: Logged In: YES user_id=6380 However note that I cannot reproduce the speedup on Zope 3 startup any more. It may have been something else in my system. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 05:49 Message: Logged In: YES user_id=6380 My preferred version, with code reordering suggested by Tim and further refinement by me (dict2.diff) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 From noreply@sourceforge.net Tue May 6 04:12:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 20:12:57 -0700 Subject: [Patches] [ python-Patches-730594 ] assert from longobject.c, line 1215 Message-ID: Patches item #730594, was opened at 2003-05-01 14:43 Message generated for change (Comment added) made by cjohns You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Chris Johns (cjohns) Assigned to: Tim Peters (tim_one) Summary: assert from longobject.c, line 1215 Initial Comment: RTEMS port running on the Coldfire (m5200) processor. RTEMS is version 4.6.0pre3 and the lastest RTEMS tool set. The target is m68k-rtems. GCC 3.2.2 and GCC 3.2.3 both cause the assert in the file: Objects/longmodule.c:1215 The assert test is in the function 'long_from_binary_base': assert(k < base); The assert and related code is valid, gcc is generating bad code. The bad code is related to the "digit" variable k being a short and the base being an int (32bit on Coldfire). GCC seems to get a little confused about which 16bit half to compare against. The simple fix is to make "k" an int and so be the same size as base. The 'k' variable is an int in the loop just above that figures out the total number of bits needed. This change also generated faster code for the Coldfire. I know a selection of one CPU is not a valid analysis, how-ever base and k being the same seemed to help gcc. ---------------------------------------------------------------------- >Comment By: Chris Johns (cjohns) Date: 2003-05-06 13:12 Message: Logged In: YES user_id=197074 I have tested the lastest cvs. The committed change to longobject.c, revision 1.160 did not generate an assert when loading site.py. This change is fine with me. Thanks for the prompt resolution. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 06:40 Message: Logged In: YES user_id=31435 If you could try current CVS Python, that would be great. I don't mind changing the code here, but if k becomes signed in this loop then I don't want to continue forcing ch to be unsigned in this loop, so I changed more than just the one declaration. I'll leave the patch open until you can find out whether it worms around your gcc problem. Objects/longobject.c; new revision: 1.160 ---------------------------------------------------------------------- Comment By: Chris Johns (cjohns) Date: 2003-05-01 14:51 Message: Logged In: YES user_id=197074 Be a good idea if I read the instructions and checked the patch attached box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470 From noreply@sourceforge.net Tue May 6 04:47:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 20:47:56 -0700 Subject: [Patches] [ python-Patches-730594 ] assert from longobject.c, line 1215 Message-ID: Patches item #730594, was opened at 2003-05-01 00:43 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Chris Johns (cjohns) >Assigned to: Nobody/Anonymous (nobody) Summary: assert from longobject.c, line 1215 Initial Comment: RTEMS port running on the Coldfire (m5200) processor. RTEMS is version 4.6.0pre3 and the lastest RTEMS tool set. The target is m68k-rtems. GCC 3.2.2 and GCC 3.2.3 both cause the assert in the file: Objects/longmodule.c:1215 The assert test is in the function 'long_from_binary_base': assert(k < base); The assert and related code is valid, gcc is generating bad code. The bad code is related to the "digit" variable k being a short and the base being an int (32bit on Coldfire). GCC seems to get a little confused about which 16bit half to compare against. The simple fix is to make "k" an int and so be the same size as base. The 'k' variable is an int in the loop just above that figures out the total number of bits needed. This change also generated faster code for the Coldfire. I know a selection of one CPU is not a valid analysis, how-ever base and k being the same seemed to help gcc. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-05 23:47 Message: Logged In: YES user_id=31435 Thank you for the followup! Marking as Closed. ---------------------------------------------------------------------- Comment By: Chris Johns (cjohns) Date: 2003-05-05 23:12 Message: Logged In: YES user_id=197074 I have tested the lastest cvs. The committed change to longobject.c, revision 1.160 did not generate an assert when loading site.py. This change is fine with me. Thanks for the prompt resolution. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-05 16:40 Message: Logged In: YES user_id=31435 If you could try current CVS Python, that would be great. I don't mind changing the code here, but if k becomes signed in this loop then I don't want to continue forcing ch to be unsigned in this loop, so I changed more than just the one declaration. I'll leave the patch open until you can find out whether it worms around your gcc problem. Objects/longobject.c; new revision: 1.160 ---------------------------------------------------------------------- Comment By: Chris Johns (cjohns) Date: 2003-05-01 00:51 Message: Logged In: YES user_id=197074 Be a good idea if I read the instructions and checked the patch attached box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470 From noreply@sourceforge.net Tue May 6 06:43:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 22:43:48 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 16:09 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-05 22:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 16:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 15:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Tue May 6 07:46:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 23:46:52 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 18:09 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 01:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 00:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 18:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 17:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Tue May 6 08:11:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 00:11:00 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 12:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 02:11 Message: Logged In: YES user_id=80475 I would like to see Thomas's patch or some comformant variant go in. Usability problems are a bug. Friendlier output makes it more likely that unittest will be used in the first place. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 07:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 07:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 07:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 06:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-19 21:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 10:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Tue May 6 08:27:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 00:27:31 -0700 Subject: [Patches] [ python-Patches-725569 ] Improved output for unittest failUnlessEqual Message-ID: Patches item #725569, was opened at 2003-04-22 05:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Duncan Booth (duncanb) Assigned to: Nobody/Anonymous (nobody) Summary: Improved output for unittest failUnlessEqual Initial Comment: The failUnlessEqual method in unittest.TestCase doesn't handle well the case where the objects being compared have a long string representation. The whole repr for each object is printed no matter how long, and no indication is given of where any differences occur. This patch uses difflib on long representations to provide a short output that highlights where the first difference actually is. It also limits the output for each value to fit on a single line (with the differences indicated on the line following). e.g. FAIL: test_failunlessEqual4 (__main__.Test) ---------------------------------------------------------------------- TestFailed: failUnlessEqual {'A': 65, 'C': 67, ...0, 'P ': 0, 'R': 82, 'U': 85, 'T': 84, 'W': 87, 'V': 8... ... ^^ ^ ... {'A': 65, 'C': 67, ...0, 'S': 83, 'R': 82, 'U': 85, 'T': 84, 'W': 87, 'V': 8... ... ^ ^^ ... File "F:\temp\test.py", line 59, in test_failunlessEqual4 self.failUnlessEqual(d2, d1) ---------------------------------------------------------------------- The attached file contains the changes, assuming that patch "722638 Better output for unittest" has already been applied. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 02:27 Message: Logged In: YES user_id=80475 The patch should wrap "import difflib" in a try/except and revert to prior behavior upon an ImportError. This will make sure unittest still runs on old Pythons. ---------------------------------------------------------------------- Comment By: Duncan Booth (duncanb) Date: 2003-04-25 05:35 Message: Logged In: YES user_id=74031 Oops. I forgot to test for the case where the string didn't need shortening in the middle. New patch uploaded. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 05:03 Message: Logged In: YES user_id=11105 There's a bug in your patch: ! else: ! x, y = s[:LINELEN+1], t[:LINELEN+1] ! left = 0 s and t are not defined here (UnboundLocal exception is raised), ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470 From noreply@sourceforge.net Tue May 6 09:03:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 01:03:12 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 16:09 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-06 01:03 Message: Logged In: YES user_id=357491 OK, following Raymond's suggestions, here is revised version of the docs. I tried to be terse and concrete, but it goes against my personal writing style (I used to get marked off for this when my philosophy classes because I refused to write dry papers; still haven't learned my lesson =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 23:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-05 22:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 16:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 15:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Tue May 6 09:38:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 01:38:52 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 18:09 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Brett Cannon (bcannon) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 03:38 Message: Logged In: YES user_id=80475 This is a good looking document. Here are a few nits: --------------------------- line 23: [replace] "traditional" [with] ``traditional'' line 29: [add] \end{seealso} line 61: [replace] True [with] \constant{True} line 68: [replace] True [with] \constant{True} line 72: [replace] True [with] \constant{True} line 109: [consider noting the classes are broken into individual testcases using the rules for MakeSuite. Technically, the class itself is not executed. The test runner scans for methodnames starting with "test" and builds a suite of testcases.] line 190: [replace] bering [with] being line 191: [replace parenthetical with] testing only the published user interface line 215: [replace my error] self.func [with] func line 217: [eliminate my extraneous space before the open parenthesis] line 231: [delete] line 233: [delete] After fixing those, go ahead a load it or assign it to Fred for further review (he does that anyway). Then, add libtest.tex to lib.tex so it will appear in the index and become part of the build. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 03:03 Message: Logged In: YES user_id=357491 OK, following Raymond's suggestions, here is revised version of the docs. I tried to be terse and concrete, but it goes against my personal writing style (I used to get marked off for this when my philosophy classes because I refused to write dry papers; still haven't learned my lesson =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 01:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 00:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 18:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 17:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Tue May 6 10:01:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 02:01:19 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 11:01 Message: Logged In: YES user_id=89016 Checked in as Lib/test/test_uu.py 1.6. OK, I'll open a new patch for the next test script once it's done. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 00:56 Message: Logged In: YES user_id=80475 Yes. It's fine. Hey, I think it's time to start a new patch for future changes. This one is getting huge. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-05 22:48 Message: Logged In: YES user_id=89016 And now for something completely different: test_uu.py ported to PyUnit. Raymond can you check that this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 19:58 Message: Logged In: YES user_id=89016 OK, I've changed the new run_unittest() to call run_suite() with a second argument if exactly one testcase is passed. I hope that's OK. Checked in as: test_StringIO.py 1.16 test___all__.py 1.30 test_base64.py 1.6 test_bisect.py 1.9 test_bool.py 1.12 test_builtin.py 1.19 test_bz2.py 1.14 test_calendar.py 1.5 test_call.py 1.4 test_cfgparser.py 1.20 test_charmapcodec.py 1.7 test_codeccallbacks.py 1.12 test_codecs.py 1.9 test_copy.py 1.8 test_cpickle.py 1.15 test_csv.py 1.6 test_dummy_thread.py 1.4 test_enumerate.py 1.4 test_filecmp.py 1.2 test_getargs2.py 1.5 test_grp.py 1.16 test_hexoct.py 1.4 test_hmac.py 1.7 test_isinstance.py 1.7 test_itertools.py 1.6 test_optparse.py 1.2 test_os.py 1.18 test_parser.py 1.17 test_pep277.py 1.6 test_pickle.py 1.18 test_posix.py 1.6 test_pow.py 1.18 test_profilehooks.py 1.10 test_pwd.py 1.17 test_re.py 1.42 test_richcmp.py 1.9 test_sets.py 1.24 test_shelve.py 1.5 test_shutil.py 1.2 test_socket.py 1.64 test_str.py 1.3 test_string.py 1.25 test_strptime.py 1.13 test_support.py 1.52 test_sys.py 1.7 test_tarfile.py 1.8 test_tempfile.py 1.14 test_textwrap.py 1.19 test_timeout.py 1.14 test_trace.py 1.9 test_ucn.py 1.14 test_unicode.py 1.83 test_unicodedata.py 1.9 test_univnewlines.py 1.5 test_urllib.py 1.13 test_urllibnet.py 1.2 test_userdict.py 1.15 test_userlist.py 1.9 test_userstring.py 1.11 test_weakref.py 1.23 test_xpickle.py 1.4 test_zipimport.py 1.8 test_zlib.py 1.23 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 19:17 Message: Logged In: YES user_id=80475 My preference was to keep run_classtests() as a separate function. The run_unittest() function was unique in that it called run_suite() with two arguments instead of one. That accounts for the additional verbosity you are seeing. While I prefer the separate run_classtests(), it's up to you to do whichever seems best. Otherwise, all looks okay. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 18:54 Message: Logged In: YES user_id=89016 I've changed test_support.run_unittest() to work like your run_classtests() and changed all test scripts to use this. (see diff2.txt) I compared the output of ./python Lib/test/regrtest.py -v 2>&1 | grep -v "Ran.*test.*in" and apart from the fact that test_csv seems to be more verbose now, there seem to be no regression bugs. Raymond, can you check, if this is OK? BTW, there's another check for memory leaks in test_datetime.py. Perhaps it would make sense to combine both and use them globally in regrtest.py (or test_support.py)? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-29 23:39 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_richcmp.py 1.8 Lib/test/output/test_richcmp delete which a few additional tests and comments. I'll probably work on using run_classtests() tomorrow, but wouldn't it be simpler to add the multiple arguments to the already existing function run_unittest() instead of introducing the new run_classtests()? > BTW, why is the int to int comparison labeled as useless? Because it would check whether comparing two ints gives the same result as comparing the same two ints. ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 21:10 Message: Logged In: YES user_id=80475 Yes. test_support.run_classtests() ought to be used everywhere it is applicable. There are a couple of places like test_sets.py where the "suite" variable is used again for other purposed (testing for memory leaks). In those cases, it ought to be left alone until I can write a function that encapsulates the essense of the combined test. test_richcmp.py looks good. Please add comment lines describing the point of classes and tests whose names are not self explanatory (i.e. misbehavin, weird, etc). BTW, why is the int to int comparison labeled as useless? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-28 20:42 Message: Logged In: YES user_id=89016 Here's the next one: test_richcmp.py with a few additional tests to increase code coverage in object.c and listobject.c. BTW, should we change all tests to use the new test_support.run_classtests()? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-25 13:40 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_bool.py 1.9 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 23:00 Message: Logged In: YES user_id=6380 I suggest not to mess with unittest.py; it is still externally maintained as PyUnit. Maybe ask the PyUnit developer. No time to review the test, sorry; if it works, I suggest to just check it in. ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 22:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 13:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-15 01:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 14:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 11:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Tue May 6 12:17:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 04:17:20 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-05 01:09 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 13:17 Message: Logged In: YES user_id=89016 A few other problems: Line 247: "Specifying a single regression", this should show how the call to regrtest looks like. Line 254: "turns enables" -> "enables" Line 257: "common-separated" -> "comma-separated" I think the description of black box testing and white box testing is reversed. (Compare Lib/test/README). Maybe we should combine both texts (libtest.tex and Lib/test/README)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 10:38 Message: Logged In: YES user_id=80475 This is a good looking document. Here are a few nits: --------------------------- line 23: [replace] "traditional" [with] ``traditional'' line 29: [add] \end{seealso} line 61: [replace] True [with] \constant{True} line 68: [replace] True [with] \constant{True} line 72: [replace] True [with] \constant{True} line 109: [consider noting the classes are broken into individual testcases using the rules for MakeSuite. Technically, the class itself is not executed. The test runner scans for methodnames starting with "test" and builds a suite of testcases.] line 190: [replace] bering [with] being line 191: [replace parenthetical with] testing only the published user interface line 215: [replace my error] self.func [with] func line 217: [eliminate my extraneous space before the open parenthesis] line 231: [delete] line 233: [delete] After fixing those, go ahead a load it or assign it to Fred for further review (he does that anyway). Then, add libtest.tex to lib.tex so it will appear in the index and become part of the build. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 10:03 Message: Logged In: YES user_id=357491 OK, following Raymond's suggestions, here is revised version of the docs. I tried to be terse and concrete, but it goes against my personal writing style (I used to get marked off for this when my philosophy classes because I refused to write dry papers; still haven't learned my lesson =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 08:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 07:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 01:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 00:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Tue May 6 13:08:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 05:08:56 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 08:08 Message: Logged In: YES user_id=6380 So maybe close this one? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 05:01 Message: Logged In: YES user_id=89016 Checked in as Lib/test/test_uu.py 1.6. OK, I'll open a new patch for the next test script once it's done. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 18:56 Message: Logged In: YES user_id=80475 Yes. It's fine. Hey, I think it's time to start a new patch for future changes. This one is getting huge. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-05 16:48 Message: Logged In: YES user_id=89016 And now for something completely different: test_uu.py ported to PyUnit. Raymond can you check that this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 13:58 Message: Logged In: YES user_id=89016 OK, I've changed the new run_unittest() to call run_suite() with a second argument if exactly one testcase is passed. I hope that's OK. Checked in as: test_StringIO.py 1.16 test___all__.py 1.30 test_base64.py 1.6 test_bisect.py 1.9 test_bool.py 1.12 test_builtin.py 1.19 test_bz2.py 1.14 test_calendar.py 1.5 test_call.py 1.4 test_cfgparser.py 1.20 test_charmapcodec.py 1.7 test_codeccallbacks.py 1.12 test_codecs.py 1.9 test_copy.py 1.8 test_cpickle.py 1.15 test_csv.py 1.6 test_dummy_thread.py 1.4 test_enumerate.py 1.4 test_filecmp.py 1.2 test_getargs2.py 1.5 test_grp.py 1.16 test_hexoct.py 1.4 test_hmac.py 1.7 test_isinstance.py 1.7 test_itertools.py 1.6 test_optparse.py 1.2 test_os.py 1.18 test_parser.py 1.17 test_pep277.py 1.6 test_pickle.py 1.18 test_posix.py 1.6 test_pow.py 1.18 test_profilehooks.py 1.10 test_pwd.py 1.17 test_re.py 1.42 test_richcmp.py 1.9 test_sets.py 1.24 test_shelve.py 1.5 test_shutil.py 1.2 test_socket.py 1.64 test_str.py 1.3 test_string.py 1.25 test_strptime.py 1.13 test_support.py 1.52 test_sys.py 1.7 test_tarfile.py 1.8 test_tempfile.py 1.14 test_textwrap.py 1.19 test_timeout.py 1.14 test_trace.py 1.9 test_ucn.py 1.14 test_unicode.py 1.83 test_unicodedata.py 1.9 test_univnewlines.py 1.5 test_urllib.py 1.13 test_urllibnet.py 1.2 test_userdict.py 1.15 test_userlist.py 1.9 test_userstring.py 1.11 test_weakref.py 1.23 test_xpickle.py 1.4 test_zipimport.py 1.8 test_zlib.py 1.23 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 13:17 Message: Logged In: YES user_id=80475 My preference was to keep run_classtests() as a separate function. The run_unittest() function was unique in that it called run_suite() with two arguments instead of one. That accounts for the additional verbosity you are seeing. While I prefer the separate run_classtests(), it's up to you to do whichever seems best. Otherwise, all looks okay. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 12:54 Message: Logged In: YES user_id=89016 I've changed test_support.run_unittest() to work like your run_classtests() and changed all test scripts to use this. (see diff2.txt) I compared the output of ./python Lib/test/regrtest.py -v 2>&1 | grep -v "Ran.*test.*in" and apart from the fact that test_csv seems to be more verbose now, there seem to be no regression bugs. Raymond, can you check, if this is OK? BTW, there's another check for memory leaks in test_datetime.py. Perhaps it would make sense to combine both and use them globally in regrtest.py (or test_support.py)? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-29 17:39 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_richcmp.py 1.8 Lib/test/output/test_richcmp delete which a few additional tests and comments. I'll probably work on using run_classtests() tomorrow, but wouldn't it be simpler to add the multiple arguments to the already existing function run_unittest() instead of introducing the new run_classtests()? > BTW, why is the int to int comparison labeled as useless? Because it would check whether comparing two ints gives the same result as comparing the same two ints. ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 15:10 Message: Logged In: YES user_id=80475 Yes. test_support.run_classtests() ought to be used everywhere it is applicable. There are a couple of places like test_sets.py where the "suite" variable is used again for other purposed (testing for memory leaks). In those cases, it ought to be left alone until I can write a function that encapsulates the essense of the combined test. test_richcmp.py looks good. Please add comment lines describing the point of classes and tests whose names are not self explanatory (i.e. misbehavin, weird, etc). BTW, why is the int to int comparison labeled as useless? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-28 14:42 Message: Logged In: YES user_id=89016 Here's the next one: test_richcmp.py with a few additional tests to increase code coverage in object.c and listobject.c. BTW, should we change all tests to use the new test_support.run_classtests()? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-25 07:40 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_bool.py 1.9 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 17:00 Message: Logged In: YES user_id=6380 I suggest not to mess with unittest.py; it is still externally maintained as PyUnit. Maybe ask the PyUnit developer. No time to review the test, sorry; if it works, I suggest to just check it in. ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 16:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 07:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-14 19:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 08:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 05:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 05:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 04:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 14:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 10:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 08:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 12:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 08:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-20 22:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 13:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 04:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 15:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 06:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 03:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 13:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 18:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Tue May 6 14:10:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 06:10:48 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Nobody/Anonymous (nobody) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 15:10 Message: Logged In: YES user_id=89016 Closed the patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 14:08 Message: Logged In: YES user_id=6380 So maybe close this one? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 11:01 Message: Logged In: YES user_id=89016 Checked in as Lib/test/test_uu.py 1.6. OK, I'll open a new patch for the next test script once it's done. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 00:56 Message: Logged In: YES user_id=80475 Yes. It's fine. Hey, I think it's time to start a new patch for future changes. This one is getting huge. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-05 22:48 Message: Logged In: YES user_id=89016 And now for something completely different: test_uu.py ported to PyUnit. Raymond can you check that this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 19:58 Message: Logged In: YES user_id=89016 OK, I've changed the new run_unittest() to call run_suite() with a second argument if exactly one testcase is passed. I hope that's OK. Checked in as: test_StringIO.py 1.16 test___all__.py 1.30 test_base64.py 1.6 test_bisect.py 1.9 test_bool.py 1.12 test_builtin.py 1.19 test_bz2.py 1.14 test_calendar.py 1.5 test_call.py 1.4 test_cfgparser.py 1.20 test_charmapcodec.py 1.7 test_codeccallbacks.py 1.12 test_codecs.py 1.9 test_copy.py 1.8 test_cpickle.py 1.15 test_csv.py 1.6 test_dummy_thread.py 1.4 test_enumerate.py 1.4 test_filecmp.py 1.2 test_getargs2.py 1.5 test_grp.py 1.16 test_hexoct.py 1.4 test_hmac.py 1.7 test_isinstance.py 1.7 test_itertools.py 1.6 test_optparse.py 1.2 test_os.py 1.18 test_parser.py 1.17 test_pep277.py 1.6 test_pickle.py 1.18 test_posix.py 1.6 test_pow.py 1.18 test_profilehooks.py 1.10 test_pwd.py 1.17 test_re.py 1.42 test_richcmp.py 1.9 test_sets.py 1.24 test_shelve.py 1.5 test_shutil.py 1.2 test_socket.py 1.64 test_str.py 1.3 test_string.py 1.25 test_strptime.py 1.13 test_support.py 1.52 test_sys.py 1.7 test_tarfile.py 1.8 test_tempfile.py 1.14 test_textwrap.py 1.19 test_timeout.py 1.14 test_trace.py 1.9 test_ucn.py 1.14 test_unicode.py 1.83 test_unicodedata.py 1.9 test_univnewlines.py 1.5 test_urllib.py 1.13 test_urllibnet.py 1.2 test_userdict.py 1.15 test_userlist.py 1.9 test_userstring.py 1.11 test_weakref.py 1.23 test_xpickle.py 1.4 test_zipimport.py 1.8 test_zlib.py 1.23 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 19:17 Message: Logged In: YES user_id=80475 My preference was to keep run_classtests() as a separate function. The run_unittest() function was unique in that it called run_suite() with two arguments instead of one. That accounts for the additional verbosity you are seeing. While I prefer the separate run_classtests(), it's up to you to do whichever seems best. Otherwise, all looks okay. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 18:54 Message: Logged In: YES user_id=89016 I've changed test_support.run_unittest() to work like your run_classtests() and changed all test scripts to use this. (see diff2.txt) I compared the output of ./python Lib/test/regrtest.py -v 2>&1 | grep -v "Ran.*test.*in" and apart from the fact that test_csv seems to be more verbose now, there seem to be no regression bugs. Raymond, can you check, if this is OK? BTW, there's another check for memory leaks in test_datetime.py. Perhaps it would make sense to combine both and use them globally in regrtest.py (or test_support.py)? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-29 23:39 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_richcmp.py 1.8 Lib/test/output/test_richcmp delete which a few additional tests and comments. I'll probably work on using run_classtests() tomorrow, but wouldn't it be simpler to add the multiple arguments to the already existing function run_unittest() instead of introducing the new run_classtests()? > BTW, why is the int to int comparison labeled as useless? Because it would check whether comparing two ints gives the same result as comparing the same two ints. ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 21:10 Message: Logged In: YES user_id=80475 Yes. test_support.run_classtests() ought to be used everywhere it is applicable. There are a couple of places like test_sets.py where the "suite" variable is used again for other purposed (testing for memory leaks). In those cases, it ought to be left alone until I can write a function that encapsulates the essense of the combined test. test_richcmp.py looks good. Please add comment lines describing the point of classes and tests whose names are not self explanatory (i.e. misbehavin, weird, etc). BTW, why is the int to int comparison labeled as useless? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-28 20:42 Message: Logged In: YES user_id=89016 Here's the next one: test_richcmp.py with a few additional tests to increase code coverage in object.c and listobject.c. BTW, should we change all tests to use the new test_support.run_classtests()? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-25 13:40 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_bool.py 1.9 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 23:00 Message: Logged In: YES user_id=6380 I suggest not to mess with unittest.py; it is still externally maintained as PyUnit. Maybe ask the PyUnit developer. No time to review the test, sorry; if it works, I suggest to just check it in. ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 22:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 13:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-15 01:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 14:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 11:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Tue May 6 20:52:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 12:52:15 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 13:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-06 15:52 Message: Logged In: YES user_id=31435 I'm split. The current output when assertRaises fails is a frequent cause of head-scratching ("what? it's complaining because ValueError got raised? ... no, it's complaining because ValueError wasn't raised? ..."). OTOH, I see no value in trimming the traceback. Now that *could* be because the assertRaises output can be so confusing that we end up using the rest of the traceback to figure out what unittest is trying to tell us in those cases. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 03:11 Message: Logged In: YES user_id=80475 I would like to see Thomas's patch or some comformant variant go in. Usability problems are a bug. Friendlier output makes it more likely that unittest will be used in the first place. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 08:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 08:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 08:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 07:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-19 22:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 11:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Tue May 6 21:26:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 13:26:06 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 16:09 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-06 13:26 Message: Logged In: YES user_id=357491 First, thanks to both Raymond and Walter for looking for this. Second, I fixed everything both of them brought up sans merging Lib/test/ README into the doc as Walter suggested (read below for an explanation on why). Third, I don't want to merge in Lib/test/README since this is meant to replace it. I tried to use it as a guide to make sure everything in there gets covered in here (which is why there is a section on how to write a good regression test). Fourth, I will assign it to Fred but not check it in until he gets a chance to look at it and tells me to check it in. I will thus not touch lib.tex unless Fred tells me to. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 04:17 Message: Logged In: YES user_id=89016 A few other problems: Line 247: "Specifying a single regression", this should show how the call to regrtest looks like. Line 254: "turns enables" -> "enables" Line 257: "common-separated" -> "comma-separated" I think the description of black box testing and white box testing is reversed. (Compare Lib/test/README). Maybe we should combine both texts (libtest.tex and Lib/test/README)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 01:38 Message: Logged In: YES user_id=80475 This is a good looking document. Here are a few nits: --------------------------- line 23: [replace] "traditional" [with] ``traditional'' line 29: [add] \end{seealso} line 61: [replace] True [with] \constant{True} line 68: [replace] True [with] \constant{True} line 72: [replace] True [with] \constant{True} line 109: [consider noting the classes are broken into individual testcases using the rules for MakeSuite. Technically, the class itself is not executed. The test runner scans for methodnames starting with "test" and builds a suite of testcases.] line 190: [replace] bering [with] being line 191: [replace parenthetical with] testing only the published user interface line 215: [replace my error] self.func [with] func line 217: [eliminate my extraneous space before the open parenthesis] line 231: [delete] line 233: [delete] After fixing those, go ahead a load it or assign it to Fred for further review (he does that anyway). Then, add libtest.tex to lib.tex so it will appear in the index and become part of the build. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 01:03 Message: Logged In: YES user_id=357491 OK, following Raymond's suggestions, here is revised version of the docs. I tried to be terse and concrete, but it goes against my personal writing style (I used to get marked off for this when my philosophy classes because I refused to write dry papers; still haven't learned my lesson =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 23:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-05 22:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 16:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 15:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Tue May 6 21:27:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 13:27:38 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 13:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-06 16:27 Message: Logged In: YES user_id=31435 That's why I'm split: I do like the new *messages* better (their content), but I don't like losing the tracebacks. Sometimes it's a bug in the test driver-- or in 20 layers of test driver code --and sometimes it's even a bug in unittest itself. The traceback is a fundamental tool when things go wrong, so I'm never in favor of hiding parts of tracebacks (hiding could be appropriate if you *knew* the true cause isn't in the part you're hiding -- but you can't know that). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-05-06 16:08 Message: Logged In: YES user_id=11105 That's exactly how I was feeling. When an assertRaises test failed, I usually inserted the call it made before this line, to see the real traceback. And that's what this patch tries to fix. I don't want to see tracebacks when a test fails, I want a clear indication that it failed (the patch prints "TestFailed" instead of "Traceback:"). For the output of a failed assertRaises, see the first comment I added. IMO it clearly says what which exception was expected, and which one was raised. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 15:52 Message: Logged In: YES user_id=31435 I'm split. The current output when assertRaises fails is a frequent cause of head-scratching ("what? it's complaining because ValueError got raised? ... no, it's complaining because ValueError wasn't raised? ..."). OTOH, I see no value in trimming the traceback. Now that *could* be because the assertRaises output can be so confusing that we end up using the rest of the traceback to figure out what unittest is trying to tell us in those cases. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 03:11 Message: Logged In: YES user_id=80475 I would like to see Thomas's patch or some comformant variant go in. Usability problems are a bug. Friendlier output makes it more likely that unittest will be used in the first place. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 08:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 08:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 08:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 07:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-19 22:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 11:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Tue May 6 21:08:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 13:08:22 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-05-06 22:08 Message: Logged In: YES user_id=11105 That's exactly how I was feeling. When an assertRaises test failed, I usually inserted the call it made before this line, to see the real traceback. And that's what this patch tries to fix. I don't want to see tracebacks when a test fails, I want a clear indication that it failed (the patch prints "TestFailed" instead of "Traceback:"). For the output of a failed assertRaises, see the first comment I added. IMO it clearly says what which exception was expected, and which one was raised. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 21:52 Message: Logged In: YES user_id=31435 I'm split. The current output when assertRaises fails is a frequent cause of head-scratching ("what? it's complaining because ValueError got raised? ... no, it's complaining because ValueError wasn't raised? ..."). OTOH, I see no value in trimming the traceback. Now that *could* be because the assertRaises output can be so confusing that we end up using the rest of the traceback to figure out what unittest is trying to tell us in those cases. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 09:11 Message: Logged In: YES user_id=80475 I would like to see Thomas's patch or some comformant variant go in. Usability problems are a bug. Friendlier output makes it more likely that unittest will be used in the first place. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 14:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 13:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-20 04:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 17:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Wed May 7 00:46:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 16:46:44 -0700 Subject: [Patches] [ python-Patches-729395 ] Dictionary tuning Message-ID: Patches item #729395, was opened at 2003-04-29 03:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Dictionary tuning Initial Comment: The idea is to make dictionaries more sparse on average (decreasing the density between 0 and 50%). This results in fewer collisions, faster collision resolution, fewer memory accesses, and better cache performance. A small side-benefit is halving the number of expensive resize operations as the dictionary grows and reducing the cost of the resize operations. The patch helps both smaller sized dictionaries and large ones. It entails a one line change to dictobject.c resulting in a new schedule of dictionary sizes for a given number of entries: Number of Current size Proposed size Filled Entries of dictionary of dictionary -------------- ------------- ------------- 0 to 5 8 8 6 to 10 16 32 11 to 21 32 32 22 to 42 64 128 43 to 85 128 128 86 to 170 256 512 171 to 341 512 512 and so on until 100,000 entries where the old schedule takes over. The 100,000 entry limit was added because of python-dev feedback about memory consumption in the presence of many large dictionaries. At 12 bytes per entry on a 32-bit box, the switchback occurs at 1.2 Mb for a single dict. This ought to allow hundreds of large dictionaries on common memory sizes. Performance improvements vary from application to application and across various hardware setups. So far, typical results are from 0 to 5%. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 18:46 Message: Logged In: YES user_id=80475 Yes, in both places, the resize argument of mp- >ma_used*3/2 should be changed to mp->ma_used*2. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 19:36 Message: Logged In: YES user_id=80475 Most likely, yes, but I would like a day to think about the use cases and implications before saying for certain. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 19:16 Message: Logged In: YES user_id=6380 Should the other calls to dictresize() also be changed? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 17:23 Message: Logged In: YES user_id=80475 Applied to Objects/dictobject.c 2.145 Closing patch. Thanks to all who contributed, timed, or encouraged. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 15:29 Message: Logged In: YES user_id=6380 I say, check it in, it can't hurt. A comment in the code should explain the considerations though. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 15:21 Message: Logged In: YES user_id=44345 Using Guido's version I saw a consistent improvement in pystone numbers. I ran it five times each with and without the patch. Every "after" run was faster than every "before" run and comparing the fastest run of each showed a 5.4% improvement (13587 vs. 14326.6 pystones). I also ran the pystone benchmark using python -i and then used ps to examine the memory usage after completion. VM and RSS both increased modestly (VM by 0.2%, from 27936 to 27984 and 2.2%, RSS from 3520 to 3600). Not a big deal in my book, but I'm one of those people w/ 1GB of RAM Tim referred to. ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 05:56 Message: Logged In: YES user_id=6380 However note that I cannot reproduce the speedup on Zope 3 startup any more. It may have been something else in my system. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 05:49 Message: Logged In: YES user_id=6380 My preferred version, with code reordering suggested by Tim and further refinement by me (dict2.diff) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 From noreply@sourceforge.net Wed May 7 01:01:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 17:01:33 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 18:09 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 19:01 Message: Logged In: YES user_id=80475 The previous version got deleted but newer one did not take its place. The upload may have failed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 15:26 Message: Logged In: YES user_id=357491 First, thanks to both Raymond and Walter for looking for this. Second, I fixed everything both of them brought up sans merging Lib/test/ README into the doc as Walter suggested (read below for an explanation on why). Third, I don't want to merge in Lib/test/README since this is meant to replace it. I tried to use it as a guide to make sure everything in there gets covered in here (which is why there is a section on how to write a good regression test). Fourth, I will assign it to Fred but not check it in until he gets a chance to look at it and tells me to check it in. I will thus not touch lib.tex unless Fred tells me to. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 06:17 Message: Logged In: YES user_id=89016 A few other problems: Line 247: "Specifying a single regression", this should show how the call to regrtest looks like. Line 254: "turns enables" -> "enables" Line 257: "common-separated" -> "comma-separated" I think the description of black box testing and white box testing is reversed. (Compare Lib/test/README). Maybe we should combine both texts (libtest.tex and Lib/test/README)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 03:38 Message: Logged In: YES user_id=80475 This is a good looking document. Here are a few nits: --------------------------- line 23: [replace] "traditional" [with] ``traditional'' line 29: [add] \end{seealso} line 61: [replace] True [with] \constant{True} line 68: [replace] True [with] \constant{True} line 72: [replace] True [with] \constant{True} line 109: [consider noting the classes are broken into individual testcases using the rules for MakeSuite. Technically, the class itself is not executed. The test runner scans for methodnames starting with "test" and builds a suite of testcases.] line 190: [replace] bering [with] being line 191: [replace parenthetical with] testing only the published user interface line 215: [replace my error] self.func [with] func line 217: [eliminate my extraneous space before the open parenthesis] line 231: [delete] line 233: [delete] After fixing those, go ahead a load it or assign it to Fred for further review (he does that anyway). Then, add libtest.tex to lib.tex so it will appear in the index and become part of the build. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 03:03 Message: Logged In: YES user_id=357491 OK, following Raymond's suggestions, here is revised version of the docs. I tried to be terse and concrete, but it goes against my personal writing style (I used to get marked off for this when my philosophy classes because I refused to write dry papers; still haven't learned my lesson =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 01:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 00:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 18:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 17:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Wed May 7 01:31:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 17:31:53 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 16:09 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-06 17:31 Message: Logged In: YES user_id=357491 Bah. This has not been my day at all. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 17:01 Message: Logged In: YES user_id=80475 The previous version got deleted but newer one did not take its place. The upload may have failed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 13:26 Message: Logged In: YES user_id=357491 First, thanks to both Raymond and Walter for looking for this. Second, I fixed everything both of them brought up sans merging Lib/test/ README into the doc as Walter suggested (read below for an explanation on why). Third, I don't want to merge in Lib/test/README since this is meant to replace it. I tried to use it as a guide to make sure everything in there gets covered in here (which is why there is a section on how to write a good regression test). Fourth, I will assign it to Fred but not check it in until he gets a chance to look at it and tells me to check it in. I will thus not touch lib.tex unless Fred tells me to. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 04:17 Message: Logged In: YES user_id=89016 A few other problems: Line 247: "Specifying a single regression", this should show how the call to regrtest looks like. Line 254: "turns enables" -> "enables" Line 257: "common-separated" -> "comma-separated" I think the description of black box testing and white box testing is reversed. (Compare Lib/test/README). Maybe we should combine both texts (libtest.tex and Lib/test/README)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 01:38 Message: Logged In: YES user_id=80475 This is a good looking document. Here are a few nits: --------------------------- line 23: [replace] "traditional" [with] ``traditional'' line 29: [add] \end{seealso} line 61: [replace] True [with] \constant{True} line 68: [replace] True [with] \constant{True} line 72: [replace] True [with] \constant{True} line 109: [consider noting the classes are broken into individual testcases using the rules for MakeSuite. Technically, the class itself is not executed. The test runner scans for methodnames starting with "test" and builds a suite of testcases.] line 190: [replace] bering [with] being line 191: [replace parenthetical with] testing only the published user interface line 215: [replace my error] self.func [with] func line 217: [eliminate my extraneous space before the open parenthesis] line 231: [delete] line 233: [delete] After fixing those, go ahead a load it or assign it to Fred for further review (he does that anyway). Then, add libtest.tex to lib.tex so it will appear in the index and become part of the build. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 01:03 Message: Logged In: YES user_id=357491 OK, following Raymond's suggestions, here is revised version of the docs. I tried to be terse and concrete, but it goes against my personal writing style (I used to get marked off for this when my philosophy classes because I refused to write dry papers; still haven't learned my lesson =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 23:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-05 22:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 16:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 15:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Wed May 7 01:39:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 17:39:02 -0700 Subject: [Patches] [ python-Patches-729395 ] Dictionary tuning Message-ID: Patches item #729395, was opened at 2003-04-29 04:03 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Dictionary tuning Initial Comment: The idea is to make dictionaries more sparse on average (decreasing the density between 0 and 50%). This results in fewer collisions, faster collision resolution, fewer memory accesses, and better cache performance. A small side-benefit is halving the number of expensive resize operations as the dictionary grows and reducing the cost of the resize operations. The patch helps both smaller sized dictionaries and large ones. It entails a one line change to dictobject.c resulting in a new schedule of dictionary sizes for a given number of entries: Number of Current size Proposed size Filled Entries of dictionary of dictionary -------------- ------------- ------------- 0 to 5 8 8 6 to 10 16 32 11 to 21 32 32 22 to 42 64 128 43 to 85 128 128 86 to 170 256 512 171 to 341 512 512 and so on until 100,000 entries where the old schedule takes over. The 100,000 entry limit was added because of python-dev feedback about memory consumption in the presence of many large dictionaries. At 12 bytes per entry on a 32-bit box, the switchback occurs at 1.2 Mb for a single dict. This ought to allow hundreds of large dictionaries on common memory sizes. Performance improvements vary from application to application and across various hardware setups. So far, typical results are from 0 to 5%. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 20:39 Message: Logged In: YES user_id=6380 Ok, do it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 19:46 Message: Logged In: YES user_id=80475 Yes, in both places, the resize argument of mp- >ma_used*3/2 should be changed to mp->ma_used*2. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 20:36 Message: Logged In: YES user_id=80475 Most likely, yes, but I would like a day to think about the use cases and implications before saying for certain. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 20:16 Message: Logged In: YES user_id=6380 Should the other calls to dictresize() also be changed? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 18:23 Message: Logged In: YES user_id=80475 Applied to Objects/dictobject.c 2.145 Closing patch. Thanks to all who contributed, timed, or encouraged. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 16:29 Message: Logged In: YES user_id=6380 I say, check it in, it can't hurt. A comment in the code should explain the considerations though. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 16:21 Message: Logged In: YES user_id=44345 Using Guido's version I saw a consistent improvement in pystone numbers. I ran it five times each with and without the patch. Every "after" run was faster than every "before" run and comparing the fastest run of each showed a 5.4% improvement (13587 vs. 14326.6 pystones). I also ran the pystone benchmark using python -i and then used ps to examine the memory usage after completion. VM and RSS both increased modestly (VM by 0.2%, from 27936 to 27984 and 2.2%, RSS from 3520 to 3600). Not a big deal in my book, but I'm one of those people w/ 1GB of RAM Tim referred to. ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 06:56 Message: Logged In: YES user_id=6380 However note that I cannot reproduce the speedup on Zope 3 startup any more. It may have been something else in my system. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-29 06:49 Message: Logged In: YES user_id=6380 My preferred version, with code reordering suggested by Tim and further refinement by me (dict2.diff) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729395&group_id=5470 From noreply@sourceforge.net Wed May 7 15:27:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 07:27:46 -0700 Subject: [Patches] [ python-Patches-733902 ] repr() vs. `` in the tutorial Message-ID: Patches item #733902, was opened at 2003-05-07 09: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=733902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: repr() vs. `` in the tutorial Initial Comment: The attached patch reduces the presence of `` in the tutorial in favor of explicit repr() calls in most instances. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=733902&group_id=5470 From noreply@sourceforge.net Wed May 7 16:17:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 08:17:03 -0700 Subject: [Patches] [ python-Patches-733902 ] repr() vs. `` in the tutorial Message-ID: Patches item #733902, was opened at 2003-05-07 10:27 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=733902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: repr() vs. `` in the tutorial Initial Comment: The attached patch reduces the presence of `` in the tutorial in favor of explicit repr() calls in most instances. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-05-07 11:16 Message: Logged In: YES user_id=3066 Note that one of the examples you modified includes this line: ... repr(x, y, ('spam', 'eggs') This example needs an additional pair of parentheses that were not required by the backtick syntax. Once that's fixed, please commit the patch and close this report. This is a backport candidate for Python 2.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=733902&group_id=5470 From noreply@sourceforge.net Wed May 7 16:21:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 08:21:29 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 19:09 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Brett Cannon (bcannon) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-05-07 11:21 Message: Logged In: YES user_id=3066 Looks like LaTeX to me. This'll be easier to work with once it's in CVS, so go ahead and commit. Thanks! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 20:31 Message: Logged In: YES user_id=357491 Bah. This has not been my day at all. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 20:01 Message: Logged In: YES user_id=80475 The previous version got deleted but newer one did not take its place. The upload may have failed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 16:26 Message: Logged In: YES user_id=357491 First, thanks to both Raymond and Walter for looking for this. Second, I fixed everything both of them brought up sans merging Lib/test/ README into the doc as Walter suggested (read below for an explanation on why). Third, I don't want to merge in Lib/test/README since this is meant to replace it. I tried to use it as a guide to make sure everything in there gets covered in here (which is why there is a section on how to write a good regression test). Fourth, I will assign it to Fred but not check it in until he gets a chance to look at it and tells me to check it in. I will thus not touch lib.tex unless Fred tells me to. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 07:17 Message: Logged In: YES user_id=89016 A few other problems: Line 247: "Specifying a single regression", this should show how the call to regrtest looks like. Line 254: "turns enables" -> "enables" Line 257: "common-separated" -> "comma-separated" I think the description of black box testing and white box testing is reversed. (Compare Lib/test/README). Maybe we should combine both texts (libtest.tex and Lib/test/README)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 04:38 Message: Logged In: YES user_id=80475 This is a good looking document. Here are a few nits: --------------------------- line 23: [replace] "traditional" [with] ``traditional'' line 29: [add] \end{seealso} line 61: [replace] True [with] \constant{True} line 68: [replace] True [with] \constant{True} line 72: [replace] True [with] \constant{True} line 109: [consider noting the classes are broken into individual testcases using the rules for MakeSuite. Technically, the class itself is not executed. The test runner scans for methodnames starting with "test" and builds a suite of testcases.] line 190: [replace] bering [with] being line 191: [replace parenthetical with] testing only the published user interface line 215: [replace my error] self.func [with] func line 217: [eliminate my extraneous space before the open parenthesis] line 231: [delete] line 233: [delete] After fixing those, go ahead a load it or assign it to Fred for further review (he does that anyway). Then, add libtest.tex to lib.tex so it will appear in the index and become part of the build. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 04:03 Message: Logged In: YES user_id=357491 OK, following Raymond's suggestions, here is revised version of the docs. I tried to be terse and concrete, but it goes against my personal writing style (I used to get marked off for this when my philosophy classes because I refused to write dry papers; still haven't learned my lesson =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 02:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 01:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 19:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 18:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Wed May 7 16:30:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 08:30:43 -0700 Subject: [Patches] [ python-Patches-733902 ] repr() vs. `` in the tutorial Message-ID: Patches item #733902, was opened at 2003-05-07 09:27 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=733902&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: repr() vs. `` in the tutorial Initial Comment: The attached patch reduces the presence of `` in the tutorial in favor of explicit repr() calls in most instances. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-07 10:30 Message: Logged In: YES user_id=44345 checked in and backported ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-05-07 10:16 Message: Logged In: YES user_id=3066 Note that one of the examples you modified includes this line: ... repr(x, y, ('spam', 'eggs') This example needs an additional pair of parentheses that were not required by the backtick syntax. Once that's fixed, please commit the patch and close this report. This is a backport candidate for Python 2.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=733902&group_id=5470 From noreply@sourceforge.net Wed May 7 16:38:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 08:38:44 -0700 Subject: [Patches] [ python-Patches-732143 ] exit status of latex2html "ignored" Message-ID: Patches item #732143, was opened at 2003-05-04 07:29 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732143&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Matthias Klose (doko) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: exit status of latex2html "ignored" Initial Comment: latex2html discovered an error building the lib html docs. It correctly prints: *** Session transcript and error messages are in /build/packages/python2.3/python2.3-2.2.102/Doc/html/lib/lib.how. *** Exited with status 25. The relevant lines from the transcript are: [...] but then exits with an exit status of 1, which lets make continue and makes it harder to find the actual error. Not sure, if this is the correct fix, but why not exit with the error you show the user? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732143&group_id=5470 From noreply@sourceforge.net Wed May 7 19:45:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 11:45:29 -0700 Subject: [Patches] [ python-Patches-734118 ] Threaded Python prevents meeting frame rate targets Message-ID: Patches item #734118, was opened at 2003-05-07 11:45 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=734118&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: Threaded Python prevents meeting frame rate targets Initial Comment: The diffs were made against the CVS version 1.157 of Python/Modules/_tkinter.c. We are using similar diffs with Python 2.2.2. The problem is with the busy-wait interval in _tkinter.c. Our application wants to output at a 30hz frame rate, but with a threaded Python, the frame rates are a multiple of the 20 millisecond Sleep call, so on a really fast machine either 50hz or 25h (47hz and 23hz on my system). Enclosed is a Python test program that demonstrates the limitation. If you install a patched version of _tkinter.c, the program will get the right frame rate. - Greg Couch aftertest.py: ------------ # # Repeatedly register a Tcl "after" callback to see how many calls # per second are made with various delay times. # start_time = None count = 0 delay_ms = 33 # milliseconds def after_cb(): f.after(delay_ms, after_cb) global count, start_time import time t = time.time() if start_time == None: start_time = t count = 0 return count = count + 1 elapsed_time = float(t - start_time) if elapsed_time >= 1: r = count / elapsed_time print 'After calls per second: %.1f' % r start_time = t count = 0 import Tkinter if hasattr(Tkinter._tkinter, "setbusywaitinterval"): Tkinter._tkinter.setbusywaitinterval(0) f = Tkinter.Frame() f.after(delay_ms, after_cb) f.mainloop() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734118&group_id=5470 From noreply@sourceforge.net Wed May 7 21:11:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 13:11:52 -0700 Subject: [Patches] [ python-Patches-734176 ] Make Tkinter.py's nametowidget work with cloned menu widgets Message-ID: Patches item #734176, was opened at 2003-05-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=734176&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: Make Tkinter.py's nametowidget work with cloned menu widgets Initial Comment: Tk will clone menu widgets when they are torn off and it gives them names at are similar to the original widget's names. The patch extends the nametowidget so it will return the original widget when given the name of a cloned widget. We used this patch to provide balloon help in cloned menus. This patch isn't perfect, it will fail on clones of clones, but it is a big help. This patch was made against the latest CVS version 1.173 of Tkinter.py but works against older Tkinter.py's too. - Greg Couch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734176&group_id=5470 From noreply@sourceforge.net Wed May 7 22:27:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 14:27:59 -0700 Subject: [Patches] [ python-Patches-734231 ] Support for RISC OS Message-ID: Patches item #734231, was opened at 2003-05-07 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=734231&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) Assigned to: Nobody/Anonymous (nobody) Summary: Support for RISC OS Initial Comment: Support for RISC OS platform with Python 2.3. Some IP6 related #ifdefs in socket.c for non IP6 platforms. Patches are relative to 2.3b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734231&group_id=5470 From noreply@sourceforge.net Wed May 7 22:35:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 14:35:40 -0700 Subject: [Patches] [ python-Patches-734231 ] Support for RISC OS Message-ID: Patches item #734231, was opened at 2003-05-07 23:27 Message generated for change (Comment added) made by dschwertberger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734231&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) Assigned to: Nobody/Anonymous (nobody) Summary: Support for RISC OS Initial Comment: Support for RISC OS platform with Python 2.3. Some IP6 related #ifdefs in socket.c for non IP6 platforms. Patches are relative to 2.3b1. ---------------------------------------------------------------------- >Comment By: Dietmar Schwertberger (dschwertberger) Date: 2003-05-07 23:35 Message: Logged In: YES user_id=86612 File upload didn't work with my browser. Patches are available from http://www.schwertberger.de/RISCOSpatches.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734231&group_id=5470 From noreply@sourceforge.net Wed May 7 23:02:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 15:02:58 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 16:09 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-07 15:02 Message: Logged In: YES user_id=357491 Both are checked in. Want me to leave this patch open to remind you to take a look, Fred? Or should I go ahead and close it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-05-07 08:21 Message: Logged In: YES user_id=3066 Looks like LaTeX to me. This'll be easier to work with once it's in CVS, so go ahead and commit. Thanks! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 17:31 Message: Logged In: YES user_id=357491 Bah. This has not been my day at all. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 17:01 Message: Logged In: YES user_id=80475 The previous version got deleted but newer one did not take its place. The upload may have failed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 13:26 Message: Logged In: YES user_id=357491 First, thanks to both Raymond and Walter for looking for this. Second, I fixed everything both of them brought up sans merging Lib/test/ README into the doc as Walter suggested (read below for an explanation on why). Third, I don't want to merge in Lib/test/README since this is meant to replace it. I tried to use it as a guide to make sure everything in there gets covered in here (which is why there is a section on how to write a good regression test). Fourth, I will assign it to Fred but not check it in until he gets a chance to look at it and tells me to check it in. I will thus not touch lib.tex unless Fred tells me to. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 04:17 Message: Logged In: YES user_id=89016 A few other problems: Line 247: "Specifying a single regression", this should show how the call to regrtest looks like. Line 254: "turns enables" -> "enables" Line 257: "common-separated" -> "comma-separated" I think the description of black box testing and white box testing is reversed. (Compare Lib/test/README). Maybe we should combine both texts (libtest.tex and Lib/test/README)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 01:38 Message: Logged In: YES user_id=80475 This is a good looking document. Here are a few nits: --------------------------- line 23: [replace] "traditional" [with] ``traditional'' line 29: [add] \end{seealso} line 61: [replace] True [with] \constant{True} line 68: [replace] True [with] \constant{True} line 72: [replace] True [with] \constant{True} line 109: [consider noting the classes are broken into individual testcases using the rules for MakeSuite. Technically, the class itself is not executed. The test runner scans for methodnames starting with "test" and builds a suite of testcases.] line 190: [replace] bering [with] being line 191: [replace parenthetical with] testing only the published user interface line 215: [replace my error] self.func [with] func line 217: [eliminate my extraneous space before the open parenthesis] line 231: [delete] line 233: [delete] After fixing those, go ahead a load it or assign it to Fred for further review (he does that anyway). Then, add libtest.tex to lib.tex so it will appear in the index and become part of the build. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 01:03 Message: Logged In: YES user_id=357491 OK, following Raymond's suggestions, here is revised version of the docs. I tried to be terse and concrete, but it goes against my personal writing style (I used to get marked off for this when my philosophy classes because I refused to write dry papers; still haven't learned my lesson =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 23:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-05 22:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 16:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 15:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Wed May 7 23:07:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 15:07:15 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 19:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 18:07 Message: Logged In: YES user_id=33168 Doesn't doc/Makefile.deps need to be updated too? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-07 18:02 Message: Logged In: YES user_id=357491 Both are checked in. Want me to leave this patch open to remind you to take a look, Fred? Or should I go ahead and close it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-05-07 11:21 Message: Logged In: YES user_id=3066 Looks like LaTeX to me. This'll be easier to work with once it's in CVS, so go ahead and commit. Thanks! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 20:31 Message: Logged In: YES user_id=357491 Bah. This has not been my day at all. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 20:01 Message: Logged In: YES user_id=80475 The previous version got deleted but newer one did not take its place. The upload may have failed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 16:26 Message: Logged In: YES user_id=357491 First, thanks to both Raymond and Walter for looking for this. Second, I fixed everything both of them brought up sans merging Lib/test/ README into the doc as Walter suggested (read below for an explanation on why). Third, I don't want to merge in Lib/test/README since this is meant to replace it. I tried to use it as a guide to make sure everything in there gets covered in here (which is why there is a section on how to write a good regression test). Fourth, I will assign it to Fred but not check it in until he gets a chance to look at it and tells me to check it in. I will thus not touch lib.tex unless Fred tells me to. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 07:17 Message: Logged In: YES user_id=89016 A few other problems: Line 247: "Specifying a single regression", this should show how the call to regrtest looks like. Line 254: "turns enables" -> "enables" Line 257: "common-separated" -> "comma-separated" I think the description of black box testing and white box testing is reversed. (Compare Lib/test/README). Maybe we should combine both texts (libtest.tex and Lib/test/README)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 04:38 Message: Logged In: YES user_id=80475 This is a good looking document. Here are a few nits: --------------------------- line 23: [replace] "traditional" [with] ``traditional'' line 29: [add] \end{seealso} line 61: [replace] True [with] \constant{True} line 68: [replace] True [with] \constant{True} line 72: [replace] True [with] \constant{True} line 109: [consider noting the classes are broken into individual testcases using the rules for MakeSuite. Technically, the class itself is not executed. The test runner scans for methodnames starting with "test" and builds a suite of testcases.] line 190: [replace] bering [with] being line 191: [replace parenthetical with] testing only the published user interface line 215: [replace my error] self.func [with] func line 217: [eliminate my extraneous space before the open parenthesis] line 231: [delete] line 233: [delete] After fixing those, go ahead a load it or assign it to Fred for further review (he does that anyway). Then, add libtest.tex to lib.tex so it will appear in the index and become part of the build. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 04:03 Message: Logged In: YES user_id=357491 OK, following Raymond's suggestions, here is revised version of the docs. I tried to be terse and concrete, but it goes against my personal writing style (I used to get marked off for this when my philosophy classes because I refused to write dry papers; still haven't learned my lesson =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 02:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 01:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 19:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 18:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Thu May 8 03:14:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 19:14:08 -0700 Subject: [Patches] [ python-Patches-598163 ] textwrap.dedent, inspect.getdoc-ish Message-ID: Patches item #598163, was opened at 2002-08-21 05:39 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=598163&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ville Vainio (vvainio) Assigned to: Greg Ward (gward) Summary: textwrap.dedent, inspect.getdoc-ish Initial Comment: Ability to remove indentation from multiline strings (often triple-quoted). Differs from inspect.getdoc by not handling the first line in special manner (often a sensible approach for non-docstring multiline strings) - which should make this function more general (symmetric 'indent' also possible), and more fitting for the textwrap module. Implementation is for the most parts familiar from inspect.getdoc, though I used sring methods instead of the module 'string'. The module 'textwrap' and the function name 'dedent' were suggested on python-dev a while back (by MAL, IIRC). ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2003-05-07 22:14 Message: Logged In: YES user_id=14422 OK, patch accepted and checked in: rev 1.28 of Lib/textwrap.py rev 1.5 of Doc/lib/libtextwrap.tex Tested in rev 1.22 of Lib/test/test_textwrap.py. ---------------------------------------------------------------------- Comment By: Ville Vainio (vvainio) Date: 2002-10-02 02:39 Message: Logged In: YES user_id=213488 Ok, I've added a patch for libtextwrap.tex. You might want to take a look at it for errors, this was my first time writing latex - I just followed the style used elsewhere in the file. Writing the test case might be handled by you in a more time-efficient manner, though I can also take a look at it once I get that linux partition going on my new home machine... ---------------------------------------------------------------------- Comment By: Ville Vainio (vvainio) Date: 2002-09-09 05:40 Message: Logged In: YES user_id=213488 Yes, I'll look into the patches for Doc and test - it just might take a short while (have to access anon cvs at work) - few weeks or so. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-09-04 09:43 Message: Logged In: YES user_id=14422 Looks fine to me. Can you provide a patch for Doc/lib/libtextwrap.tex as well? A patch to Lib/test/test_textwrap.py would be nice too, but I can take care of that if you prefer. (Any other diffs should just be uploaded to this patch report.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:57 Message: Logged In: YES user_id=6380 For Greg Ward. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=598163&group_id=5470 From noreply@sourceforge.net Fri May 9 00:47:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 16:47:25 -0700 Subject: [Patches] [ python-Patches-731607 ] make threading join() method return a value Message-ID: Patches item #731607, was opened at 2003-05-02 14:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: make threading join() method return a value Initial Comment: This patch makes the join() method of a threading module Thread return the value that was returned by the callable that is running in the thread. It came about because I needed to split a process into a number of threads, join them all, and then check what each of them returned before proceeding. It against the current CVS tree, tested on Linux. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-08 16:47 Message: Logged In: YES user_id=357491 If no one else speaks up on this patch by May 15 I am going to close it and reject it. ---------------------------------------------------------------------- Comment By: Matthew Boedicker (mboedick) Date: 2003-05-04 20:23 Message: Logged In: YES user_id=119895 I wasn't subclassing Thread, just instantiating it and passing in a target. I didn't think of writing a wrapper, but that would work for me. I still think having join() return something that might be useful in some circumstances is better than having it return something which is always useless (None), and easier than dealing with Queues or wrappers. Anyway, thanks for feedback. I'll probably use the wrapper approach for now. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-04 17:22 Message: Logged In: YES user_id=357491 But don't you have the requirement that the code know that it is running in a thread when you made your subclass of threading.thread? And even if you didn't, why can't you just wrap the code to catch the return value and push it into the queue in a threading class? I am not going to reject this patch, Matthew, until someone else with commit privs comes in and says they don't like the patch either, so no need to worry... yet. =) ---------------------------------------------------------------------- Comment By: Matthew Boedicker (mboedick) Date: 2003-05-04 17:03 Message: Logged In: YES user_id=119895 The problem with using a Queue is that it requires whatever is running in the thread to be aware it is running in a thread. It would force non-threaded programs using that method to deal with Queues. With the patch, there would be a standard, intuitive way to return data to the caller that worked whether the method was running in a separate thread or not. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-02 14:35 Message: Logged In: YES user_id=357491 I don't think this is truly necessary. If you needed to know what they would return just insert it into a Queue and when the 'join' calls finish check the Queue to see what was added. It also deviates from Java's threading setup which 'threading' is based on. I'm -1 on this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 From noreply@sourceforge.net Fri May 9 00:56:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 16:56:27 -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: Open Resolution: None 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-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 Fri May 9 01:20:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 17:20:38 -0700 Subject: [Patches] [ python-Patches-727789 ] Editing of __str__ and __repr__ docs Message-ID: Patches item #727789, was opened at 2003-04-25 15:25 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727789&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: Editing of __str__ and __repr__ docs Initial Comment: A recent thread in comp.lang.python [1] suggests that there is some question whether the existing docs for the __str__ and __repr__ methods is clear, and whether what it says is good in the first place. The patch shows proposed changes based on the discussions in that thread. The new text treats __repr__ as a programmer-centric stringification (with eval(repr(x)) == x as a possibility, rather than a principle), and __str__ as a more general-purpose stringification-as-appropriate- to-the-object. [1] http://groups.google.com/groups?th=24b817d49ec3a59b ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-08 17:20 Message: Logged In: YES user_id=357491 I agree with Raymond that it seems "wordy". For instance, the first changed paragraph is basically just trying to say "__repr__ should return something that can be past to 'eval' to return return the same object. If this is not possible then make its output useful to the programmer." Don't need to go on about it needing to be a "valid Python expression" and such. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 21:52 Message: Logged In: YES user_id=80475 The patch looks technically correct. It is wordy and I liked the original better, but clarity is more important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727789&group_id=5470 From noreply@sourceforge.net Fri May 9 01:30:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 17:30:25 -0700 Subject: [Patches] [ python-Patches-463656 ] setup.py, --with-includepath, and LD_LIB Message-ID: Patches item #463656, was opened at 2001-09-21 12:12 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py, --with-includepath, and LD_LIB Initial Comment: This patch improves the module detection capability in setup.py. The following improvements are implemented: - directories listed in LD_LIBRARY_PATH are also searched for shared libraries. - the --with-includepath option has been added to configure, to specify additional non-standard directories where the include files are to be searched for. The corresponding changes were added to setup.py (new function detect_include(), find_library_file() augmented, detect_tkinter() improved) I retroceeded manually the changes from configure into configure.in, but I did not run autoconf; you might want to double-check this. Sample aplication: ./configure --prefix=/something --with-includepath='/mgl/apps/include:/mgl/share/include' With this patch, I get Tkinter to build correctly without editing the Setup files, with non-standard tckl/tk 8.0 to 8.3 installations. where the only tcl.h file is in /mgl/share/include/tcl8.0 (therefore, tkinter is build with tcl8.0 on this configuration). FG ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-08 17:30 Message: Logged In: YES user_id=357491 Is that last response a "yes" or a "no"? =) Any of the distutils guys think we should apply this patch or can we finally close this (it was opened over a 1.5 years ago)? ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2002-08-17 12:24 Message: Logged In: YES user_id=93657 On one hand, using -I and -L from setup.py would simplify the setup.py code, but on the other hand, in the present build system, this will require coding in configure.in some of what we can write in python in setup.py (e.g. the use of LD_SHARED_LIBRARY by default). I know we get the eternal story (I already hear it every day with Perl, awk, and various forms of platform-dependent shell scripting), that autoconf is a great and well-known programming language which everybody uses, and why should we do in Python what we can already do in autoconf, and so on... I wish I could put a smiley on this, but I stopped laughing at this things, since I meet them endlessly. Regards, FG ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-14 07:56 Message: Logged In: YES user_id=21627 Frederic, do you still think there is a need for this patch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-17 09:58 Message: Logged In: YES user_id=6656 You do know that you can pass -I and -L options to setup.py? That might be a less involved way of doing what you want. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-27 17:17 Message: Logged In: YES user_id=93657 I moved the functions find_library_file() and detect_include() to distutils.sysconfig(), so that they can be reused for configuring third party modules too (e.g.: PyOpenGL...). Let me know if you wish a patch for this. Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-26 15:56 Message: Logged In: YES user_id=93657 I'm replacing the patch with an improved version (against main line as of 09/26/01). New features: - configure is generated from configure.in, with autoconf - detect_tkinter also checks the version number inside the tcl.h and tk.h files (#define TCL_VERSION, #define TK_VERSION...). The 'tk_detect' improvement is in this same patch as the '--include-patch' feature; since the second one was written to get the first one working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 From noreply@sourceforge.net Fri May 9 01:46:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 17:46:00 -0700 Subject: [Patches] [ python-Patches-658316 ] skips.txt for regrtest.py Message-ID: Patches item #658316, was opened at 2002-12-24 12:03 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658316&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: skips.txt for regrtest.py Initial Comment: As I promised on python-dev here is the functionality to have a skips.txt file for regrtest.py. If the file is present in the current directory it is parsed (using the exact same code as used for the -f option for regrtest; good, old copy-n-paste) and all tests are added to the expected skip set. And as commented in the file, the name of the file is so named after Skip Montanaro because he is too shy. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-08 17:46 Message: Logged In: YES user_id=357491 OK, I am uploading a new patch but now it prints out if a test was not executed and then listed all the tests not executed. This is for several reasons. One is so you don't forget you have a skips.txt file and what tests are in it. You also don't get any possible confusion on why the test was not listed while the tests are being executed or if it was printed that it was actually run and passed. I also factored out the file parsing code used by the -f option to the function parsefile and use it for both -f and for parsing skips.txt . Can someone please just take a quick look and tell me that the "not executed" statements are reasonable? If someone gives me the all-clear I will apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-23 15:27 Message: Logged In: YES user_id=357491 =) Sure thing. Noticed it was assigned to me and everything. Just need to add one feature; I want it to print out what tests were specifically skipped because of the skips.txt file so people don't forget that they have tests being skipped because of what they have in the file. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 11:33 Message: Logged In: YES user_id=80475 It is time to exercise your new commit priviledges. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 13:15 Message: Logged In: YES user_id=21627 Raymond, any further comments? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-12-29 17:37 Message: Logged In: YES user_id=357491 Oops. =) New diff includes a paragraph at the end of the module documentation that mentions how to use the new functionality. Please delete the old diff. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-28 21:09 Message: Logged In: YES user_id=80475 The patch looks good. Now, it needs documentation. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-12-26 13:04 Message: Logged In: YES user_id=357491 Sorry about that! I could have sworn I checked the box. I have uploaded enough files here you would think it would be habitual by now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 10:10 Message: Logged In: YES user_id=33168 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=658316&group_id=5470 From noreply@sourceforge.net Fri May 9 02:09:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 18:09:55 -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-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 Fri May 9 02:32:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 18:32:34 -0700 Subject: [Patches] [ python-Patches-639139 ] Remove type-check from urllib2 Message-ID: Patches item #639139, was opened at 2002-11-15 14:25 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&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: Remove type-check from urllib2 Initial Comment: Remove undesirable type-checking assertion from urllib2.Request. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-08 18:32 Message: Logged In: YES user_id=357491 It's not so much that the dummy attribute would break anything so much as it is just unneeded. If you want to make sure an object is not going to meet your required API you either just follow EAFP (Easier to Ask Forgiveness than Permission) or you explicitly test for the required interface. There is no good argument to have to flag an object to say that it meets an API spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 13:21 Message: Logged In: YES user_id=261020 Why not a new attribute? What would it break? Checking for the interface by checking all the methods (there are maybe ten of them) is not really practical, and really it's the intent that's the important bit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:57 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:55 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 06:46 Message: Logged In: YES user_id=261020 It's widely regarded as a bug if Python code checks for type with isinstance (or type(foo) == type(bar)) without some good reason. It's plausible that you may want to make an object that implements the Request interface without deriving from Request (say, I don't know, to implement the frobozz URI scheme, which requires ordered headers, and never has any data associated with it). If so, you don't want to have to follow 'bug fixes' in the Python std. library that may break your code simply because you had to derive from Request to satisfy the assertion. I might have done this when I wrote a couple of modules that build on urllib2, actually. I'm not sure whether that would have been the best way, because I didn't think about it since I didn't have any choice in the matter, thanks to this assertion! OTOH, it's true that removing type-checks can break backwards compatibility. However, this is an assertion, not a real runtime type-check, so it won't break backwards compatibility: if people are relying on catching AssertionError to do type-checking in their own code, that's their problem! The docs say: urlopen(url[, data]) Open the URL url, which can be either a string or a Request object (currently the code checks that it really is a Request instance, or an instance of a subclass of Request). Note the 'currently' (and the source code comment indicating that what we really want to check is the interface), and that fact that the code *doesn't* actually check it, but only asserts. Request interface is already documented, so there's no problem there. John ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 15:14 Message: Logged In: YES user_id=33168 John, could you explain why you need it and what is the benefit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 From noreply@sourceforge.net Fri May 9 02:38:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 18:38:23 -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: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) 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-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 Fri May 9 03:32:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 19:32:41 -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-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 Fri May 9 04:04:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 20:04:53 -0700 Subject: [Patches] [ python-Patches-731701 ] SpawnedGenerator class for threading module Message-ID: Patches item #731701, was opened at 2003-05-02 22:38 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731701&group_id=5470 Category: Modules Group: None Status: Open Resolution: None 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: Tim Peters (tim_one) Date: 2003-05-08 23: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 19: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 Fri May 9 04:43:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 20:43:37 -0700 Subject: [Patches] [ python-Patches-731701 ] SpawnedGenerator class for threading module Message-ID: Patches item #731701, was opened at 2003-05-02 20:38 Message generated for change (Comment added) made by laotzu0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731701&group_id=5470 Category: Modules Group: None Status: Open Resolution: None 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: Mathieu Fenniak (laotzu0) Date: 2003-05-08 21: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 21: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 17: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 Fri May 9 04:53:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 20:53:07 -0700 Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor Message-ID: Patches item #608182, was opened at 2002-09-11 23:45 Message generated for change (Comment added) made by tim_one 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: Tim Peters (tim_one) Date: 2003-05-08 23: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 22: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 21: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 15:12 Message: Logged In: YES user_id=25129 Didn't make it into 2.3alpha? ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-12 14: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 02: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 01: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-12 00: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 23: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 Fri May 9 07:28:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 23:28:13 -0700 Subject: [Patches] [ python-Patches-735051 ] time.tzset documentation Message-ID: Patches item #735051, was opened at 2003-05-09 16: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=735051&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735051&group_id=5470 From noreply@sourceforge.net Fri May 9 08:19:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 00:19:50 -0700 Subject: [Patches] [ python-Patches-732284 ] UnixWare 7 build patch Message-ID: Patches item #732284, was opened at 2003-05-04 20:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7 build patch Initial Comment: Here is a patch to fix the build on UnixWare 7 & OpenUNIX 8 without taking the simple route of define_xopen_source=no. This patch depends on patches 731191 and 732234 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 09:19 Message: Logged In: YES user_id=21627 Assuming it all works now fine, I'm closing this patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 07:15 Message: Logged In: YES user_id=21627 I have now disabled _XOPEN_SOURCE in configure 1.396 configure.in 1.407 I have used the information provided in 731991, and assumed that the patch is necessary for UnixWare 7.1.[123], where 7.1.2 identifies itself as OpenUNIX 8.0. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 06:58 Message: Logged In: YES user_id=21627 When I asked "is there no way to get these types", I didn't expect that the answer would be "sure, Python can define them itself". By that approach, you wouldn't need any system headers, but could include any declaration literally in Python, with #ifdef UW7. This is clearly not the right solution: I meant to ask "is there no way to get these types *from the system headers*" If the answer to that question is "no", then I'm still curious what the answer to the question "Why *specifically* do we need u_int in the first place?" is. By "specifically", I mean what *specific* other declaration from the system headers relies on it, saying that sys/socket.h needs it is too general. I'm willing to go with the simple patch, provided it is changed in the following way: 1. A comment is added indicating what the specific reason for this patch is. 2. The system check is strengthened to not include future system releases. I.e. saying OpenUNIX/8.*|UnixWare/7.* is too generic: include a list of minor system releases so far. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 23:59 Message: Logged In: YES user_id=618097 If I define _POSIX_SOURCE the data types are available but I get a whole new set of errors in posixmodule.c .... cc -Kthread -K pentium,host,inline,loop_unroll,alloca -DNDEBUG -O -I. -I/opt/src/utils/python/python/dist/src/Include -DPy_BUILD_CORE -c /opt/src/utils/python/python/dist/src/Modules/posixmodule.c -o Modules/posixmodule.o UX:acomp: ERROR: "/usr/include/sys/wait.h", line 141: Syntax error before or at: siginfo_t UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 874: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 875: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 876: improper member use: tv_nsec gmake: *** [Modules/posixmodule.o] Error 1 .... I'm attaching a new patch that has the data type checks from patch 731991. With this patch (which still depends on patches 731991 & 732234) UnixWare 7 builds. It's kind of ugly and I don't like it much. The simple alternative is to use this patch -------------------------- --- configure.in.old 2003-04-17 13:16:42.000000000 -0700 +++ configure.in 2003-04-22 15:26:13.450080095 -0700 @@ -124,6 +124,8 @@ # of union __?sigval. Reported by Stuart Bishop. SunOS/5.6) define_xopen_source=no;; + OpenUNIX/8.* | UnixWare/7.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes -------------------------- ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 22:09 Message: Logged In: YES user_id=618097 There may be a way Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:15 Message: Logged In: YES user_id=21627 Is there absolutely no way to get to these types when _XOPEN_SOURCE is defined? Not by including some obscure header file? Not by defining some obscure macro? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 From noreply@sourceforge.net Fri May 9 08:57:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 00:57:04 -0700 Subject: [Patches] [ python-Patches-604210 ] release GIL around getaddrinfo() Message-ID: Patches item #604210, was opened at 2002-09-03 23:48 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: release GIL around getaddrinfo() Initial Comment: If getaddrinfo() is thread-safe, then we should release the interpreter lock before calling it. There is every reason to believe that this operation will be slow. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-09 09:57 Message: Logged In: YES user_id=92689 The last patch from python.org/sf/731644 was accepted by MvL, and consequently checked in as socketmodule.c rev. 1.265. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 20:07 Message: Logged In: YES user_id=92689 FWIW, I opened a bug regarding this very same issue (I didn't know if this item): python.org/sf/731644. That item now also contains a new patch that takes care of locking. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-05 10:38 Message: Logged In: YES user_id=21627 RFC 2553 specifies that getaddrinfo, getipnodebyname, and all the other new netdb functions must be thread-safe - hence the BSD man pages document it as a bug that they are not. So adding an additional lock, in general, might be overkill. I'd suggest a strategy that assumes, in general, that getaddrinfo is thread-safe. If it isn't (by hard-coded knowledge), I'd propose just to continue using the interpreter lock - those systems deserve to lose. As for the fallback implementation - feel free to do anything about it that you can find the time for. Recording it as thread-unsafe might be fine, adding a lock is another option, using the thread-safe API inside the fallback (where available) is a third option. I would not care too much, except that this is used on Windows. Notice that it won't be used on Windows if Python is compiled with VC.NET, since that provides a "native" getaddrinfo (and Python knows that it does). So if Python 2.3 is going to be compiled with VC.NET, I would not worry about the fallback implementation at all. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-04 22:18 Message: Logged In: YES user_id=33168 I looked on OpenBSD (I think, may have been NetBSD) and FreeBSD. The man pages were the same, both old (circa 1995), but they said their implementation was not thread-safe. I did a man on Dec UNIX and it said it conformed to POSIX.1g Draft 6.6, but didn't indicate if it was thread safe. Solaris 8 doesn't say anything in the man page. Here's a NetBSD 1.6 man page dated 2002/05/14 and it's still not thread-safe: http://216.239.37.100/search?q=cache:4bTvQQqcwq4C:www.tac.eu.org/cgi-bin/man-cgi%3Fgetaddrinfo%2B3+getaddrinfo+thread+safe&hl=en&ie=UTF-8 This: http://216.239.33.100/search?q=cache:q5egqJ5_mv4C:mail.gnu.org/pipermail/guile-devel/2001-October/004039.html+getaddrinfo+thread+safe&hl=en&ie=UTF-8 says "getaddrinfo and getnameinfo are the recommended APIs. They avoid hidden static data; they're supposed to be thread-safe; they handle multiple address families." It seems safest to do what Jeremy proposes and add a lock. There can always be a define if getaddrinfo is thread safe or not. Maybe we can even determine with autoconf. Note: I get much better performance with this patch under linux. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-04 21:20 Message: Logged In: YES user_id=31392 The getaddrinfo() on Linux says it thread-safe. It's a name-fangled call. Is it part of some standard? It would certainly be possible to make the fallback implementation thread-safe. Or, if we don't believe it is thread-safe, we could add a separate lock to protect it. The socket module of 2.1 vintage had a separate lock for this purpose. And the 2.1 vintage Python performs much better when a multi-threaded app does DNS lookups. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 08:25 Message: Logged In: YES user_id=21627 How do you know getaddrinfo is thread-safe? In particular, when using the getaddrinfo emulation, it is not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 From noreply@sourceforge.net Fri May 9 09:06:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 01:06:51 -0700 Subject: [Patches] [ python-Patches-734231 ] Support for RISC OS Message-ID: Patches item #734231, was opened at 2003-05-07 23:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734231&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) Assigned to: Nobody/Anonymous (nobody) Summary: Support for RISC OS Initial Comment: Support for RISC OS platform with Python 2.3. Some IP6 related #ifdefs in socket.c for non IP6 platforms. Patches are relative to 2.3b1. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:06 Message: Logged In: YES user_id=21627 Can you please explain these changes? Did the extension separator change on RiscOS? If so, what is the last RiscOS release that still used "." as the separator? ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger (dschwertberger) Date: 2003-05-07 23:35 Message: Logged In: YES user_id=86612 File upload didn't work with my browser. Patches are available from http://www.schwertberger.de/RISCOSpatches.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734231&group_id=5470 From noreply@sourceforge.net Fri May 9 09:20:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 01:20:16 -0700 Subject: [Patches] [ python-Patches-734118 ] Threaded Python prevents meeting frame rate targets Message-ID: Patches item #734118, was opened at 2003-05-07 20:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734118&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: Threaded Python prevents meeting frame rate targets Initial Comment: The diffs were made against the CVS version 1.157 of Python/Modules/_tkinter.c. We are using similar diffs with Python 2.2.2. The problem is with the busy-wait interval in _tkinter.c. Our application wants to output at a 30hz frame rate, but with a threaded Python, the frame rates are a multiple of the 20 millisecond Sleep call, so on a really fast machine either 50hz or 25h (47hz and 23hz on my system). Enclosed is a Python test program that demonstrates the limitation. If you install a patched version of _tkinter.c, the program will get the right frame rate. - Greg Couch aftertest.py: ------------ # # Repeatedly register a Tcl "after" callback to see how many calls # per second are made with various delay times. # start_time = None count = 0 delay_ms = 33 # milliseconds def after_cb(): f.after(delay_ms, after_cb) global count, start_time import time t = time.time() if start_time == None: start_time = t count = 0 return count = count + 1 elapsed_time = float(t - start_time) if elapsed_time >= 1: r = count / elapsed_time print 'After calls per second: %.1f' % r start_time = t count = 0 import Tkinter if hasattr(Tkinter._tkinter, "setbusywaitinterval"): Tkinter._tkinter.setbusywaitinterval(0) f = Tkinter.Frame() f.after(delay_ms, after_cb) f.mainloop() ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:20 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as NEWS 1.760 _tkinter.c 1.158 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734118&group_id=5470 From noreply@sourceforge.net Fri May 9 10:08:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 02:08:24 -0700 Subject: [Patches] [ python-Patches-612627 ] Allow more Unicode on sys.stdout Message-ID: Patches item #612627, was opened at 2002-09-21 22:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Allow more Unicode on sys.stdout Initial Comment: This patch extends the set of Unicode strings that can be printed to sys.stdout, to support all strings that the terminal will likely support. It also adds an encoding attribute to sys.std{in,out}. To do that: - it adds a .encoding attribute to all file objects, which is normally None - initializes the encoding of sys.stdin and sys.stdout if either is a terminal. - adds a wrapper object around sys.stdout in site.py that encodes all Unicode objects according to the detected encoding, if that encoding is known to Python To find the encoding of the terminal, it - uses GetConsoleCP and GetConsoleOutputCP on Windows, - uses nl_langinfo(CODESET) on Unix, if available. The primary rationale for this change is that people should be able to print Unicode in an interactive session. A parallel change needs to be added for IDLE, so that it adds the .encoding attribute to the emulated stdout (it already supports printing of Unicode on stdout). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 11:08 Message: Logged In: YES user_id=21627 Any chance that this can go into 2.3b2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-29 15:40 Message: Logged In: YES user_id=21627 In stdout3.txt, PyFile_SetEncoding has been added, wrapping the creation and assignment of the string object f_encoding. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-28 09:44 Message: Logged In: YES user_id=38388 Looks ok except for the direct hacking of f_encoding in the sys module. Please add either a macro or a new API to make changing the encoding from C possible without tapping directly into the implementation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-23 12:59 Message: Logged In: YES user_id=21627 Is the patch now acceptable? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 19:47 Message: Logged In: YES user_id=21627 I've attached a revised version which implements your proposal; this version works without modification of site.py. In its current form, the file encoding is only applied in print; for sys.stdout.write, it is ignored. For print, it is applied independent of whether this is a script or interactive mode. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-25 14:09 Message: Logged In: YES user_id=38388 I think it could work by adding a special case to PyFile_WriteObject() instead of calling PyObject_Print(). You first encode the Unicode object and then let PyFile_WriteString() take care of the writing to the FILE* object. I see no other way, since you can't place the .encoding information into the FILE* object. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 11:02 Message: Logged In: YES user_id=21627 I have considered implementing it in the file object. However, it becomes quite involved, and heavy C code: PyFile_WriteObject calls PyObject_Print. Since Unicode does not implement a tp_print, this calls str/repr, which converts using the default encoding. It is not clear at which point the file encoding should be taking into account. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-24 10:10 Message: Logged In: NO I like the .encoding concept. I don't really like the sys.stdout wrapper. Wouldn't it be better to add the functionality to the file object .write() and .writelines() methods and then only use the wrapper in case sys.stdout is not a true file object ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 From noreply@sourceforge.net Fri May 9 10:14:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 02:14:09 -0700 Subject: [Patches] [ python-Patches-612627 ] Allow more Unicode on sys.stdout Message-ID: Patches item #612627, was opened at 2002-09-21 22:32 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: Allow more Unicode on sys.stdout Initial Comment: This patch extends the set of Unicode strings that can be printed to sys.stdout, to support all strings that the terminal will likely support. It also adds an encoding attribute to sys.std{in,out}. To do that: - it adds a .encoding attribute to all file objects, which is normally None - initializes the encoding of sys.stdin and sys.stdout if either is a terminal. - adds a wrapper object around sys.stdout in site.py that encodes all Unicode objects according to the detected encoding, if that encoding is known to Python To find the encoding of the terminal, it - uses GetConsoleCP and GetConsoleOutputCP on Windows, - uses nl_langinfo(CODESET) on Unix, if available. The primary rationale for this change is that people should be able to print Unicode in an interactive session. A parallel change needs to be added for IDLE, so that it adds the .encoding attribute to the emulated stdout (it already supports printing of Unicode on stdout). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-05-09 11:14 Message: Logged In: YES user_id=38388 Sorry for not getting back to you on this earlier. stdout3.txt looks OK. Please check it in. Thanks ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 11:08 Message: Logged In: YES user_id=21627 Any chance that this can go into 2.3b2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-29 15:40 Message: Logged In: YES user_id=21627 In stdout3.txt, PyFile_SetEncoding has been added, wrapping the creation and assignment of the string object f_encoding. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-28 09:44 Message: Logged In: YES user_id=38388 Looks ok except for the direct hacking of f_encoding in the sys module. Please add either a macro or a new API to make changing the encoding from C possible without tapping directly into the implementation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-23 12:59 Message: Logged In: YES user_id=21627 Is the patch now acceptable? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 19:47 Message: Logged In: YES user_id=21627 I've attached a revised version which implements your proposal; this version works without modification of site.py. In its current form, the file encoding is only applied in print; for sys.stdout.write, it is ignored. For print, it is applied independent of whether this is a script or interactive mode. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-25 14:09 Message: Logged In: YES user_id=38388 I think it could work by adding a special case to PyFile_WriteObject() instead of calling PyObject_Print(). You first encode the Unicode object and then let PyFile_WriteString() take care of the writing to the FILE* object. I see no other way, since you can't place the .encoding information into the FILE* object. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 11:02 Message: Logged In: YES user_id=21627 I have considered implementing it in the file object. However, it becomes quite involved, and heavy C code: PyFile_WriteObject calls PyObject_Print. Since Unicode does not implement a tp_print, this calls str/repr, which converts using the default encoding. It is not clear at which point the file encoding should be taking into account. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-24 10:10 Message: Logged In: NO I like the .encoding concept. I don't really like the sys.stdout wrapper. Wouldn't it be better to add the functionality to the file object .write() and .writelines() methods and then only use the wrapper in case sys.stdout is not a true file object ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 From noreply@sourceforge.net Fri May 9 13:41:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 05:41:53 -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: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) 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-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 Fri May 9 13:43:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 05:43:45 -0700 Subject: [Patches] [ python-Patches-639139 ] Remove type-check from urllib2 Message-ID: Patches item #639139, was opened at 2002-11-15 22:25 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&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: Remove type-check from urllib2 Initial Comment: Remove undesirable type-checking assertion from urllib2.Request. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-05-09 13:43 Message: Logged In: YES user_id=261020 Well, I think EAFP is probably best. An attribute check is in some sense the nearest thing to the assert that's there now, which is why my patch did that. OTOH, a method check seemed half-baked to me and so worse than an attribute check. it's not worth *too* much of our time :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 02:32 Message: Logged In: YES user_id=357491 It's not so much that the dummy attribute would break anything so much as it is just unneeded. If you want to make sure an object is not going to meet your required API you either just follow EAFP (Easier to Ask Forgiveness than Permission) or you explicitly test for the required interface. There is no good argument to have to flag an object to say that it meets an API spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 21:21 Message: Logged In: YES user_id=261020 Why not a new attribute? What would it break? Checking for the interface by checking all the methods (there are maybe ten of them) is not really practical, and really it's the intent that's the important bit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 17:57 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 17:55 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 14:46 Message: Logged In: YES user_id=261020 It's widely regarded as a bug if Python code checks for type with isinstance (or type(foo) == type(bar)) without some good reason. It's plausible that you may want to make an object that implements the Request interface without deriving from Request (say, I don't know, to implement the frobozz URI scheme, which requires ordered headers, and never has any data associated with it). If so, you don't want to have to follow 'bug fixes' in the Python std. library that may break your code simply because you had to derive from Request to satisfy the assertion. I might have done this when I wrote a couple of modules that build on urllib2, actually. I'm not sure whether that would have been the best way, because I didn't think about it since I didn't have any choice in the matter, thanks to this assertion! OTOH, it's true that removing type-checks can break backwards compatibility. However, this is an assertion, not a real runtime type-check, so it won't break backwards compatibility: if people are relying on catching AssertionError to do type-checking in their own code, that's their problem! The docs say: urlopen(url[, data]) Open the URL url, which can be either a string or a Request object (currently the code checks that it really is a Request instance, or an instance of a subclass of Request). Note the 'currently' (and the source code comment indicating that what we really want to check is the interface), and that fact that the code *doesn't* actually check it, but only asserts. Request interface is already documented, so there's no problem there. John ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 23:14 Message: Logged In: YES user_id=33168 John, could you explain why you need it and what is the benefit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 From noreply@sourceforge.net Fri May 9 17:07:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 09:07:19 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-26 03:09 Message generated for change (Comment added) made by jhylton 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: Jeremy Hylton (jhylton) Date: 2003-05-09 16: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 22: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 17: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 16: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 16: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 09: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 19: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 17: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 16: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 15: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 08: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 08: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 21: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 17: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 15: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 09: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 15: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 11: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 21: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 21: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-26 04: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 Fri May 9 17:22:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 09:22:16 -0700 Subject: [Patches] [ python-Patches-734231 ] Support for RISC OS Message-ID: Patches item #734231, was opened at 2003-05-07 23:27 Message generated for change (Comment added) made by dschwertberger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734231&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) Assigned to: Nobody/Anonymous (nobody) Summary: Support for RISC OS Initial Comment: Support for RISC OS platform with Python 2.3. Some IP6 related #ifdefs in socket.c for non IP6 platforms. Patches are relative to 2.3b1. ---------------------------------------------------------------------- >Comment By: Dietmar Schwertberger (dschwertberger) Date: 2003-05-09 18:22 Message: Logged In: YES user_id=86612 No, it was always "/", but it seems that when extsep was moved from os.py to OS specific ...path.py, this was changed by accident. riscospath.sep is "." ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:06 Message: Logged In: YES user_id=21627 Can you please explain these changes? Did the extension separator change on RiscOS? If so, what is the last RiscOS release that still used "." as the separator? ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger (dschwertberger) Date: 2003-05-07 23:35 Message: Logged In: YES user_id=86612 File upload didn't work with my browser. Patches are available from http://www.schwertberger.de/RISCOSpatches.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734231&group_id=5470 From noreply@sourceforge.net Fri May 9 17:37:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 09:37:34 -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-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 Sat May 10 00:46:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 16:46:12 -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: None Status: Open Resolution: None 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-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 Sat May 10 00:47:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 16:47:46 -0700 Subject: [Patches] [ python-Patches-639139 ] Remove type-check from urllib2 Message-ID: Patches item #639139, was opened at 2002-11-15 14:25 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Brett Cannon (bcannon) Summary: Remove type-check from urllib2 Initial Comment: Remove undesirable type-checking assertion from urllib2.Request. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-09 16:47 Message: Logged In: YES user_id=357491 =) OK. If you care to rewrite the patch using EAFP, then please do so. If not, then you just followup here saying you don't think the patch is worthing persuing any farther so I can close it? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 05:43 Message: Logged In: YES user_id=261020 Well, I think EAFP is probably best. An attribute check is in some sense the nearest thing to the assert that's there now, which is why my patch did that. OTOH, a method check seemed half-baked to me and so worse than an attribute check. it's not worth *too* much of our time :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 18:32 Message: Logged In: YES user_id=357491 It's not so much that the dummy attribute would break anything so much as it is just unneeded. If you want to make sure an object is not going to meet your required API you either just follow EAFP (Easier to Ask Forgiveness than Permission) or you explicitly test for the required interface. There is no good argument to have to flag an object to say that it meets an API spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 13:21 Message: Logged In: YES user_id=261020 Why not a new attribute? What would it break? Checking for the interface by checking all the methods (there are maybe ten of them) is not really practical, and really it's the intent that's the important bit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:57 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:55 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 06:46 Message: Logged In: YES user_id=261020 It's widely regarded as a bug if Python code checks for type with isinstance (or type(foo) == type(bar)) without some good reason. It's plausible that you may want to make an object that implements the Request interface without deriving from Request (say, I don't know, to implement the frobozz URI scheme, which requires ordered headers, and never has any data associated with it). If so, you don't want to have to follow 'bug fixes' in the Python std. library that may break your code simply because you had to derive from Request to satisfy the assertion. I might have done this when I wrote a couple of modules that build on urllib2, actually. I'm not sure whether that would have been the best way, because I didn't think about it since I didn't have any choice in the matter, thanks to this assertion! OTOH, it's true that removing type-checks can break backwards compatibility. However, this is an assertion, not a real runtime type-check, so it won't break backwards compatibility: if people are relying on catching AssertionError to do type-checking in their own code, that's their problem! The docs say: urlopen(url[, data]) Open the URL url, which can be either a string or a Request object (currently the code checks that it really is a Request instance, or an instance of a subclass of Request). Note the 'currently' (and the source code comment indicating that what we really want to check is the interface), and that fact that the code *doesn't* actually check it, but only asserts. Request interface is already documented, so there's no problem there. John ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 15:14 Message: Logged In: YES user_id=33168 John, could you explain why you need it and what is the benefit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 From noreply@sourceforge.net Sat May 10 08:11:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 00:11:14 -0700 Subject: [Patches] [ python-Patches-612627 ] Allow more Unicode on sys.stdout Message-ID: Patches item #612627, was opened at 2002-09-21 22:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Allow more Unicode on sys.stdout Initial Comment: This patch extends the set of Unicode strings that can be printed to sys.stdout, to support all strings that the terminal will likely support. It also adds an encoding attribute to sys.std{in,out}. To do that: - it adds a .encoding attribute to all file objects, which is normally None - initializes the encoding of sys.stdin and sys.stdout if either is a terminal. - adds a wrapper object around sys.stdout in site.py that encodes all Unicode objects according to the detected encoding, if that encoding is known to Python To find the encoding of the terminal, it - uses GetConsoleCP and GetConsoleOutputCP on Windows, - uses nl_langinfo(CODESET) on Unix, if available. The primary rationale for this change is that people should be able to print Unicode in an interactive session. A parallel change needs to be added for IDLE, so that it adds the .encoding attribute to the emulated stdout (it already supports printing of Unicode on stdout). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:11 Message: Logged In: YES user_id=21627 Committed as concrete.tex 1.25 libstdtypes.tex 1.124 fileobject.h 2.32 fileobject.c 2.178 sysmodule.c 2.119 NEWS 1.763 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-05-09 11:14 Message: Logged In: YES user_id=38388 Sorry for not getting back to you on this earlier. stdout3.txt looks OK. Please check it in. Thanks ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 11:08 Message: Logged In: YES user_id=21627 Any chance that this can go into 2.3b2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-29 15:40 Message: Logged In: YES user_id=21627 In stdout3.txt, PyFile_SetEncoding has been added, wrapping the creation and assignment of the string object f_encoding. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-28 09:44 Message: Logged In: YES user_id=38388 Looks ok except for the direct hacking of f_encoding in the sys module. Please add either a macro or a new API to make changing the encoding from C possible without tapping directly into the implementation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-23 12:59 Message: Logged In: YES user_id=21627 Is the patch now acceptable? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 19:47 Message: Logged In: YES user_id=21627 I've attached a revised version which implements your proposal; this version works without modification of site.py. In its current form, the file encoding is only applied in print; for sys.stdout.write, it is ignored. For print, it is applied independent of whether this is a script or interactive mode. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-25 14:09 Message: Logged In: YES user_id=38388 I think it could work by adding a special case to PyFile_WriteObject() instead of calling PyObject_Print(). You first encode the Unicode object and then let PyFile_WriteString() take care of the writing to the FILE* object. I see no other way, since you can't place the .encoding information into the FILE* object. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 11:02 Message: Logged In: YES user_id=21627 I have considered implementing it in the file object. However, it becomes quite involved, and heavy C code: PyFile_WriteObject calls PyObject_Print. Since Unicode does not implement a tp_print, this calls str/repr, which converts using the default encoding. It is not clear at which point the file encoding should be taking into account. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-24 10:10 Message: Logged In: NO I like the .encoding concept. I don't really like the sys.stdout wrapper. Wouldn't it be better to add the functionality to the file object .write() and .writelines() methods and then only use the wrapper in case sys.stdout is not a true file object ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 From noreply@sourceforge.net Sat May 10 08:37:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 00:37:55 -0700 Subject: [Patches] [ python-Patches-734231 ] Support for RISC OS Message-ID: Patches item #734231, was opened at 2003-05-07 23:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734231&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) Assigned to: Nobody/Anonymous (nobody) Summary: Support for RISC OS Initial Comment: Support for RISC OS platform with Python 2.3. Some IP6 related #ifdefs in socket.c for non IP6 platforms. Patches are relative to 2.3b1. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:37 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as pyport.h 2.61 site.py 1.50 socket.py 1.40 riscospath.py 1.10 regrtest.py 1.140 test_bz2.py 1.15 test_exceptions.py 1.19 test_import.py 1.18 test_normalization.py 1.7 test_select.py 1.16 test_shelve.py 1.6 test_support.py 1.54 test_tarfile.py 1.9 test_zipimport.py 1.9 socketmodule.c 1.268 timemodule.c 2.137 zipimport.c 1.14 typeobject.c 2.230 grammar.c 2.22 compile.c 2.284 Makefile 1.6 pyconfig.h 1.7 sleep.c 1.3 riscosmodule.c 1.7 swimodule.c 1.3 !Boot 1.3 !Run 1.2 ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger (dschwertberger) Date: 2003-05-09 18:22 Message: Logged In: YES user_id=86612 No, it was always "/", but it seems that when extsep was moved from os.py to OS specific ...path.py, this was changed by accident. riscospath.sep is "." ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:06 Message: Logged In: YES user_id=21627 Can you please explain these changes? Did the extension separator change on RiscOS? If so, what is the last RiscOS release that still used "." as the separator? ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger (dschwertberger) Date: 2003-05-07 23:35 Message: Logged In: YES user_id=86612 File upload didn't work with my browser. Patches are available from http://www.schwertberger.de/RISCOSpatches.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734231&group_id=5470 From noreply@sourceforge.net Sat May 10 08:44:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 00:44:26 -0700 Subject: [Patches] [ python-Patches-730603 ] socketmodule inet_ntop built when IPV6 is disabled Message-ID: Patches item #730603, was opened at 2003-05-01 07:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730603&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Johns (cjohns) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule inet_ntop built when IPV6 is disabled Initial Comment: RTEMS does not support IPV6 and so does not define ENABLE_IPV6 for Python. RTEMS contains an aging port of the FreeBSD stack and the port contains some IPV6 things such as inet_ntop and inet_pton. This causes HAVE_INET_PTON to be defined to 1 causing the current socketmodule.c to compile the socket_inet_ntop code. The assumption being these functions are only present with IPV6 stacks. This assumption is valid, how-ever RTEMS breaks this assuption and fixing this in RTEMS is not pratical. Removing the HAVE_INET_PTON definition causes socketmodule.c to compile in a private version. The private versions have a slightly different prototype to RTEMS and so the compiler stops with an error. This patch seems the simplest solutions given it does not effect other platforms. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:44 Message: Logged In: YES user_id=21627 I believe this patch is now superceded by #734231. It appears that the problem of inet_pton is shared on many platforms, so the code now wraps the buffer declaration with ENABLE_IPV6. Can you please retry the current CVS, and indicate whether further changes are needed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730603&group_id=5470 From noreply@sourceforge.net Sat May 10 10:08:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 02:08:53 -0700 Subject: [Patches] [ python-Patches-735613 ] Python2.3b1 makefile improperly installs IDLE Message-ID: Patches item #735613, was opened at 2003-05-10 02: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=735613&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Stearns (jeffstearns) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.3b1 makefile improperly installs IDLE Initial Comment: The Makefile.pre.in for Python 2.3b1 has a bug which may cause idle to be installed in the wrong place. The bug occurs at the idleinstall target. When the Makefile calls .../idle/setup.py, it passes --install-platlib, but it fails to pass --install-purelib. This means that setup.py will always try to install the .../idlelib/*.py files within /usr/local, regardless of what parameters are passed to the Makefile. The fix is to add --install-purelib=$(LIBDEST) to the rule for idleinstall. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735613&group_id=5470 From noreply@sourceforge.net Sat May 10 10:18:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 02:18:21 -0700 Subject: [Patches] [ python-Patches-735614 ] Python makefile may install idle in the wrong place Message-ID: Patches item #735614, was opened at 2003-05-10 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=735614&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Stearns (jeffstearns) Assigned to: Nobody/Anonymous (nobody) Summary: Python makefile may install idle in the wrong place Initial Comment: The Python makefile ignores some parameters when installing idle. This may cause the .../idle/*.py files to be installed to the wrong directory. The idleinstall target ignores the ${prefix} value in the Makefile. Instead, it always installs its *.py files below /usr/local/. Some of us don't install Python there. The fix is to add a missing line to Makefile.pre.in. Patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735614&group_id=5470 From noreply@sourceforge.net Sat May 10 12:55:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 04:55:03 -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: None Status: Open Resolution: None 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-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 Sat May 10 12:58:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 04:58:03 -0700 Subject: [Patches] [ python-Patches-639139 ] Remove type-check from urllib2 Message-ID: Patches item #639139, was opened at 2002-11-15 22:25 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Brett Cannon (bcannon) Summary: Remove type-check from urllib2 Initial Comment: Remove undesirable type-checking assertion from urllib2.Request. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-05-10 12:58 Message: Logged In: YES user_id=261020 Is there a 'least interesting patch of the year' prize? My entry is attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-10 00:47 Message: Logged In: YES user_id=357491 =) OK. If you care to rewrite the patch using EAFP, then please do so. If not, then you just followup here saying you don't think the patch is worthing persuing any farther so I can close it? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 13:43 Message: Logged In: YES user_id=261020 Well, I think EAFP is probably best. An attribute check is in some sense the nearest thing to the assert that's there now, which is why my patch did that. OTOH, a method check seemed half-baked to me and so worse than an attribute check. it's not worth *too* much of our time :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 02:32 Message: Logged In: YES user_id=357491 It's not so much that the dummy attribute would break anything so much as it is just unneeded. If you want to make sure an object is not going to meet your required API you either just follow EAFP (Easier to Ask Forgiveness than Permission) or you explicitly test for the required interface. There is no good argument to have to flag an object to say that it meets an API spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 21:21 Message: Logged In: YES user_id=261020 Why not a new attribute? What would it break? Checking for the interface by checking all the methods (there are maybe ten of them) is not really practical, and really it's the intent that's the important bit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 17:57 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 17:55 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 14:46 Message: Logged In: YES user_id=261020 It's widely regarded as a bug if Python code checks for type with isinstance (or type(foo) == type(bar)) without some good reason. It's plausible that you may want to make an object that implements the Request interface without deriving from Request (say, I don't know, to implement the frobozz URI scheme, which requires ordered headers, and never has any data associated with it). If so, you don't want to have to follow 'bug fixes' in the Python std. library that may break your code simply because you had to derive from Request to satisfy the assertion. I might have done this when I wrote a couple of modules that build on urllib2, actually. I'm not sure whether that would have been the best way, because I didn't think about it since I didn't have any choice in the matter, thanks to this assertion! OTOH, it's true that removing type-checks can break backwards compatibility. However, this is an assertion, not a real runtime type-check, so it won't break backwards compatibility: if people are relying on catching AssertionError to do type-checking in their own code, that's their problem! The docs say: urlopen(url[, data]) Open the URL url, which can be either a string or a Request object (currently the code checks that it really is a Request instance, or an instance of a subclass of Request). Note the 'currently' (and the source code comment indicating that what we really want to check is the interface), and that fact that the code *doesn't* actually check it, but only asserts. Request interface is already documented, so there's no problem there. John ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 23:14 Message: Logged In: YES user_id=33168 John, could you explain why you need it and what is the benefit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 From noreply@sourceforge.net Sat May 10 13:30:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 05:30:07 -0700 Subject: [Patches] [ python-Patches-735694 ] Pydoc.py fixes links Message-ID: Patches item #735694, was opened at 2003-05-10 07: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=735694&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Raymond A. St. Marie (rastm2) Assigned to: Nobody/Anonymous (nobody) Summary: Pydoc.py fixes links Initial Comment: This is for Ka-Ping Yee. The links to certain python docs are incorrect in the document server link dictionary called "class Helper" about line 1377 to 1490' of pydoc.py . The corrected section of code is attached. You should be able to cut and paste the code right over the original code and save the file to fix all your links. The individual changes I made follow the code. Ping, if this helps, please drop me a line. I'm a newbie programmer, so make sure you look over the changes. It would make my day to get a word from a real programmer - if this is correct or otherwise. If it's already been fixed, then I'm sorry to waste you time. :) Thanks, Ray St. Marie Rastm2@aol.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735694&group_id=5470 From noreply@sourceforge.net Sat May 10 13:56:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 05:56:45 -0700 Subject: [Patches] [ python-Patches-735694 ] Pydoc.py fixes links Message-ID: Patches item #735694, was opened at 2003-05-10 07:30 Message generated for change (Settings changed) made by rastm2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735694&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Raymond A. St. Marie (rastm2) >Assigned to: Ka-Ping Yee (ping) Summary: Pydoc.py fixes links Initial Comment: This is for Ka-Ping Yee. The links to certain python docs are incorrect in the document server link dictionary called "class Helper" about line 1377 to 1490' of pydoc.py . The corrected section of code is attached. You should be able to cut and paste the code right over the original code and save the file to fix all your links. The individual changes I made follow the code. Ping, if this helps, please drop me a line. I'm a newbie programmer, so make sure you look over the changes. It would make my day to get a word from a real programmer - if this is correct or otherwise. If it's already been fixed, then I'm sorry to waste you time. :) Thanks, Ray St. Marie Rastm2@aol.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735694&group_id=5470 From noreply@sourceforge.net Sat May 10 21:10:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 13:10:59 -0700 Subject: [Patches] [ python-Patches-732284 ] UnixWare 7 build patch Message-ID: Patches item #732284, was opened at 2003-05-04 11:58 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7 build patch Initial Comment: Here is a patch to fix the build on UnixWare 7 & OpenUNIX 8 without taking the simple route of define_xopen_source=no. This patch depends on patches 731191 and 732234 ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-10 13:10 Message: Logged In: YES user_id=618097 Thanks for the changes so far. Actually OpenUNIUX identifies iteslf a 8.0.0 I'm attaching a patch that corrects this as well as allowing UnixWare 7.1.0 through 7.1.3. I've also added SCO OpenServer to the define_xopen_source=no list as it has the same problems of missing data types. Your comments in configure.in about UnixWare 7 actually fit OpenServer perfectly. I've updated the UnixWare 7 comments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 00:19 Message: Logged In: YES user_id=21627 Assuming it all works now fine, I'm closing this patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 22:15 Message: Logged In: YES user_id=21627 I have now disabled _XOPEN_SOURCE in configure 1.396 configure.in 1.407 I have used the information provided in 731991, and assumed that the patch is necessary for UnixWare 7.1.[123], where 7.1.2 identifies itself as OpenUNIX 8.0. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:58 Message: Logged In: YES user_id=21627 When I asked "is there no way to get these types", I didn't expect that the answer would be "sure, Python can define them itself". By that approach, you wouldn't need any system headers, but could include any declaration literally in Python, with #ifdef UW7. This is clearly not the right solution: I meant to ask "is there no way to get these types *from the system headers*" If the answer to that question is "no", then I'm still curious what the answer to the question "Why *specifically* do we need u_int in the first place?" is. By "specifically", I mean what *specific* other declaration from the system headers relies on it, saying that sys/socket.h needs it is too general. I'm willing to go with the simple patch, provided it is changed in the following way: 1. A comment is added indicating what the specific reason for this patch is. 2. The system check is strengthened to not include future system releases. I.e. saying OpenUNIX/8.*|UnixWare/7.* is too generic: include a list of minor system releases so far. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 14:59 Message: Logged In: YES user_id=618097 If I define _POSIX_SOURCE the data types are available but I get a whole new set of errors in posixmodule.c .... cc -Kthread -K pentium,host,inline,loop_unroll,alloca -DNDEBUG -O -I. -I/opt/src/utils/python/python/dist/src/Include -DPy_BUILD_CORE -c /opt/src/utils/python/python/dist/src/Modules/posixmodule.c -o Modules/posixmodule.o UX:acomp: ERROR: "/usr/include/sys/wait.h", line 141: Syntax error before or at: siginfo_t UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 874: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 875: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 876: improper member use: tv_nsec gmake: *** [Modules/posixmodule.o] Error 1 .... I'm attaching a new patch that has the data type checks from patch 731991. With this patch (which still depends on patches 731991 & 732234) UnixWare 7 builds. It's kind of ugly and I don't like it much. The simple alternative is to use this patch -------------------------- --- configure.in.old 2003-04-17 13:16:42.000000000 -0700 +++ configure.in 2003-04-22 15:26:13.450080095 -0700 @@ -124,6 +124,8 @@ # of union __?sigval. Reported by Stuart Bishop. SunOS/5.6) define_xopen_source=no;; + OpenUNIX/8.* | UnixWare/7.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes -------------------------- ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 13:09 Message: Logged In: YES user_id=618097 There may be a way Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:15 Message: Logged In: YES user_id=21627 Is there absolutely no way to get to these types when _XOPEN_SOURCE is defined? Not by including some obscure header file? Not by defining some obscure macro? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 From noreply@sourceforge.net Sat May 10 21:24:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 13:24:05 -0700 Subject: [Patches] [ python-Patches-732284 ] UnixWare 7 build patch Message-ID: Patches item #732284, was opened at 2003-05-04 11:58 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7 build patch Initial Comment: Here is a patch to fix the build on UnixWare 7 & OpenUNIX 8 without taking the simple route of define_xopen_source=no. This patch depends on patches 731191 and 732234 ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-10 13:24 Message: Logged In: YES user_id=618097 Thanks for the changes so far. Actually OpenUNIUX identifies iteslf a 8.0.0 I'm attaching a patch that corrects this as well as allowing UnixWare 7.1.0 through 7.1.3. I've also added SCO OpenServer to the define_xopen_source=no list as it has the same problems of missing data types. Your comments in configure.in about UnixWare 7 actually fit OpenServer perfectly. I've updated the UnixWare 7 comments. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-10 13:10 Message: Logged In: YES user_id=618097 Thanks for the changes so far. Actually OpenUNIUX identifies iteslf a 8.0.0 I'm attaching a patch that corrects this as well as allowing UnixWare 7.1.0 through 7.1.3. I've also added SCO OpenServer to the define_xopen_source=no list as it has the same problems of missing data types. Your comments in configure.in about UnixWare 7 actually fit OpenServer perfectly. I've updated the UnixWare 7 comments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 00:19 Message: Logged In: YES user_id=21627 Assuming it all works now fine, I'm closing this patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 22:15 Message: Logged In: YES user_id=21627 I have now disabled _XOPEN_SOURCE in configure 1.396 configure.in 1.407 I have used the information provided in 731991, and assumed that the patch is necessary for UnixWare 7.1.[123], where 7.1.2 identifies itself as OpenUNIX 8.0. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:58 Message: Logged In: YES user_id=21627 When I asked "is there no way to get these types", I didn't expect that the answer would be "sure, Python can define them itself". By that approach, you wouldn't need any system headers, but could include any declaration literally in Python, with #ifdef UW7. This is clearly not the right solution: I meant to ask "is there no way to get these types *from the system headers*" If the answer to that question is "no", then I'm still curious what the answer to the question "Why *specifically* do we need u_int in the first place?" is. By "specifically", I mean what *specific* other declaration from the system headers relies on it, saying that sys/socket.h needs it is too general. I'm willing to go with the simple patch, provided it is changed in the following way: 1. A comment is added indicating what the specific reason for this patch is. 2. The system check is strengthened to not include future system releases. I.e. saying OpenUNIX/8.*|UnixWare/7.* is too generic: include a list of minor system releases so far. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 14:59 Message: Logged In: YES user_id=618097 If I define _POSIX_SOURCE the data types are available but I get a whole new set of errors in posixmodule.c .... cc -Kthread -K pentium,host,inline,loop_unroll,alloca -DNDEBUG -O -I. -I/opt/src/utils/python/python/dist/src/Include -DPy_BUILD_CORE -c /opt/src/utils/python/python/dist/src/Modules/posixmodule.c -o Modules/posixmodule.o UX:acomp: ERROR: "/usr/include/sys/wait.h", line 141: Syntax error before or at: siginfo_t UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 874: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 875: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 876: improper member use: tv_nsec gmake: *** [Modules/posixmodule.o] Error 1 .... I'm attaching a new patch that has the data type checks from patch 731991. With this patch (which still depends on patches 731991 & 732234) UnixWare 7 builds. It's kind of ugly and I don't like it much. The simple alternative is to use this patch -------------------------- --- configure.in.old 2003-04-17 13:16:42.000000000 -0700 +++ configure.in 2003-04-22 15:26:13.450080095 -0700 @@ -124,6 +124,8 @@ # of union __?sigval. Reported by Stuart Bishop. SunOS/5.6) define_xopen_source=no;; + OpenUNIX/8.* | UnixWare/7.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes -------------------------- ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 13:09 Message: Logged In: YES user_id=618097 There may be a way Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:15 Message: Logged In: YES user_id=21627 Is there absolutely no way to get to these types when _XOPEN_SOURCE is defined? Not by including some obscure header file? Not by defining some obscure macro? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 From noreply@sourceforge.net Sat May 10 22:10:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 14:10:05 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-03 16:04 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-10 14:10 Message: Logged In: YES user_id=618097 The errors: UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1100: argument #3 incompatible with prototype: accept() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1319: argument #5 incompatible with prototype: _getsockopt() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1337: argument #5 incompatible with prototype: _getsockopt() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1571: argument #3 incompatible with prototype: getsockname() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1599: argument #3 incompatible with prototype: getpeername() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1833: argument #6 incompatible with prototype: recvfrom() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 2963: statement not reached How it works: First it tests if the system supports socklen_t data type. If not, it loops through compiling a test program and testing the compiler's return code. It tries using int, size_t, unsigned, long, and then "unsigned long". I've personaly used this on UnixWare 2.03, UnixWare 2.1.3, UnixWare 7.x SCO OpenServer 3, SCO OpenServer 5, several flavors of Caldera Linux, RedHat 6.2, Solaris 7, & Solaris 8. Looking at http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=100174342829230&w=2 ..... > tested successfully on: > Solaris 2.5.1, 2.6, 7, 8/SPARC, HP-UX 10.20, 11.00, > Tru64 UNIX 4.0D, 5.0A, 5.1, IRIX 6.2, 6.5, AIX 4.3.2. Rsync also features on the Samba build farm (see below), building and testing on over 20 platforms, so its safe to say its portable... Andrew Bartlett ..... socklen-4.patch is against 10 May 2003 CVS ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 22:18 Message: Logged In: YES user_id=21627 I have now disabled _XOPEN_SOURCE for this system. Before applying a patch like this one, I'd like to know a) how it works (see my first comment) b) what specific error it fixes on UnixWare. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=618097 That was a waste of time. I mis read sys/types.h on OpenServer u_int and u_short are not defined because they are warped inside #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) #endif /* !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) */ The error is "/usr/include/sys/socket.h", line 171: error: Syntax error before or at: u_short "/usr/include/sys/socket.h", line 171: error: cannot recover from previous errors .... 167:/* 168: * Structure used by kernel to store most addresses. 169: */ 170:struct sockaddr { 171: u_short sa_family; /* address family */ 172: char sa_data[14]; /* up to 14 bytes of direct address */ 173:}; 174: .... I've modified the patch to be less obtrusive my undefing _XOPEN_SOURCE on OpenServer only. We may end up removing the confdefs2.h parts later if we end up using define_xopen_source=no for OpenServer. As it stands now, with or without this patch, OpenServer doesn't build. This patch is really for SVR4.2 and SVR5 systems. (Ie. UnixWare) ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 13:08 Message: Logged In: YES user_id=618097 There may be a way. Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:51 Message: Logged In: YES user_id=21627 Now we are getting closer. What is the specific line in sys/socket.h that gives the syntax error? Are there alternative definitions of the (function, I suppose), either in socket.h or in another file? Why is u_int not defined when _XOPEN_SOURCE is? IOW: Are you absolutely, definitely, 100% certain that there is no way to compile sys/socket.h when _XOPEN_SOURCE is defined? That would be a serious bug in the system. Now, if we can establish with certainty that the system is broken beyond repair, it is acceptable to work around the bugs, by not defining _XOPEN_SOURCE. We then need to record the specific release of the system that we found is broken, and we need to document what specifically we found broken about it. For better reproducability, we also want to record the name of the person who determined the system being broken. We do all this in the hope that future system releases will be fixed by the system vendors, and that our work-arounds won't be needed anymore when we stop supporting old releases of the system (at a time when nobody uses those old releases anymore). I am not opposed to setting _define_xopen_source=no in principle (I once was, but am not any longer). I only want a convincing analysis that this is necessary to get essential parts of Python (such as sockets) to work. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:29 Message: Logged In: YES user_id=618097 Without u_short and u_int the soclklen_t test can NEVER suceed on OpenServer because of a syntax error in sys/socket.h whthout them. Ugly, but you don't seem to like the option of seting define_xopen_source=no on platforms that puilt fine prior to 2.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:18 Message: Logged In: YES user_id=21627 Why do you say "is needed for the socklen_t test"? Are you referring to the test in your patch? In this test, u_int is not *used* at all, it is only defined. So not defining it should not cause problems. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 11:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 10:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 11 06:33:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 22:33:11 -0700 Subject: [Patches] [ python-Patches-639139 ] Remove type-check from urllib2 Message-ID: Patches item #639139, was opened at 2002-11-15 14:25 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: John J Lee (jjlee) Assigned to: Brett Cannon (bcannon) Summary: Remove type-check from urllib2 Initial Comment: Remove undesirable type-checking assertion from urllib2.Request. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-10 22:33 Message: Logged In: YES user_id=357491 This is not what I meant by EAFP. In order for a patch to do that you would need to wrap all outgoing calls in that method that will use 'req' and see if the exception was because the object didn't have the proper interface. Good try, though. =) Doing it using hasattr in a loop is probably going to be the best bet. If you don't want to do the patch I will understand; I should have been more clear by what I was expecting for EAFP. Thus if you don't want to do it I will do the patch myself. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 04:58 Message: Logged In: YES user_id=261020 Is there a 'least interesting patch of the year' prize? My entry is attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 16:47 Message: Logged In: YES user_id=357491 =) OK. If you care to rewrite the patch using EAFP, then please do so. If not, then you just followup here saying you don't think the patch is worthing persuing any farther so I can close it? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 05:43 Message: Logged In: YES user_id=261020 Well, I think EAFP is probably best. An attribute check is in some sense the nearest thing to the assert that's there now, which is why my patch did that. OTOH, a method check seemed half-baked to me and so worse than an attribute check. it's not worth *too* much of our time :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 18:32 Message: Logged In: YES user_id=357491 It's not so much that the dummy attribute would break anything so much as it is just unneeded. If you want to make sure an object is not going to meet your required API you either just follow EAFP (Easier to Ask Forgiveness than Permission) or you explicitly test for the required interface. There is no good argument to have to flag an object to say that it meets an API spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 13:21 Message: Logged In: YES user_id=261020 Why not a new attribute? What would it break? Checking for the interface by checking all the methods (there are maybe ten of them) is not really practical, and really it's the intent that's the important bit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:57 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:55 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 06:46 Message: Logged In: YES user_id=261020 It's widely regarded as a bug if Python code checks for type with isinstance (or type(foo) == type(bar)) without some good reason. It's plausible that you may want to make an object that implements the Request interface without deriving from Request (say, I don't know, to implement the frobozz URI scheme, which requires ordered headers, and never has any data associated with it). If so, you don't want to have to follow 'bug fixes' in the Python std. library that may break your code simply because you had to derive from Request to satisfy the assertion. I might have done this when I wrote a couple of modules that build on urllib2, actually. I'm not sure whether that would have been the best way, because I didn't think about it since I didn't have any choice in the matter, thanks to this assertion! OTOH, it's true that removing type-checks can break backwards compatibility. However, this is an assertion, not a real runtime type-check, so it won't break backwards compatibility: if people are relying on catching AssertionError to do type-checking in their own code, that's their problem! The docs say: urlopen(url[, data]) Open the URL url, which can be either a string or a Request object (currently the code checks that it really is a Request instance, or an instance of a subclass of Request). Note the 'currently' (and the source code comment indicating that what we really want to check is the interface), and that fact that the code *doesn't* actually check it, but only asserts. Request interface is already documented, so there's no problem there. John ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 15:14 Message: Logged In: YES user_id=33168 John, could you explain why you need it and what is the benefit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 From noreply@sourceforge.net Sun May 11 06:54:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 22:54:12 -0700 Subject: [Patches] [ python-Patches-732284 ] UnixWare 7 build patch Message-ID: Patches item #732284, was opened at 2003-05-04 20:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7 build patch Initial Comment: Here is a patch to fix the build on UnixWare 7 & OpenUNIX 8 without taking the simple route of define_xopen_source=no. This patch depends on patches 731191 and 732234 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 07:54 Message: Logged In: YES user_id=21627 Thanks, applied as configure 1.398 configure.in 1.409 ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-10 22:24 Message: Logged In: YES user_id=618097 Thanks for the changes so far. Actually OpenUNIUX identifies iteslf a 8.0.0 I'm attaching a patch that corrects this as well as allowing UnixWare 7.1.0 through 7.1.3. I've also added SCO OpenServer to the define_xopen_source=no list as it has the same problems of missing data types. Your comments in configure.in about UnixWare 7 actually fit OpenServer perfectly. I've updated the UnixWare 7 comments. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-10 22:10 Message: Logged In: YES user_id=618097 Thanks for the changes so far. Actually OpenUNIUX identifies iteslf a 8.0.0 I'm attaching a patch that corrects this as well as allowing UnixWare 7.1.0 through 7.1.3. I've also added SCO OpenServer to the define_xopen_source=no list as it has the same problems of missing data types. Your comments in configure.in about UnixWare 7 actually fit OpenServer perfectly. I've updated the UnixWare 7 comments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 09:19 Message: Logged In: YES user_id=21627 Assuming it all works now fine, I'm closing this patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 07:15 Message: Logged In: YES user_id=21627 I have now disabled _XOPEN_SOURCE in configure 1.396 configure.in 1.407 I have used the information provided in 731991, and assumed that the patch is necessary for UnixWare 7.1.[123], where 7.1.2 identifies itself as OpenUNIX 8.0. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 06:58 Message: Logged In: YES user_id=21627 When I asked "is there no way to get these types", I didn't expect that the answer would be "sure, Python can define them itself". By that approach, you wouldn't need any system headers, but could include any declaration literally in Python, with #ifdef UW7. This is clearly not the right solution: I meant to ask "is there no way to get these types *from the system headers*" If the answer to that question is "no", then I'm still curious what the answer to the question "Why *specifically* do we need u_int in the first place?" is. By "specifically", I mean what *specific* other declaration from the system headers relies on it, saying that sys/socket.h needs it is too general. I'm willing to go with the simple patch, provided it is changed in the following way: 1. A comment is added indicating what the specific reason for this patch is. 2. The system check is strengthened to not include future system releases. I.e. saying OpenUNIX/8.*|UnixWare/7.* is too generic: include a list of minor system releases so far. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 23:59 Message: Logged In: YES user_id=618097 If I define _POSIX_SOURCE the data types are available but I get a whole new set of errors in posixmodule.c .... cc -Kthread -K pentium,host,inline,loop_unroll,alloca -DNDEBUG -O -I. -I/opt/src/utils/python/python/dist/src/Include -DPy_BUILD_CORE -c /opt/src/utils/python/python/dist/src/Modules/posixmodule.c -o Modules/posixmodule.o UX:acomp: ERROR: "/usr/include/sys/wait.h", line 141: Syntax error before or at: siginfo_t UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 874: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 875: improper member use: tv_nsec UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/posixmodule.c", line 876: improper member use: tv_nsec gmake: *** [Modules/posixmodule.o] Error 1 .... I'm attaching a new patch that has the data type checks from patch 731991. With this patch (which still depends on patches 731991 & 732234) UnixWare 7 builds. It's kind of ugly and I don't like it much. The simple alternative is to use this patch -------------------------- --- configure.in.old 2003-04-17 13:16:42.000000000 -0700 +++ configure.in 2003-04-22 15:26:13.450080095 -0700 @@ -124,6 +124,8 @@ # of union __?sigval. Reported by Stuart Bishop. SunOS/5.6) define_xopen_source=no;; + OpenUNIX/8.* | UnixWare/7.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes -------------------------- ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 22:09 Message: Logged In: YES user_id=618097 There may be a way Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:15 Message: Logged In: YES user_id=21627 Is there absolutely no way to get to these types when _XOPEN_SOURCE is defined? Not by including some obscure header file? Not by defining some obscure macro? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470 From noreply@sourceforge.net Sun May 11 07:01:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 23:01:01 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-04 01:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 08:01 Message: Logged In: YES user_id=21627 So these are all warnings only? I'm not sure I want to risk breaking compilation on other systems to get rid of these warnings this late in the beta cycle. When you say you have used this: Do you mean in combination with OpenSSH, or with Python? On the "how it works" issue: How precisely does it cause the compiler to produce a status code? I.e. what in the test program does it assume to give an error? In particular: Why does it call getpeername? ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-10 23:10 Message: Logged In: YES user_id=618097 The errors: UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1100: argument #3 incompatible with prototype: accept() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1319: argument #5 incompatible with prototype: _getsockopt() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1337: argument #5 incompatible with prototype: _getsockopt() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1571: argument #3 incompatible with prototype: getsockname() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1599: argument #3 incompatible with prototype: getpeername() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1833: argument #6 incompatible with prototype: recvfrom() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 2963: statement not reached How it works: First it tests if the system supports socklen_t data type. If not, it loops through compiling a test program and testing the compiler's return code. It tries using int, size_t, unsigned, long, and then "unsigned long". I've personaly used this on UnixWare 2.03, UnixWare 2.1.3, UnixWare 7.x SCO OpenServer 3, SCO OpenServer 5, several flavors of Caldera Linux, RedHat 6.2, Solaris 7, & Solaris 8. Looking at http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=100174342829230&w=2 ..... > tested successfully on: > Solaris 2.5.1, 2.6, 7, 8/SPARC, HP-UX 10.20, 11.00, > Tru64 UNIX 4.0D, 5.0A, 5.1, IRIX 6.2, 6.5, AIX 4.3.2. Rsync also features on the Samba build farm (see below), building and testing on over 20 platforms, so its safe to say its portable... Andrew Bartlett ..... socklen-4.patch is against 10 May 2003 CVS ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 07:18 Message: Logged In: YES user_id=21627 I have now disabled _XOPEN_SOURCE for this system. Before applying a patch like this one, I'd like to know a) how it works (see my first comment) b) what specific error it fixes on UnixWare. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 23:39 Message: Logged In: YES user_id=618097 That was a waste of time. I mis read sys/types.h on OpenServer u_int and u_short are not defined because they are warped inside #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) #endif /* !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) */ The error is "/usr/include/sys/socket.h", line 171: error: Syntax error before or at: u_short "/usr/include/sys/socket.h", line 171: error: cannot recover from previous errors .... 167:/* 168: * Structure used by kernel to store most addresses. 169: */ 170:struct sockaddr { 171: u_short sa_family; /* address family */ 172: char sa_data[14]; /* up to 14 bytes of direct address */ 173:}; 174: .... I've modified the patch to be less obtrusive my undefing _XOPEN_SOURCE on OpenServer only. We may end up removing the confdefs2.h parts later if we end up using define_xopen_source=no for OpenServer. As it stands now, with or without this patch, OpenServer doesn't build. This patch is really for SVR4.2 and SVR5 systems. (Ie. UnixWare) ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 22:08 Message: Logged In: YES user_id=618097 There may be a way. Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:51 Message: Logged In: YES user_id=21627 Now we are getting closer. What is the specific line in sys/socket.h that gives the syntax error? Are there alternative definitions of the (function, I suppose), either in socket.h or in another file? Why is u_int not defined when _XOPEN_SOURCE is? IOW: Are you absolutely, definitely, 100% certain that there is no way to compile sys/socket.h when _XOPEN_SOURCE is defined? That would be a serious bug in the system. Now, if we can establish with certainty that the system is broken beyond repair, it is acceptable to work around the bugs, by not defining _XOPEN_SOURCE. We then need to record the specific release of the system that we found is broken, and we need to document what specifically we found broken about it. For better reproducability, we also want to record the name of the person who determined the system being broken. We do all this in the hope that future system releases will be fixed by the system vendors, and that our work-arounds won't be needed anymore when we stop supporting old releases of the system (at a time when nobody uses those old releases anymore). I am not opposed to setting _define_xopen_source=no in principle (I once was, but am not any longer). I only want a convincing analysis that this is necessary to get essential parts of Python (such as sockets) to work. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 21:29 Message: Logged In: YES user_id=618097 Without u_short and u_int the soclklen_t test can NEVER suceed on OpenServer because of a syntax error in sys/socket.h whthout them. Ugly, but you don't seem to like the option of seting define_xopen_source=no on platforms that puilt fine prior to 2.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:18 Message: Logged In: YES user_id=21627 Why do you say "is needed for the socklen_t test"? Are you referring to the test in your patch? In this test, u_int is not *used* at all, it is only defined. So not defining it should not cause problems. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 21:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 20:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 19:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 11 07:01:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 23:01:58 -0700 Subject: [Patches] [ python-Patches-735613 ] Python2.3b1 makefile improperly installs IDLE Message-ID: Patches item #735613, was opened at 2003-05-10 11:08 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735613&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Stearns (jeffstearns) >Assigned to: Martin v. Löwis (loewis) Summary: Python2.3b1 makefile improperly installs IDLE Initial Comment: The Makefile.pre.in for Python 2.3b1 has a bug which may cause idle to be installed in the wrong place. The bug occurs at the idleinstall target. When the Makefile calls .../idle/setup.py, it passes --install-platlib, but it fails to pass --install-purelib. This means that setup.py will always try to install the .../idlelib/*.py files within /usr/local, regardless of what parameters are passed to the Makefile. The fix is to add --install-purelib=$(LIBDEST) to the rule for idleinstall. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735613&group_id=5470 From noreply@sourceforge.net Sun May 11 07:03:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 23:03:02 -0700 Subject: [Patches] [ python-Patches-735614 ] Python makefile may install idle in the wrong place Message-ID: Patches item #735614, was opened at 2003-05-10 11:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735614&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Stearns (jeffstearns) Assigned to: Nobody/Anonymous (nobody) Summary: Python makefile may install idle in the wrong place Initial Comment: The Python makefile ignores some parameters when installing idle. This may cause the .../idle/*.py files to be installed to the wrong directory. The idleinstall target ignores the ${prefix} value in the Makefile. Instead, it always installs its *.py files below /usr/local/. Some of us don't install Python there. The fix is to add a missing line to Makefile.pre.in. Patch attached. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 08:03 Message: Logged In: YES user_id=21627 Is this a duplicate of 735613? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735614&group_id=5470 From noreply@sourceforge.net Sun May 11 07:06:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 23:06:13 -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: None Status: Open Resolution: None 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-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 Sun May 11 12:19:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 04:19:13 -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: None Status: Open Resolution: None 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-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 Sun May 11 12:46:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 04:46:11 -0700 Subject: [Patches] [ python-Patches-639139 ] Remove type-check from urllib2 Message-ID: Patches item #639139, was opened at 2002-11-15 22:25 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: John J Lee (jjlee) Assigned to: Brett Cannon (bcannon) Summary: Remove type-check from urllib2 Initial Comment: Remove undesirable type-checking assertion from urllib2.Request. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-05-11 12:46 Message: Logged In: YES user_id=261020 No!! Ahem. Personally I wouldn't want to apply a patch like that -- I think it's inappropriate, since this is a violated precondition, and the patch you describe would add significant complexity (not to mention inefficiency, if I dare use that word here). The caller will get AttributeError anyway, with my patch, and though it wasn't my goal to pamper callers who mess up the call, that's actually not an unreasonable error. Would it convince you if I pointed out that my patch is simply EAFP again, at a different place in the call stack? If you don't like AttributeError being raised, you could always wrap up the five uses of req in try: except: blocks, but personally I don't think that's worth the added complexity or bug-masking risk. I don't know... first he tells me not to attribute check, then he wants to do it in a loop ;-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 06:33 Message: Logged In: YES user_id=357491 This is not what I meant by EAFP. In order for a patch to do that you would need to wrap all outgoing calls in that method that will use 'req' and see if the exception was because the object didn't have the proper interface. Good try, though. =) Doing it using hasattr in a loop is probably going to be the best bet. If you don't want to do the patch I will understand; I should have been more clear by what I was expecting for EAFP. Thus if you don't want to do it I will do the patch myself. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 12:58 Message: Logged In: YES user_id=261020 Is there a 'least interesting patch of the year' prize? My entry is attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-10 00:47 Message: Logged In: YES user_id=357491 =) OK. If you care to rewrite the patch using EAFP, then please do so. If not, then you just followup here saying you don't think the patch is worthing persuing any farther so I can close it? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 13:43 Message: Logged In: YES user_id=261020 Well, I think EAFP is probably best. An attribute check is in some sense the nearest thing to the assert that's there now, which is why my patch did that. OTOH, a method check seemed half-baked to me and so worse than an attribute check. it's not worth *too* much of our time :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 02:32 Message: Logged In: YES user_id=357491 It's not so much that the dummy attribute would break anything so much as it is just unneeded. If you want to make sure an object is not going to meet your required API you either just follow EAFP (Easier to Ask Forgiveness than Permission) or you explicitly test for the required interface. There is no good argument to have to flag an object to say that it meets an API spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 21:21 Message: Logged In: YES user_id=261020 Why not a new attribute? What would it break? Checking for the interface by checking all the methods (there are maybe ten of them) is not really practical, and really it's the intent that's the important bit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 17:57 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 17:55 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 14:46 Message: Logged In: YES user_id=261020 It's widely regarded as a bug if Python code checks for type with isinstance (or type(foo) == type(bar)) without some good reason. It's plausible that you may want to make an object that implements the Request interface without deriving from Request (say, I don't know, to implement the frobozz URI scheme, which requires ordered headers, and never has any data associated with it). If so, you don't want to have to follow 'bug fixes' in the Python std. library that may break your code simply because you had to derive from Request to satisfy the assertion. I might have done this when I wrote a couple of modules that build on urllib2, actually. I'm not sure whether that would have been the best way, because I didn't think about it since I didn't have any choice in the matter, thanks to this assertion! OTOH, it's true that removing type-checks can break backwards compatibility. However, this is an assertion, not a real runtime type-check, so it won't break backwards compatibility: if people are relying on catching AssertionError to do type-checking in their own code, that's their problem! The docs say: urlopen(url[, data]) Open the URL url, which can be either a string or a Request object (currently the code checks that it really is a Request instance, or an instance of a subclass of Request). Note the 'currently' (and the source code comment indicating that what we really want to check is the interface), and that fact that the code *doesn't* actually check it, but only asserts. Request interface is already documented, so there's no problem there. John ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 23:14 Message: Logged In: YES user_id=33168 John, could you explain why you need it and what is the benefit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 From noreply@sourceforge.net Sun May 11 15:30:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 07:30:58 -0700 Subject: [Patches] [ python-Patches-734176 ] Make Tkinter.py's nametowidget work with cloned menu widgets Message-ID: Patches item #734176, was opened at 2003-05-07 15:11 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734176&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: Make Tkinter.py's nametowidget work with cloned menu widgets Initial Comment: Tk will clone menu widgets when they are torn off and it gives them names at are similar to the original widget's names. The patch extends the nametowidget so it will return the original widget when given the name of a cloned widget. We used this patch to provide balloon help in cloned menus. This patch isn't perfect, it will fail on clones of clones, but it is a big help. This patch was made against the latest CVS version 1.173 of Tkinter.py but works against older Tkinter.py's too. - Greg Couch ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-05-11 09:30 Message: Logged In: YES user_id=2772 I don't believe that the naming convention of cloned menus is actually documented anywhere (it's certainly not documented in menu(n) of tk-8.3.5 as packaged by RedHat. The only promise that the documentation makes is that the clone "is a child of the original". (but that can be violated if "menu clone" is invoked directly: % menu .m .m % .m clone .n % ) That said, the convention for automatically generated clones hasn't varied in the versions of Tk I'm aware of (at least 8.2 through 8.4) so it might be reasonable to depend on this. Does anybody in Python development also keep up with Tcl/Tk development? It might be reasonable to ask them to document the format of automatically generated clone names. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=734176&group_id=5470 From noreply@sourceforge.net Sun May 11 18:57:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 10:57:43 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-03 16:04 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-05-11 10:57 Message: Logged In: YES user_id=618097 Yes these are warnings. But then warnings are there so you'll look at the code and correct if necessary. If you're nervous about the autoconf test that's fine. I can always correct pyconfig.h after configure runs. But the Modules/socketmodule.c patch should be applied. The code there is just pain wrong. I've used the autoconf bits in OpenSSH and now in my local Python 2.3 tree. I've been using the socketmodule patch since the 2.2.2 beta days. But 2.2.2 uses autoconf 2.13 so the autoconf bits don't work there. I don't know why Albert chose getpeername for the test. I strongly suspect you could use accept, getsockopt, getsockname, recvfrom, or any socket call that has the length option you're testing for. On UnixWare the test progtram (using int) produces the error identifier redeclared: getpeername causing cc to return with a non 0. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 23:01 Message: Logged In: YES user_id=21627 So these are all warnings only? I'm not sure I want to risk breaking compilation on other systems to get rid of these warnings this late in the beta cycle. When you say you have used this: Do you mean in combination with OpenSSH, or with Python? On the "how it works" issue: How precisely does it cause the compiler to produce a status code? I.e. what in the test program does it assume to give an error? In particular: Why does it call getpeername? ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-10 14:10 Message: Logged In: YES user_id=618097 The errors: UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1100: argument #3 incompatible with prototype: accept() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1319: argument #5 incompatible with prototype: _getsockopt() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1337: argument #5 incompatible with prototype: _getsockopt() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1571: argument #3 incompatible with prototype: getsockname() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1599: argument #3 incompatible with prototype: getpeername() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1833: argument #6 incompatible with prototype: recvfrom() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 2963: statement not reached How it works: First it tests if the system supports socklen_t data type. If not, it loops through compiling a test program and testing the compiler's return code. It tries using int, size_t, unsigned, long, and then "unsigned long". I've personaly used this on UnixWare 2.03, UnixWare 2.1.3, UnixWare 7.x SCO OpenServer 3, SCO OpenServer 5, several flavors of Caldera Linux, RedHat 6.2, Solaris 7, & Solaris 8. Looking at http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=100174342829230&w=2 ..... > tested successfully on: > Solaris 2.5.1, 2.6, 7, 8/SPARC, HP-UX 10.20, 11.00, > Tru64 UNIX 4.0D, 5.0A, 5.1, IRIX 6.2, 6.5, AIX 4.3.2. Rsync also features on the Samba build farm (see below), building and testing on over 20 platforms, so its safe to say its portable... Andrew Bartlett ..... socklen-4.patch is against 10 May 2003 CVS ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 22:18 Message: Logged In: YES user_id=21627 I have now disabled _XOPEN_SOURCE for this system. Before applying a patch like this one, I'd like to know a) how it works (see my first comment) b) what specific error it fixes on UnixWare. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=618097 That was a waste of time. I mis read sys/types.h on OpenServer u_int and u_short are not defined because they are warped inside #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) #endif /* !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) */ The error is "/usr/include/sys/socket.h", line 171: error: Syntax error before or at: u_short "/usr/include/sys/socket.h", line 171: error: cannot recover from previous errors .... 167:/* 168: * Structure used by kernel to store most addresses. 169: */ 170:struct sockaddr { 171: u_short sa_family; /* address family */ 172: char sa_data[14]; /* up to 14 bytes of direct address */ 173:}; 174: .... I've modified the patch to be less obtrusive my undefing _XOPEN_SOURCE on OpenServer only. We may end up removing the confdefs2.h parts later if we end up using define_xopen_source=no for OpenServer. As it stands now, with or without this patch, OpenServer doesn't build. This patch is really for SVR4.2 and SVR5 systems. (Ie. UnixWare) ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 13:08 Message: Logged In: YES user_id=618097 There may be a way. Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:51 Message: Logged In: YES user_id=21627 Now we are getting closer. What is the specific line in sys/socket.h that gives the syntax error? Are there alternative definitions of the (function, I suppose), either in socket.h or in another file? Why is u_int not defined when _XOPEN_SOURCE is? IOW: Are you absolutely, definitely, 100% certain that there is no way to compile sys/socket.h when _XOPEN_SOURCE is defined? That would be a serious bug in the system. Now, if we can establish with certainty that the system is broken beyond repair, it is acceptable to work around the bugs, by not defining _XOPEN_SOURCE. We then need to record the specific release of the system that we found is broken, and we need to document what specifically we found broken about it. For better reproducability, we also want to record the name of the person who determined the system being broken. We do all this in the hope that future system releases will be fixed by the system vendors, and that our work-arounds won't be needed anymore when we stop supporting old releases of the system (at a time when nobody uses those old releases anymore). I am not opposed to setting _define_xopen_source=no in principle (I once was, but am not any longer). I only want a convincing analysis that this is necessary to get essential parts of Python (such as sockets) to work. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:29 Message: Logged In: YES user_id=618097 Without u_short and u_int the soclklen_t test can NEVER suceed on OpenServer because of a syntax error in sys/socket.h whthout them. Ugly, but you don't seem to like the option of seting define_xopen_source=no on platforms that puilt fine prior to 2.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:18 Message: Logged In: YES user_id=21627 Why do you say "is needed for the socklen_t test"? Are you referring to the test in your patch? In this test, u_int is not *used* at all, it is only defined. So not defining it should not cause problems. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 12:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 11:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 10:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Sun May 11 21:18:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 13:18:50 -0700 Subject: [Patches] [ python-Patches-718286 ] DESTDIR variable patch Message-ID: Patches item #718286, was opened at 2003-04-09 16:44 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718286&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: wrobell (wrobell) >Assigned to: Martin v. Löwis (loewis) Summary: DESTDIR variable patch Initial Comment: This patch adds DESTDIR variable feature known from automake generated Makefile's. It simplifies packaging task and is useful for distro (i.e. PLD, RedHat, Debian) developers. For example, for rpm, one can specify in %install section: make install DESTDIR=$RPM_BUILD_ROOT then Python will be installed under $RPM_BUILD_ROOT directory. Otherwise distro developer is forced to specify: make install \ BINDIR=$RPM_BUILD_ROOT%{_bindir} \ SCRIPTDIR=$RPM_BUILD_ROOT%{_libdir} \ LIBDIR=$RPM_BUILD_ROOT%{_libdir} \ MANDIR=$RPM_BUILD_ROOT%{_mandir} \ INCLUDEDIR=$RPM_BUILD_ROOT%{_includedir} \ CONFINCLUDEDIR=$RPM_BUILD_ROOT%{_includedir} The patch has been tested on Linux. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2003-04-09 16:46 Message: Logged In: YES user_id=387193 Adding the patch due to current sf policy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718286&group_id=5470 From noreply@sourceforge.net Sun May 11 21:26:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 13:26:03 -0700 Subject: [Patches] [ python-Patches-718286 ] DESTDIR variable patch Message-ID: Patches item #718286, was opened at 2003-04-09 16:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718286&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: wrobell (wrobell) Assigned to: Martin v. Löwis (loewis) Summary: DESTDIR variable patch Initial Comment: This patch adds DESTDIR variable feature known from automake generated Makefile's. It simplifies packaging task and is useful for distro (i.e. PLD, RedHat, Debian) developers. For example, for rpm, one can specify in %install section: make install DESTDIR=$RPM_BUILD_ROOT then Python will be installed under $RPM_BUILD_ROOT directory. Otherwise distro developer is forced to specify: make install \ BINDIR=$RPM_BUILD_ROOT%{_bindir} \ SCRIPTDIR=$RPM_BUILD_ROOT%{_libdir} \ LIBDIR=$RPM_BUILD_ROOT%{_libdir} \ MANDIR=$RPM_BUILD_ROOT%{_mandir} \ INCLUDEDIR=$RPM_BUILD_ROOT%{_includedir} \ CONFINCLUDEDIR=$RPM_BUILD_ROOT%{_includedir} The patch has been tested on Linux. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 22:26 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as Makefile.pre.in 1.125 README 1.172 NEWS 1.764 ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2003-04-09 16:46 Message: Logged In: YES user_id=387193 Adding the patch due to current sf policy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718286&group_id=5470 From noreply@sourceforge.net Sun May 11 21:28:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 13:28:25 -0700 Subject: [Patches] [ python-Patches-735613 ] Python2.3b1 makefile improperly installs IDLE Message-ID: Patches item #735613, was opened at 2003-05-10 11:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735613&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Stearns (jeffstearns) Assigned to: Martin v. Löwis (loewis) Summary: Python2.3b1 makefile improperly installs IDLE Initial Comment: The Makefile.pre.in for Python 2.3b1 has a bug which may cause idle to be installed in the wrong place. The bug occurs at the idleinstall target. When the Makefile calls .../idle/setup.py, it passes --install-platlib, but it fails to pass --install-purelib. This means that setup.py will always try to install the .../idlelib/*.py files within /usr/local, regardless of what parameters are passed to the Makefile. The fix is to add --install-purelib=$(LIBDEST) to the rule for idleinstall. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 22:28 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as Makefile.pre.in 1.126. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735613&group_id=5470 From noreply@sourceforge.net Sun May 11 21:29:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 13:29:01 -0700 Subject: [Patches] [ python-Patches-735614 ] Python makefile may install idle in the wrong place Message-ID: Patches item #735614, was opened at 2003-05-10 11:18 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735614&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jeff Stearns (jeffstearns) Assigned to: Nobody/Anonymous (nobody) Summary: Python makefile may install idle in the wrong place Initial Comment: The Python makefile ignores some parameters when installing idle. This may cause the .../idle/*.py files to be installed to the wrong directory. The idleinstall target ignores the ${prefix} value in the Makefile. Instead, it always installs its *.py files below /usr/local/. Some of us don't install Python there. The fix is to add a missing line to Makefile.pre.in. Patch attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 08:03 Message: Logged In: YES user_id=21627 Is this a duplicate of 735613? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735614&group_id=5470 From noreply@sourceforge.net Mon May 12 00:24:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 16:24:34 -0700 Subject: [Patches] [ python-Patches-639139 ] Remove type-check from urllib2 Message-ID: Patches item #639139, was opened at 2002-11-15 14:25 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: John J Lee (jjlee) Assigned to: Brett Cannon (bcannon) Summary: Remove type-check from urllib2 Initial Comment: Remove undesirable type-checking assertion from urllib2.Request. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-11 16:24 Message: Logged In: YES user_id=357491 I am going to see if i can get someone to step in here and give me some advice on how to handle this. I personally have no issues ditching the check entirely. I just checked the module and it does not look like an AttributeError will be caught somewhere else in the code. But since Raymond only wanted to weaken the assertion and not remove it I feel the need to get someone else to choose a side on this to force which resolution is taken (status quo, hasattr, remove the check entirely). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-11 04:46 Message: Logged In: YES user_id=261020 No!! Ahem. Personally I wouldn't want to apply a patch like that -- I think it's inappropriate, since this is a violated precondition, and the patch you describe would add significant complexity (not to mention inefficiency, if I dare use that word here). The caller will get AttributeError anyway, with my patch, and though it wasn't my goal to pamper callers who mess up the call, that's actually not an unreasonable error. Would it convince you if I pointed out that my patch is simply EAFP again, at a different place in the call stack? If you don't like AttributeError being raised, you could always wrap up the five uses of req in try: except: blocks, but personally I don't think that's worth the added complexity or bug-masking risk. I don't know... first he tells me not to attribute check, then he wants to do it in a loop ;-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-10 22:33 Message: Logged In: YES user_id=357491 This is not what I meant by EAFP. In order for a patch to do that you would need to wrap all outgoing calls in that method that will use 'req' and see if the exception was because the object didn't have the proper interface. Good try, though. =) Doing it using hasattr in a loop is probably going to be the best bet. If you don't want to do the patch I will understand; I should have been more clear by what I was expecting for EAFP. Thus if you don't want to do it I will do the patch myself. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 04:58 Message: Logged In: YES user_id=261020 Is there a 'least interesting patch of the year' prize? My entry is attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 16:47 Message: Logged In: YES user_id=357491 =) OK. If you care to rewrite the patch using EAFP, then please do so. If not, then you just followup here saying you don't think the patch is worthing persuing any farther so I can close it? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 05:43 Message: Logged In: YES user_id=261020 Well, I think EAFP is probably best. An attribute check is in some sense the nearest thing to the assert that's there now, which is why my patch did that. OTOH, a method check seemed half-baked to me and so worse than an attribute check. it's not worth *too* much of our time :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 18:32 Message: Logged In: YES user_id=357491 It's not so much that the dummy attribute would break anything so much as it is just unneeded. If you want to make sure an object is not going to meet your required API you either just follow EAFP (Easier to Ask Forgiveness than Permission) or you explicitly test for the required interface. There is no good argument to have to flag an object to say that it meets an API spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 13:21 Message: Logged In: YES user_id=261020 Why not a new attribute? What would it break? Checking for the interface by checking all the methods (there are maybe ten of them) is not really practical, and really it's the intent that's the important bit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:57 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:55 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 06:46 Message: Logged In: YES user_id=261020 It's widely regarded as a bug if Python code checks for type with isinstance (or type(foo) == type(bar)) without some good reason. It's plausible that you may want to make an object that implements the Request interface without deriving from Request (say, I don't know, to implement the frobozz URI scheme, which requires ordered headers, and never has any data associated with it). If so, you don't want to have to follow 'bug fixes' in the Python std. library that may break your code simply because you had to derive from Request to satisfy the assertion. I might have done this when I wrote a couple of modules that build on urllib2, actually. I'm not sure whether that would have been the best way, because I didn't think about it since I didn't have any choice in the matter, thanks to this assertion! OTOH, it's true that removing type-checks can break backwards compatibility. However, this is an assertion, not a real runtime type-check, so it won't break backwards compatibility: if people are relying on catching AssertionError to do type-checking in their own code, that's their problem! The docs say: urlopen(url[, data]) Open the URL url, which can be either a string or a Request object (currently the code checks that it really is a Request instance, or an instance of a subclass of Request). Note the 'currently' (and the source code comment indicating that what we really want to check is the interface), and that fact that the code *doesn't* actually check it, but only asserts. Request interface is already documented, so there's no problem there. John ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 15:14 Message: Logged In: YES user_id=33168 John, could you explain why you need it and what is the benefit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 From noreply@sourceforge.net Mon May 12 00:26:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 16:26:04 -0700 Subject: [Patches] [ python-Patches-732394 ] Docs for test package Message-ID: Patches item #732394, was opened at 2003-05-04 16:09 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Docs for test package Initial Comment: Here is an attempt to document the test package. I tried to explain what the package is for, document test_support (but only things relevant to unittest tests; no need to push older-style tests), how to write a test for the package, and how to use regrtest.py (roughly). The only thing I am not sure on is what the preferred way to execute tests is anymore; is it run_suite or run_unittest from test_support? Now that run_unittest takes in *classes should we be pushing that since the code is shorter and less error-prone? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-11 16:26 Message: Logged In: YES user_id=357491 Since I uploaded the new files, tweaked Makefile.deps, and Fred has already taken at least one pass at fiddling with the file I am going to close this patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 15:07 Message: Logged In: YES user_id=33168 Doesn't doc/Makefile.deps need to be updated too? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-07 15:02 Message: Logged In: YES user_id=357491 Both are checked in. Want me to leave this patch open to remind you to take a look, Fred? Or should I go ahead and close it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-05-07 08:21 Message: Logged In: YES user_id=3066 Looks like LaTeX to me. This'll be easier to work with once it's in CVS, so go ahead and commit. Thanks! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 17:31 Message: Logged In: YES user_id=357491 Bah. This has not been my day at all. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 17:01 Message: Logged In: YES user_id=80475 The previous version got deleted but newer one did not take its place. The upload may have failed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 13:26 Message: Logged In: YES user_id=357491 First, thanks to both Raymond and Walter for looking for this. Second, I fixed everything both of them brought up sans merging Lib/test/ README into the doc as Walter suggested (read below for an explanation on why). Third, I don't want to merge in Lib/test/README since this is meant to replace it. I tried to use it as a guide to make sure everything in there gets covered in here (which is why there is a section on how to write a good regression test). Fourth, I will assign it to Fred but not check it in until he gets a chance to look at it and tells me to check it in. I will thus not touch lib.tex unless Fred tells me to. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-06 04:17 Message: Logged In: YES user_id=89016 A few other problems: Line 247: "Specifying a single regression", this should show how the call to regrtest looks like. Line 254: "turns enables" -> "enables" Line 257: "common-separated" -> "comma-separated" I think the description of black box testing and white box testing is reversed. (Compare Lib/test/README). Maybe we should combine both texts (libtest.tex and Lib/test/README)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 01:38 Message: Logged In: YES user_id=80475 This is a good looking document. Here are a few nits: --------------------------- line 23: [replace] "traditional" [with] ``traditional'' line 29: [add] \end{seealso} line 61: [replace] True [with] \constant{True} line 68: [replace] True [with] \constant{True} line 72: [replace] True [with] \constant{True} line 109: [consider noting the classes are broken into individual testcases using the rules for MakeSuite. Technically, the class itself is not executed. The test runner scans for methodnames starting with "test" and builds a suite of testcases.] line 190: [replace] bering [with] being line 191: [replace parenthetical with] testing only the published user interface line 215: [replace my error] self.func [with] func line 217: [eliminate my extraneous space before the open parenthesis] line 231: [delete] line 233: [delete] After fixing those, go ahead a load it or assign it to Fred for further review (he does that anyway). Then, add libtest.tex to lib.tex so it will appear in the index and become part of the build. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 01:03 Message: Logged In: YES user_id=357491 OK, following Raymond's suggestions, here is revised version of the docs. I tried to be terse and concrete, but it goes against my personal writing style (I used to get marked off for this when my philosophy classes because I refused to write dry papers; still haven't learned my lesson =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 23:46 Message: Logged In: YES user_id=80475 Well, it does have an air of near perfection ;) The content, accuracy, and completeness are ten times more important than the form :-) Most of the stuff is just a one element change. The abbreviations are just a style manual thing. When you write your second set of docs almost none of this will come up. Things like section markers and seealso's are pretty easy. The trick is to write docs by pasting in snippet's from other docs. I always find the nearest match (in form, not content) and keep it open while writing the docs. The attached script may help. It catches the kind of TeX errors that I tend to make. BTW, the hard knocks document may have understated this one a bit. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-05 22:43 Message: Logged In: YES user_id=357491 Ah nuts, Raymond. You were supposed to say it was perfect. =) OK, I will make the fixes and clean up the text to be more terse and sterile. So this is why people hate writing docs... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 16:31 Message: Logged In: YES user_id=80475 The \section title should indicate that the regression tests are for python itself. Add a seealso note referencing unittest and doctest. On line 78, \dict{sys.modules} should be \module {sys.modules}. On line 123, remove the exclamation point and explain the guideline rationale (docstrings get printed out, but comments don't). On line 194, add a closing parenthesis. On line 226, \Windows{} should be Windows. In either the guidelines section or the example section, show how common code can be factored out through subclassing (this question comes-up alot): class TestFuncAcceptsSequences(unittest.TestCase): self.func = mySuperWhammyFunction def test_func(self): self.func (self.arg) class AcceptLists(TestFuncAcceptsSequences): arg = [1,2,3] class AcceptStrings(TestFuncAcceptsSequences): arg = 'abc' class AcceptTuples(TestFuncAcceptsSequences): arg = (1,2,3) Everywhere. Do not use abbreviations like e.g., i.e. and etc. They do not transate well and Fred will come in behind you and remove them all. Change the voice to not speak directly to the reader. None of this: "you will most likely not use these modules directly". Instead try: "Except for test_support.py, most of these modules are not needed by user code". New tests do not *have to be* in unittest format. Instead, mention that the unittest format is more flexible and easier to extend for future maintainers. At the end, refer readers to Kent Beck's Test-Driven Development for more guidelines. Try to tighten-up the sentence structure to be much more terse and concrete. Avoid vague "recommended" or "prohibited" talk, instead giving fact based advantages and disadvantages. Consider a three or four part grouping: * First, collect all of the prose into one intro section. * Put the function/method description one section. * Put the examples/boilerplate in another. * Final collect the guidelines in a separate section. See libsets.tex and libitertools.tex to see how it's done and what it looks like. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-05 15:33 Message: Logged In: YES user_id=80475 Yes, run_unittest(*classes) is the most general and requires the least boilerplate. Will read through your docs tonight. Thanks for the effort to take this beyond (read the code to figure out what it does). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732394&group_id=5470 From noreply@sourceforge.net Mon May 12 00:27:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 16:27:49 -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: None Status: Open Resolution: None 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-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 Mon May 12 01:59:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 17:59:59 -0700 Subject: [Patches] [ python-Patches-639139 ] Remove type-check from urllib2 Message-ID: Patches item #639139, was opened at 2002-11-15 22:25 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: John J Lee (jjlee) Assigned to: Brett Cannon (bcannon) Summary: Remove type-check from urllib2 Initial Comment: Remove undesirable type-checking assertion from urllib2.Request. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-05-12 01:59 Message: Logged In: YES user_id=261020 Oh, is it really worth any more of everyone's time, I wonder? I didn't anticipate a big discussion. Let's just leave it at the status-quo, shell we? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 00:24 Message: Logged In: YES user_id=357491 I am going to see if i can get someone to step in here and give me some advice on how to handle this. I personally have no issues ditching the check entirely. I just checked the module and it does not look like an AttributeError will be caught somewhere else in the code. But since Raymond only wanted to weaken the assertion and not remove it I feel the need to get someone else to choose a side on this to force which resolution is taken (status quo, hasattr, remove the check entirely). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-11 12:46 Message: Logged In: YES user_id=261020 No!! Ahem. Personally I wouldn't want to apply a patch like that -- I think it's inappropriate, since this is a violated precondition, and the patch you describe would add significant complexity (not to mention inefficiency, if I dare use that word here). The caller will get AttributeError anyway, with my patch, and though it wasn't my goal to pamper callers who mess up the call, that's actually not an unreasonable error. Would it convince you if I pointed out that my patch is simply EAFP again, at a different place in the call stack? If you don't like AttributeError being raised, you could always wrap up the five uses of req in try: except: blocks, but personally I don't think that's worth the added complexity or bug-masking risk. I don't know... first he tells me not to attribute check, then he wants to do it in a loop ;-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 06:33 Message: Logged In: YES user_id=357491 This is not what I meant by EAFP. In order for a patch to do that you would need to wrap all outgoing calls in that method that will use 'req' and see if the exception was because the object didn't have the proper interface. Good try, though. =) Doing it using hasattr in a loop is probably going to be the best bet. If you don't want to do the patch I will understand; I should have been more clear by what I was expecting for EAFP. Thus if you don't want to do it I will do the patch myself. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 12:58 Message: Logged In: YES user_id=261020 Is there a 'least interesting patch of the year' prize? My entry is attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-10 00:47 Message: Logged In: YES user_id=357491 =) OK. If you care to rewrite the patch using EAFP, then please do so. If not, then you just followup here saying you don't think the patch is worthing persuing any farther so I can close it? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 13:43 Message: Logged In: YES user_id=261020 Well, I think EAFP is probably best. An attribute check is in some sense the nearest thing to the assert that's there now, which is why my patch did that. OTOH, a method check seemed half-baked to me and so worse than an attribute check. it's not worth *too* much of our time :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 02:32 Message: Logged In: YES user_id=357491 It's not so much that the dummy attribute would break anything so much as it is just unneeded. If you want to make sure an object is not going to meet your required API you either just follow EAFP (Easier to Ask Forgiveness than Permission) or you explicitly test for the required interface. There is no good argument to have to flag an object to say that it meets an API spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 21:21 Message: Logged In: YES user_id=261020 Why not a new attribute? What would it break? Checking for the interface by checking all the methods (there are maybe ten of them) is not really practical, and really it's the intent that's the important bit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 17:57 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 17:55 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 14:46 Message: Logged In: YES user_id=261020 It's widely regarded as a bug if Python code checks for type with isinstance (or type(foo) == type(bar)) without some good reason. It's plausible that you may want to make an object that implements the Request interface without deriving from Request (say, I don't know, to implement the frobozz URI scheme, which requires ordered headers, and never has any data associated with it). If so, you don't want to have to follow 'bug fixes' in the Python std. library that may break your code simply because you had to derive from Request to satisfy the assertion. I might have done this when I wrote a couple of modules that build on urllib2, actually. I'm not sure whether that would have been the best way, because I didn't think about it since I didn't have any choice in the matter, thanks to this assertion! OTOH, it's true that removing type-checks can break backwards compatibility. However, this is an assertion, not a real runtime type-check, so it won't break backwards compatibility: if people are relying on catching AssertionError to do type-checking in their own code, that's their problem! The docs say: urlopen(url[, data]) Open the URL url, which can be either a string or a Request object (currently the code checks that it really is a Request instance, or an instance of a subclass of Request). Note the 'currently' (and the source code comment indicating that what we really want to check is the interface), and that fact that the code *doesn't* actually check it, but only asserts. Request interface is already documented, so there's no problem there. John ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 23:14 Message: Logged In: YES user_id=33168 John, could you explain why you need it and what is the benefit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 From noreply@sourceforge.net Mon May 12 04:05:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 20:05:06 -0700 Subject: [Patches] [ python-Patches-735614 ] Python makefile may install idle in the wrong place Message-ID: Patches item #735614, was opened at 2003-05-10 02:18 Message generated for change (Comment added) made by jeffstearns You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735614&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Jeff Stearns (jeffstearns) Assigned to: Nobody/Anonymous (nobody) Summary: Python makefile may install idle in the wrong place Initial Comment: The Python makefile ignores some parameters when installing idle. This may cause the .../idle/*.py files to be installed to the wrong directory. The idleinstall target ignores the ${prefix} value in the Makefile. Instead, it always installs its *.py files below /usr/local/. Some of us don't install Python there. The fix is to add a missing line to Makefile.pre.in. Patch attached. ---------------------------------------------------------------------- >Comment By: Jeff Stearns (jeffstearns) Date: 2003-05-11 20:05 Message: Logged In: YES user_id=660929 Yes, this is a duplicate of 735613. My browser crashed while I was submitting that one. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 23:03 Message: Logged In: YES user_id=21627 Is this a duplicate of 735613? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735614&group_id=5470 From noreply@sourceforge.net Mon May 12 05:23:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 21:23:45 -0700 Subject: [Patches] [ python-Patches-731991 ] find correct socklen_t type Message-ID: Patches item #731991, was opened at 2003-05-04 01:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: find correct socklen_t type Initial Comment: This patch adds code to configure.in to determine the correct data type for socklen_t if socklen_t is not defined by the system. Credit for the socklen_t autoconf magic goes to Albert Chin (china@thewrittenword.com) I've also fixed some sections of Modules/socketmodule.c that should have used socklen_t. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-12 06:23 Message: Logged In: YES user_id=21627 It is fine to chose getpeername for the test. I don't understand why the test features a *call* to getpeername, if the expected error is an incorrect redeclaration. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-11 19:57 Message: Logged In: YES user_id=618097 Yes these are warnings. But then warnings are there so you'll look at the code and correct if necessary. If you're nervous about the autoconf test that's fine. I can always correct pyconfig.h after configure runs. But the Modules/socketmodule.c patch should be applied. The code there is just pain wrong. I've used the autoconf bits in OpenSSH and now in my local Python 2.3 tree. I've been using the socketmodule patch since the 2.2.2 beta days. But 2.2.2 uses autoconf 2.13 so the autoconf bits don't work there. I don't know why Albert chose getpeername for the test. I strongly suspect you could use accept, getsockopt, getsockname, recvfrom, or any socket call that has the length option you're testing for. On UnixWare the test progtram (using int) produces the error identifier redeclared: getpeername causing cc to return with a non 0. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 08:01 Message: Logged In: YES user_id=21627 So these are all warnings only? I'm not sure I want to risk breaking compilation on other systems to get rid of these warnings this late in the beta cycle. When you say you have used this: Do you mean in combination with OpenSSH, or with Python? On the "how it works" issue: How precisely does it cause the compiler to produce a status code? I.e. what in the test program does it assume to give an error? In particular: Why does it call getpeername? ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-10 23:10 Message: Logged In: YES user_id=618097 The errors: UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1100: argument #3 incompatible with prototype: accept() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1319: argument #5 incompatible with prototype: _getsockopt() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1337: argument #5 incompatible with prototype: _getsockopt() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1571: argument #3 incompatible with prototype: getsockname() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1599: argument #3 incompatible with prototype: getpeername() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 1833: argument #6 incompatible with prototype: recvfrom() UX:acomp: WARNING: "/opt/src/utils/python/python/dist/src/Modules/socketmodule.c", line 2963: statement not reached How it works: First it tests if the system supports socklen_t data type. If not, it loops through compiling a test program and testing the compiler's return code. It tries using int, size_t, unsigned, long, and then "unsigned long". I've personaly used this on UnixWare 2.03, UnixWare 2.1.3, UnixWare 7.x SCO OpenServer 3, SCO OpenServer 5, several flavors of Caldera Linux, RedHat 6.2, Solaris 7, & Solaris 8. Looking at http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=100174342829230&w=2 ..... > tested successfully on: > Solaris 2.5.1, 2.6, 7, 8/SPARC, HP-UX 10.20, 11.00, > Tru64 UNIX 4.0D, 5.0A, 5.1, IRIX 6.2, 6.5, AIX 4.3.2. Rsync also features on the Samba build farm (see below), building and testing on over 20 platforms, so its safe to say its portable... Andrew Bartlett ..... socklen-4.patch is against 10 May 2003 CVS ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 07:18 Message: Logged In: YES user_id=21627 I have now disabled _XOPEN_SOURCE for this system. Before applying a patch like this one, I'd like to know a) how it works (see my first comment) b) what specific error it fixes on UnixWare. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 23:39 Message: Logged In: YES user_id=618097 That was a waste of time. I mis read sys/types.h on OpenServer u_int and u_short are not defined because they are warped inside #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) #endif /* !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) */ The error is "/usr/include/sys/socket.h", line 171: error: Syntax error before or at: u_short "/usr/include/sys/socket.h", line 171: error: cannot recover from previous errors .... 167:/* 168: * Structure used by kernel to store most addresses. 169: */ 170:struct sockaddr { 171: u_short sa_family; /* address family */ 172: char sa_data[14]; /* up to 14 bytes of direct address */ 173:}; 174: .... I've modified the patch to be less obtrusive my undefing _XOPEN_SOURCE on OpenServer only. We may end up removing the confdefs2.h parts later if we end up using define_xopen_source=no for OpenServer. As it stands now, with or without this patch, OpenServer doesn't build. This patch is really for SVR4.2 and SVR5 systems. (Ie. UnixWare) ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 22:08 Message: Logged In: YES user_id=618097 There may be a way. Hold off until I test defining _POSIX_SOURCE ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:51 Message: Logged In: YES user_id=21627 Now we are getting closer. What is the specific line in sys/socket.h that gives the syntax error? Are there alternative definitions of the (function, I suppose), either in socket.h or in another file? Why is u_int not defined when _XOPEN_SOURCE is? IOW: Are you absolutely, definitely, 100% certain that there is no way to compile sys/socket.h when _XOPEN_SOURCE is defined? That would be a serious bug in the system. Now, if we can establish with certainty that the system is broken beyond repair, it is acceptable to work around the bugs, by not defining _XOPEN_SOURCE. We then need to record the specific release of the system that we found is broken, and we need to document what specifically we found broken about it. For better reproducability, we also want to record the name of the person who determined the system being broken. We do all this in the hope that future system releases will be fixed by the system vendors, and that our work-arounds won't be needed anymore when we stop supporting old releases of the system (at a time when nobody uses those old releases anymore). I am not opposed to setting _define_xopen_source=no in principle (I once was, but am not any longer). I only want a convincing analysis that this is necessary to get essential parts of Python (such as sockets) to work. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 21:29 Message: Logged In: YES user_id=618097 Without u_short and u_int the soclklen_t test can NEVER suceed on OpenServer because of a syntax error in sys/socket.h whthout them. Ugly, but you don't seem to like the option of seting define_xopen_source=no on platforms that puilt fine prior to 2.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 21:18 Message: Logged In: YES user_id=21627 Why do you say "is needed for the socklen_t test"? Are you referring to the test in your patch? In this test, u_int is not *used* at all, it is only defined. So not defining it should not cause problems. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 21:05 Message: Logged In: YES user_id=618097 u_int is needed for the socklen_t test by sys/socket.h on SCO OpenServer The u_int test towards the top of configure.in is also needed by patch # 732284 for UnixWare 7 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 20:56 Message: Logged In: YES user_id=21627 Why do you need to define u_int? Python does not use this type, so it should be irrelevant whether it is defined or not. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2003-05-04 19:50 Message: Logged In: YES user_id=618097 Looking at it again, undefing _XOPEN_SOURCE is not a good idea. Yes you'll miss the data types in socketmodule.c too but they will be addressed in another patch to Include/pyport.h which is not included in the configure tests. I haven't taken the time to analize why it works (I didn't write it). It's been working fine on a wide range of platforms for over a year in OpenSSH portable. I wanted to get it in 2.2.2 but it requires autoconf 2.52 or newer. I've personaly tested on Linux, Solaris, UnixWare, OpenServer. UnixWare uses size_t and OpenServer uses int. My new patch gets rid of AC_DEFUN and adds some data type tests. Two of the data type tests (u_char & u_long) are not needed by the socklen_t test but will be needed by a UnixWare 7 patch that I'll post shortly. Expect some fuz in the patch. I'm breaking up a large patch into understanable chunks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:29 Message: Logged In: YES user_id=21627 Why do you #undef _XOPEN_SOURCE? If you "miss data types without this", won't you miss the same data types when compiling socketmodule.c? How does the test work? What kind of failure do you expect when "trying the wrong type? On what platforms has this change be tested? What platforms did the old test fail on? What types do these systems use for socklen_t? Please lose the AC_DEFUN; AFAICT, it is used only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731991&group_id=5470 From noreply@sourceforge.net Mon May 12 07:55:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 23:55:36 -0700 Subject: [Patches] [ python-Patches-639139 ] Remove type-check from urllib2 Message-ID: Patches item #639139, was opened at 2002-11-15 14:25 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Pending >Resolution: Accepted Priority: 3 Submitted By: John J Lee (jjlee) Assigned to: Brett Cannon (bcannon) Summary: Remove type-check from urllib2 Initial Comment: Remove undesirable type-checking assertion from urllib2.Request. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-11 23:55 Message: Logged In: YES user_id=357491 Too late, I got approval. =) I have to anyway, John, since this is one of the first patches I have handled personally. The assert will be removed some time this week. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-11 17:59 Message: Logged In: YES user_id=261020 Oh, is it really worth any more of everyone's time, I wonder? I didn't anticipate a big discussion. Let's just leave it at the status-quo, shell we? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 16:24 Message: Logged In: YES user_id=357491 I am going to see if i can get someone to step in here and give me some advice on how to handle this. I personally have no issues ditching the check entirely. I just checked the module and it does not look like an AttributeError will be caught somewhere else in the code. But since Raymond only wanted to weaken the assertion and not remove it I feel the need to get someone else to choose a side on this to force which resolution is taken (status quo, hasattr, remove the check entirely). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-11 04:46 Message: Logged In: YES user_id=261020 No!! Ahem. Personally I wouldn't want to apply a patch like that -- I think it's inappropriate, since this is a violated precondition, and the patch you describe would add significant complexity (not to mention inefficiency, if I dare use that word here). The caller will get AttributeError anyway, with my patch, and though it wasn't my goal to pamper callers who mess up the call, that's actually not an unreasonable error. Would it convince you if I pointed out that my patch is simply EAFP again, at a different place in the call stack? If you don't like AttributeError being raised, you could always wrap up the five uses of req in try: except: blocks, but personally I don't think that's worth the added complexity or bug-masking risk. I don't know... first he tells me not to attribute check, then he wants to do it in a loop ;-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-10 22:33 Message: Logged In: YES user_id=357491 This is not what I meant by EAFP. In order for a patch to do that you would need to wrap all outgoing calls in that method that will use 'req' and see if the exception was because the object didn't have the proper interface. Good try, though. =) Doing it using hasattr in a loop is probably going to be the best bet. If you don't want to do the patch I will understand; I should have been more clear by what I was expecting for EAFP. Thus if you don't want to do it I will do the patch myself. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 04:58 Message: Logged In: YES user_id=261020 Is there a 'least interesting patch of the year' prize? My entry is attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 16:47 Message: Logged In: YES user_id=357491 =) OK. If you care to rewrite the patch using EAFP, then please do so. If not, then you just followup here saying you don't think the patch is worthing persuing any farther so I can close it? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 05:43 Message: Logged In: YES user_id=261020 Well, I think EAFP is probably best. An attribute check is in some sense the nearest thing to the assert that's there now, which is why my patch did that. OTOH, a method check seemed half-baked to me and so worse than an attribute check. it's not worth *too* much of our time :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 18:32 Message: Logged In: YES user_id=357491 It's not so much that the dummy attribute would break anything so much as it is just unneeded. If you want to make sure an object is not going to meet your required API you either just follow EAFP (Easier to Ask Forgiveness than Permission) or you explicitly test for the required interface. There is no good argument to have to flag an object to say that it meets an API spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 13:21 Message: Logged In: YES user_id=261020 Why not a new attribute? What would it break? Checking for the interface by checking all the methods (there are maybe ten of them) is not really practical, and really it's the intent that's the important bit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:57 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:55 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 06:46 Message: Logged In: YES user_id=261020 It's widely regarded as a bug if Python code checks for type with isinstance (or type(foo) == type(bar)) without some good reason. It's plausible that you may want to make an object that implements the Request interface without deriving from Request (say, I don't know, to implement the frobozz URI scheme, which requires ordered headers, and never has any data associated with it). If so, you don't want to have to follow 'bug fixes' in the Python std. library that may break your code simply because you had to derive from Request to satisfy the assertion. I might have done this when I wrote a couple of modules that build on urllib2, actually. I'm not sure whether that would have been the best way, because I didn't think about it since I didn't have any choice in the matter, thanks to this assertion! OTOH, it's true that removing type-checks can break backwards compatibility. However, this is an assertion, not a real runtime type-check, so it won't break backwards compatibility: if people are relying on catching AssertionError to do type-checking in their own code, that's their problem! The docs say: urlopen(url[, data]) Open the URL url, which can be either a string or a Request object (currently the code checks that it really is a Request instance, or an instance of a subclass of Request). Note the 'currently' (and the source code comment indicating that what we really want to check is the interface), and that fact that the code *doesn't* actually check it, but only asserts. Request interface is already documented, so there's no problem there. John ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 15:14 Message: Logged In: YES user_id=33168 John, could you explain why you need it and what is the benefit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 From noreply@sourceforge.net Mon May 12 07:56:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 23:56:18 -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 (Settings changed) 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: None >Status: Pending >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-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 Mon May 12 08:30:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 00:30:25 -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: None >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-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 Mon May 12 08:32:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 00:32:21 -0700 Subject: [Patches] [ python-Patches-639139 ] Remove type-check from urllib2 Message-ID: Patches item #639139, was opened at 2002-11-15 14:25 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 3 Submitted By: John J Lee (jjlee) Assigned to: Brett Cannon (bcannon) Summary: Remove type-check from urllib2 Initial Comment: Remove undesirable type-checking assertion from urllib2.Request. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 00:32 Message: Logged In: YES user_id=357491 Applied as Lib/urllib2.py 1.44 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 23:55 Message: Logged In: YES user_id=357491 Too late, I got approval. =) I have to anyway, John, since this is one of the first patches I have handled personally. The assert will be removed some time this week. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-11 17:59 Message: Logged In: YES user_id=261020 Oh, is it really worth any more of everyone's time, I wonder? I didn't anticipate a big discussion. Let's just leave it at the status-quo, shell we? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 16:24 Message: Logged In: YES user_id=357491 I am going to see if i can get someone to step in here and give me some advice on how to handle this. I personally have no issues ditching the check entirely. I just checked the module and it does not look like an AttributeError will be caught somewhere else in the code. But since Raymond only wanted to weaken the assertion and not remove it I feel the need to get someone else to choose a side on this to force which resolution is taken (status quo, hasattr, remove the check entirely). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-11 04:46 Message: Logged In: YES user_id=261020 No!! Ahem. Personally I wouldn't want to apply a patch like that -- I think it's inappropriate, since this is a violated precondition, and the patch you describe would add significant complexity (not to mention inefficiency, if I dare use that word here). The caller will get AttributeError anyway, with my patch, and though it wasn't my goal to pamper callers who mess up the call, that's actually not an unreasonable error. Would it convince you if I pointed out that my patch is simply EAFP again, at a different place in the call stack? If you don't like AttributeError being raised, you could always wrap up the five uses of req in try: except: blocks, but personally I don't think that's worth the added complexity or bug-masking risk. I don't know... first he tells me not to attribute check, then he wants to do it in a loop ;-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-10 22:33 Message: Logged In: YES user_id=357491 This is not what I meant by EAFP. In order for a patch to do that you would need to wrap all outgoing calls in that method that will use 'req' and see if the exception was because the object didn't have the proper interface. Good try, though. =) Doing it using hasattr in a loop is probably going to be the best bet. If you don't want to do the patch I will understand; I should have been more clear by what I was expecting for EAFP. Thus if you don't want to do it I will do the patch myself. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 04:58 Message: Logged In: YES user_id=261020 Is there a 'least interesting patch of the year' prize? My entry is attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 16:47 Message: Logged In: YES user_id=357491 =) OK. If you care to rewrite the patch using EAFP, then please do so. If not, then you just followup here saying you don't think the patch is worthing persuing any farther so I can close it? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 05:43 Message: Logged In: YES user_id=261020 Well, I think EAFP is probably best. An attribute check is in some sense the nearest thing to the assert that's there now, which is why my patch did that. OTOH, a method check seemed half-baked to me and so worse than an attribute check. it's not worth *too* much of our time :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 18:32 Message: Logged In: YES user_id=357491 It's not so much that the dummy attribute would break anything so much as it is just unneeded. If you want to make sure an object is not going to meet your required API you either just follow EAFP (Easier to Ask Forgiveness than Permission) or you explicitly test for the required interface. There is no good argument to have to flag an object to say that it meets an API spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 13:21 Message: Logged In: YES user_id=261020 Why not a new attribute? What would it break? Checking for the interface by checking all the methods (there are maybe ten of them) is not really practical, and really it's the intent that's the important bit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:57 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-17 09:55 Message: Logged In: YES user_id=80475 I see no problem with weakening the assertion, but hasattr should check for a required part of the interface instead of a new, undocumented, dummy attribute. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-11-17 06:46 Message: Logged In: YES user_id=261020 It's widely regarded as a bug if Python code checks for type with isinstance (or type(foo) == type(bar)) without some good reason. It's plausible that you may want to make an object that implements the Request interface without deriving from Request (say, I don't know, to implement the frobozz URI scheme, which requires ordered headers, and never has any data associated with it). If so, you don't want to have to follow 'bug fixes' in the Python std. library that may break your code simply because you had to derive from Request to satisfy the assertion. I might have done this when I wrote a couple of modules that build on urllib2, actually. I'm not sure whether that would have been the best way, because I didn't think about it since I didn't have any choice in the matter, thanks to this assertion! OTOH, it's true that removing type-checks can break backwards compatibility. However, this is an assertion, not a real runtime type-check, so it won't break backwards compatibility: if people are relying on catching AssertionError to do type-checking in their own code, that's their problem! The docs say: urlopen(url[, data]) Open the URL url, which can be either a string or a Request object (currently the code checks that it really is a Request instance, or an instance of a subclass of Request). Note the 'currently' (and the source code comment indicating that what we really want to check is the interface), and that fact that the code *doesn't* actually check it, but only asserts. Request interface is already documented, so there's no problem there. John ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 15:14 Message: Logged In: YES user_id=33168 John, could you explain why you need it and what is the benefit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=639139&group_id=5470 From noreply@sourceforge.net Mon May 12 08:38:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 00:38:25 -0700 Subject: [Patches] [ python-Patches-726751 ] Clarify docs for except target assignment Message-ID: Patches item #726751, was opened at 2003-04-24 01:30 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726751&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Clarify docs for except target assignment Initial Comment: I have always found the docs dealing with the target as found in 'except' clauses misleading:: try: raise Exception('argument 1') except Exception, x: print type(x) This code outputs ```` while I would have expected ```` from the way the docs read (at least to me). So I tried to clarify this in the tutorial and references (Doc/tut/tut.tex and Doc/ref/ref7.tex respectively). If people think I am nuts and people don't get confused by the fact that having a single target gets the exception instance assigned to it while a tuple of targets gets the exception to unpack its arg values through iterating over them with the way the docs are now, then I guess I am nuts. =) Regardless of the final outcome of this patch, the result will close/ reject bug #675928 . ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 00:38 Message: Logged In: YES user_id=357491 Fair enough. Do you want me to keep this patch open as a reminder to you, Fred, or should I just go ahead and reject it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-04-25 10:11 Message: Logged In: YES user_id=3066 There's definately a shortcoming in those docs; they really still assume the world of string exceptions. The patch, on the other hand, somewhat assumes a world of class-based exceptions. The reality is a bit more conflated; I'll see what I can do about it, but I don't think the patch as it stands is really right either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726751&group_id=5470 From noreply@sourceforge.net Mon May 12 11:31:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 03:31:21 -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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: DESTDIR improvement Initial Comment: Byte compile correctly with DESTDIR. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736413&group_id=5470 From noreply@sourceforge.net Mon May 12 11:44:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 03:44:39 -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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None 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.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736417&group_id=5470 From noreply@sourceforge.net Mon May 12 23:52:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 15:52:44 -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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736730&group_id=5470 From noreply@sourceforge.net Tue May 13 00:05:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 16:05:22 -0700 Subject: [Patches] [ python-Patches-736730 ] Trivial improvement to NameError message Message-ID: Patches item #736730, was opened at 2003-05-12 15:52 Message generated for change (Comment added) made by bcannon 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: Open Resolution: None 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: Brett Cannon (bcannon) Date: 2003-05-12 16: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 Tue May 13 00:16:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 16:16:53 -0700 Subject: [Patches] [ python-Patches-736730 ] Trivial improvement to NameError message Message-ID: Patches item #736730, was opened at 2003-05-12 18: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=736730&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None 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: Tim Peters (tim_one) Date: 2003-05-12 19: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 19: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 Tue May 13 01:57:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 17:57:36 -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: Open Resolution: None 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-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 Tue May 13 02:27:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 18:27:44 -0700 Subject: [Patches] [ python-Patches-736730 ] Trivial improvement to NameError message Message-ID: Patches item #736730, was opened at 2003-05-12 18: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=736730&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None 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: Tim Peters (tim_one) Date: 2003-05-12 21: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 20: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 19: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 19: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 Tue May 13 02:37:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 18:37:58 -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: Open Resolution: None 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-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 Tue May 13 03:05:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:05:39 -0700 Subject: [Patches] [ python-Patches-477441 ] Mutable PyCObject Message-ID: Patches item #477441, was opened at 2001-11-02 01:02 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=477441&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Abbott (araneidae) Assigned to: Nobody/Anonymous (nobody) Summary: Mutable PyCObject Initial Comment: I'd like to add the following code to Core\Objects\cobject.c together with the associated declaration in include\cobject.h . The purpose of this is to allow PyCObjects to be mutable when required. Obviously this doesn't change the language semantics, but is a convenience in the implementation of certain Python extensions. /* The void pointer already in the given PyCObject is replaced with the given * new value. The caller is responsible for first checking that the given * PyObject really is a PyCObject. */ void PyCObject_SetVoidPtr(PyObject *self, void *cobj) { ((PyCObject *)self)->cobject = cobj; } (I'm not to sure about the procedure for submissions of this type!) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:05 Message: Logged In: YES user_id=357491 Since the code is actually in the summary I am going to make this a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=477441&group_id=5470 From noreply@sourceforge.net Tue May 13 04:49:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 20:49:28 -0700 Subject: [Patches] [ python-Patches-677651 ] ConfigParser.read() should return list of files read Message-ID: Patches item #677651, was opened at 2003-01-30 10:53 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677651&group_id=5470 >Category: None Group: None Status: Open Resolution: None >Priority: 3 Submitted By: John Belmonte (jbelmonte) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser.read() should return list of files read Initial Comment: Regarding ConfigParser.ConfigParser: When debugging or when the user of a command line tool requests verbose output, it is useful to report exactly which files the configuration has been read from. If this is required, ConfigParser.read() is not useful. Attached is a patch to make ConfigParser.read() return a list of files it has read from. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 20:49 Message: Logged In: YES user_id=357491 Since this has actual code I am making this a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677651&group_id=5470 From noreply@sourceforge.net Tue May 13 07:23:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 23:23:42 -0700 Subject: [Patches] [ python-Patches-736857 ] interpreter final destination location Message-ID: Patches item #736857, was opened at 2003-05-12 23:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736857&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Magill (tmagill) Assigned to: Nobody/Anonymous (nobody) Summary: interpreter final destination location Initial Comment: New command line option to specify the string to be substituted in the "#!" line at the beginning of scripts ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736857&group_id=5470 From noreply@sourceforge.net Tue May 13 07:31:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 23:31:17 -0700 Subject: [Patches] [ python-Patches-736859 ] docs for interpreter final destination location Message-ID: Patches item #736859, was opened at 2003-05-12 23: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=736859&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Magill (tmagill) Assigned to: Nobody/Anonymous (nobody) Summary: docs for interpreter final destination location Initial Comment: documentation fragment for new command line option to specify the string to be substituted in the "#!" line at the beginning of scripts ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736859&group_id=5470 From noreply@sourceforge.net Tue May 13 11:45:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 03:45:17 -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 (Tracker Item Submitted) made by Item Submitter 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: None 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%) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply@sourceforge.net Tue May 13 13:57:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 05:57:18 -0700 Subject: [Patches] [ python-Patches-628208 ] xmlrpclib: Optional 'nil' support Message-ID: Patches item #628208, was opened at 2002-10-24 15:33 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: xmlrpclib: Optional 'nil' support Initial Comment: This patch doesn't include documentation or test suite updates yet, and only touches the < The extension is defined at http://ontosys.com/xml-rpc/extensions.html. Outstanding questions: * To generate , an option must be explicitly supplied to dumps(). is always accepted, and it can't be turned off. Is this OK? * Similarly, allow_none is on or off for a ServerProxy; you can't turn it on for just one method. (Seems a reasonable limitation...) * Should the parameter to enable it be named allow_none (Python term) or allow_nil (XML-RPC term)? * When allow_none is false and a None is encountered, this patch raises a ValueError. Is that the right exception, or should it use xmlrpclib.Error? Can anyone suggest a better message for the exception? * The FastMarshaller accelerator would also need to be updated. * Are we ever likely to change the default for allow_none to True? If so, how should we arrange things so we can warn people? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-25 21:20 Message: Logged In: YES user_id=33168 This was checked in. Is there anything left to do or should this patch be closed? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-04-20 15:06 Message: Logged In: YES user_id=11375 Should I leave the name of the 'allow_none' parameter alone, or should I change it to 'strict' and default it to True? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 04:01 Message: Logged In: YES user_id=21627 Since /F seems unresponsive, I'll accept the patch, on the provision that it is integrated before Python 2.3b1 (or after Python 2.3 is released), and that a documentation change is also committed. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-10-29 11:44 Message: Logged In: YES user_id=11375 Updated version of the patch: raises TypeError instead of ValueError, and uses Martin's suggested wording; thanks! Now it's up to /F to accept, decline, or request revisions to this patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 15:50 Message: Logged In: YES user_id=21627 On the exception: Currently, you get TypeError: cannot marshal objects and TypeError seems to be the right thing. The message might read cannot marshal None unless allow_none is enabled On allowing None by default: I'd assume that you would want to disable None only for "strictly-conforming" operation, so I'd expect to see an option strict (which then defaults to False). I don't know in what other ways we'd reasonably deviate from the spec. If that ever happens, I don't think a transitional warning is needed: existing applications continue to work. In general, in cases that produce an exception now, we don't need a transition procedure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 From noreply@sourceforge.net Tue May 13 14:10:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 06:10:18 -0700 Subject: [Patches] [ python-Patches-717152 ] has_function() method for CCompiler Message-ID: Patches item #717152, was opened at 2003-04-07 20:50 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717152&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: A.M. Kuchling (akuchling) Summary: has_function() method for CCompiler Initial Comment: On the psycopg mailing list, Federico bemoaned the problem figuring out via distutils if a particular platform contains an implementation for asprintf(). I wrote the attached method as a starting point for such functionality in distutils. It's been barely tested at all, but seems to me to be a reasonable addition to the set of stuff distutils can check for. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 09:10 Message: Logged In: YES user_id=11375 Checked in. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-04-07 20:56 Message: Logged In: YES user_id=44345 Also note a number of known nits: * it doesn't yet clean up after itself * it doesn't yet suppress messages to stderr * I haven't tested it in any but the simplest of cases ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717152&group_id=5470 From noreply@sourceforge.net Wed May 14 05:18:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 21:18:42 -0700 Subject: [Patches] [ python-Patches-732143 ] exit status of latex2html "ignored" Message-ID: Patches item #732143, was opened at 2003-05-04 07:29 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732143&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: exit status of latex2html "ignored" Initial Comment: latex2html discovered an error building the lib html docs. It correctly prints: *** Session transcript and error messages are in /build/packages/python2.3/python2.3-2.2.102/Doc/html/lib/lib.how. *** Exited with status 25. The relevant lines from the transcript are: [...] but then exits with an exit status of 1, which lets make continue and makes it harder to find the actual error. Not sure, if this is the correct fix, but why not exit with the error you show the user? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-05-14 00:18 Message: Logged In: YES user_id=3066 Fixed using a slightly different patch in Doc/tools/mkhowto 1.39. When a child process exits normally, the result code of the child is used as the result code for mkhowto; all other error exits cause mkhowto to return a result code of 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732143&group_id=5470 From noreply@sourceforge.net Wed May 14 06:44:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 22:44:48 -0700 Subject: [Patches] [ python-Patches-737473 ] traceback module caches sources invalid Message-ID: Patches item #737473, was opened at 2003-05-14 14:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737473&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: traceback module caches sources invalid Initial Comment: traceback.{extract,print}_tb function doesn't check source code's mtime validity. attached script copies the bug situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737473&group_id=5470 From noreply@sourceforge.net Thu May 15 02:55:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 18:55:28 -0700 Subject: [Patches] [ python-Patches-737999 ] minor codeop fixes Message-ID: Patches item #737999, was opened at 2003-05-15 03: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=737999&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Michael Hudson (mwh) Summary: minor codeop fixes Initial Comment: *) compile_command("",eval) -> None , previously raised syntax error about "pass" *) symbol must be eval or single, now raises ValueError accordingly as specified in the documentation patch both for 2.3 and 2.2 maint for codeop.py and test/test_codeop.py (beefed up) (for Jython at the moment we use the test suite of 2.2 maint, that's why this is relevant) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737999&group_id=5470 From noreply@sourceforge.net Thu May 15 04:56:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 20:56:58 -0700 Subject: [Patches] [ python-Patches-730603 ] socketmodule inet_ntop built when IPV6 is disabled Message-ID: Patches item #730603, was opened at 2003-05-01 15:05 Message generated for change (Comment added) made by cjohns You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730603&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Johns (cjohns) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule inet_ntop built when IPV6 is disabled Initial Comment: RTEMS does not support IPV6 and so does not define ENABLE_IPV6 for Python. RTEMS contains an aging port of the FreeBSD stack and the port contains some IPV6 things such as inet_ntop and inet_pton. This causes HAVE_INET_PTON to be defined to 1 causing the current socketmodule.c to compile the socket_inet_ntop code. The assumption being these functions are only present with IPV6 stacks. This assumption is valid, how-ever RTEMS breaks this assuption and fixing this in RTEMS is not pratical. Removing the HAVE_INET_PTON definition causes socketmodule.c to compile in a private version. The private versions have a slightly different prototype to RTEMS and so the compiler stops with an error. This patch seems the simplest solutions given it does not effect other platforms. ---------------------------------------------------------------------- >Comment By: Chris Johns (cjohns) Date: 2003-05-15 13:56 Message: Logged In: YES user_id=197074 I have tested socketmodule.c version 1.268 with RTEMS and it compiles and works. No further changes are needed. I added to RTEMS the INET_ADDRSTRLEN define as it was not in netinet/in.h and the addition took a little longer than expected. An RTEMS maintainer raised the point the SUS standard that defines INET_ADDRSTRLEN is new(ish!) and so Python may not be as robust on older systems that do not have INET_ADDRSTRLEN defined. Thanks for the prompt resolution. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 17:44 Message: Logged In: YES user_id=21627 I believe this patch is now superceded by #734231. It appears that the problem of inet_pton is shared on many platforms, so the code now wraps the buffer declaration with ENABLE_IPV6. Can you please retry the current CVS, and indicate whether further changes are needed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730603&group_id=5470 From noreply@sourceforge.net Thu May 15 07:53:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 23:53:25 -0700 Subject: [Patches] [ python-Patches-730603 ] socketmodule inet_ntop built when IPV6 is disabled Message-ID: Patches item #730603, was opened at 2003-05-01 07:05 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730603&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chris Johns (cjohns) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule inet_ntop built when IPV6 is disabled Initial Comment: RTEMS does not support IPV6 and so does not define ENABLE_IPV6 for Python. RTEMS contains an aging port of the FreeBSD stack and the port contains some IPV6 things such as inet_ntop and inet_pton. This causes HAVE_INET_PTON to be defined to 1 causing the current socketmodule.c to compile the socket_inet_ntop code. The assumption being these functions are only present with IPV6 stacks. This assumption is valid, how-ever RTEMS breaks this assuption and fixing this in RTEMS is not pratical. Removing the HAVE_INET_PTON definition causes socketmodule.c to compile in a private version. The private versions have a slightly different prototype to RTEMS and so the compiler stops with an error. This patch seems the simplest solutions given it does not effect other platforms. ---------------------------------------------------------------------- Comment By: Chris Johns (cjohns) Date: 2003-05-15 05:56 Message: Logged In: YES user_id=197074 I have tested socketmodule.c version 1.268 with RTEMS and it compiles and works. No further changes are needed. I added to RTEMS the INET_ADDRSTRLEN define as it was not in netinet/in.h and the addition took a little longer than expected. An RTEMS maintainer raised the point the SUS standard that defines INET_ADDRSTRLEN is new(ish!) and so Python may not be as robust on older systems that do not have INET_ADDRSTRLEN defined. Thanks for the prompt resolution. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:44 Message: Logged In: YES user_id=21627 I believe this patch is now superceded by #734231. It appears that the problem of inet_pton is shared on many platforms, so the code now wraps the buffer declaration with ENABLE_IPV6. Can you please retry the current CVS, and indicate whether further changes are needed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730603&group_id=5470 From noreply@sourceforge.net Thu May 15 08:14:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 00:14:17 -0700 Subject: [Patches] [ python-Patches-738094 ] for i in range(N) optimization Message-ID: Patches item #738094, was opened at 2003-05-15 09: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=738094&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Keim (s_keim) Assigned to: Nobody/Anonymous (nobody) Summary: for i in range(N) optimization Initial Comment: This patch is intended to special case the built-in range function in the common "for i in range(...):" construct. The goal is to make range() return an iterator instead of creating a real list, and then being able to depreciate the xrange type. It has once been suggested to make the compiler aware of the "for i in range(N):" construct and to make it able to produce optimized bytecode. But this solution is really hard to achieve because you have to ensure that the range built-in is not overridden. The patch take an opposite approach: it let the range built-in function looks at its execution context, and return an iterator if the next frame opcode to be executed is the GET_ITER opcode. Speed increase for the piece of code "for i in range(N): pass" : N (speed gain) 10 (+ 64%) 100 (+ 29%) 1000 (+ 23%) 10000 (+ 68%) 100000 (+108%) Since the patch only affect a small construct of the language, performance improvements for real applications are less impressive but they are still interesting: pystone.py (+7%) test_userstring.py (+8%) test_datetime.py (+20%) Note that the performance loss for "A = range(10)" is not measurable (less than 1%). If the patch is accepted, the same recipe may be applicable in some few other places. So the Py_IsIterationContext function must probably live somewhere else (is there a standard location for byte-code dependent stuff?). Maybe other opcodes (for sample JUMP_IF_FALSE) could provide other useful specialization contexts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 From noreply@sourceforge.net Thu May 15 15:33:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 07:33:58 -0700 Subject: [Patches] [ python-Patches-738094 ] for i in range(N) optimization Message-ID: Patches item #738094, was opened at 2003-05-15 02:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Keim (s_keim) Assigned to: Nobody/Anonymous (nobody) Summary: for i in range(N) optimization Initial Comment: This patch is intended to special case the built-in range function in the common "for i in range(...):" construct. The goal is to make range() return an iterator instead of creating a real list, and then being able to depreciate the xrange type. It has once been suggested to make the compiler aware of the "for i in range(N):" construct and to make it able to produce optimized bytecode. But this solution is really hard to achieve because you have to ensure that the range built-in is not overridden. The patch take an opposite approach: it let the range built-in function looks at its execution context, and return an iterator if the next frame opcode to be executed is the GET_ITER opcode. Speed increase for the piece of code "for i in range(N): pass" : N (speed gain) 10 (+ 64%) 100 (+ 29%) 1000 (+ 23%) 10000 (+ 68%) 100000 (+108%) Since the patch only affect a small construct of the language, performance improvements for real applications are less impressive but they are still interesting: pystone.py (+7%) test_userstring.py (+8%) test_datetime.py (+20%) Note that the performance loss for "A = range(10)" is not measurable (less than 1%). If the patch is accepted, the same recipe may be applicable in some few other places. So the Py_IsIterationContext function must probably live somewhere else (is there a standard location for byte-code dependent stuff?). Maybe other opcodes (for sample JUMP_IF_FALSE) could provide other useful specialization contexts. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-15 09:33 Message: Logged In: YES user_id=80475 zip() would benefit greatly from your approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 From noreply@sourceforge.net Thu May 15 16:14:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 08:14:39 -0700 Subject: [Patches] [ python-Patches-738094 ] for i in range(N) optimization Message-ID: Patches item #738094, was opened at 2003-05-15 09:14 Message generated for change (Comment added) made by s_keim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Keim (s_keim) Assigned to: Nobody/Anonymous (nobody) Summary: for i in range(N) optimization Initial Comment: This patch is intended to special case the built-in range function in the common "for i in range(...):" construct. The goal is to make range() return an iterator instead of creating a real list, and then being able to depreciate the xrange type. It has once been suggested to make the compiler aware of the "for i in range(N):" construct and to make it able to produce optimized bytecode. But this solution is really hard to achieve because you have to ensure that the range built-in is not overridden. The patch take an opposite approach: it let the range built-in function looks at its execution context, and return an iterator if the next frame opcode to be executed is the GET_ITER opcode. Speed increase for the piece of code "for i in range(N): pass" : N (speed gain) 10 (+ 64%) 100 (+ 29%) 1000 (+ 23%) 10000 (+ 68%) 100000 (+108%) Since the patch only affect a small construct of the language, performance improvements for real applications are less impressive but they are still interesting: pystone.py (+7%) test_userstring.py (+8%) test_datetime.py (+20%) Note that the performance loss for "A = range(10)" is not measurable (less than 1%). If the patch is accepted, the same recipe may be applicable in some few other places. So the Py_IsIterationContext function must probably live somewhere else (is there a standard location for byte-code dependent stuff?). Maybe other opcodes (for sample JUMP_IF_FALSE) could provide other useful specialization contexts. ---------------------------------------------------------------------- >Comment By: Sebastien Keim (s_keim) Date: 2003-05-15 17:14 Message: Logged In: YES user_id=498191 I have also thought about slicing, map and filter which could all be replaced by itertools equivalents , but I have failed to find a way to ensure that the argument lists aren't mutated during the for loop. Maybe it could be interesting to investigate into copy on write semantic for lists objects? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-15 16:33 Message: Logged In: YES user_id=80475 zip() would benefit greatly from your approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 From noreply@sourceforge.net Thu May 15 16:22:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 08:22:22 -0700 Subject: [Patches] [ python-Patches-738325 ] install idle byte optimized modules, too Message-ID: Patches item #738325, was opened at 2003-05-15 17: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=738325&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: wrobell (wrobell) Assigned to: Nobody/Anonymous (nobody) Summary: install idle byte optimized modules, too Initial Comment: Python 2.3 installs sources, byte compiled and byte optimized modules from Lib directory. However, idlelib modules are installed only as sources and byte compiled files, so there is the patch to install idle byte optimized modules, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738325&group_id=5470 From noreply@sourceforge.net Thu May 15 18:11:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 10:11:32 -0700 Subject: [Patches] [ python-Patches-738389 ] fix for glob with directories which contain brackets Message-ID: Patches item #738389, was opened at 2003-05-15 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=738389&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: fix for glob with directories which contain brackets Initial Comment: see bug #738631, http://sourceforge.net/tracker/index.php?func=detail&aid=738361&group_id=5470&atid=105470 if you give glob a pattern with [...], it assumes it's a file pattern. this changes glob.py to add a \ in front of the [ if a directory actually exists with the bracket in it. it also changes translate in fnmatch.py to take the special case of \[ and add that straight to the regex instead of trying to handle the shell pattern. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738389&group_id=5470 From noreply@sourceforge.net Fri May 16 06:40:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 22:40:58 -0700 Subject: [Patches] [ python-Patches-738325 ] install idle byte optimized modules, too Message-ID: Patches item #738325, was opened at 2003-05-15 17:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738325&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: wrobell (wrobell) Assigned to: Nobody/Anonymous (nobody) Summary: install idle byte optimized modules, too Initial Comment: Python 2.3 installs sources, byte compiled and byte optimized modules from Lib directory. However, idlelib modules are installed only as sources and byte compiled files, so there is the patch to install idle byte optimized modules, too. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-16 07:40 Message: Logged In: YES user_id=21627 Thanks for the patch. Installed as Makefile.pre.in 1.127. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738325&group_id=5470 From noreply@sourceforge.net Fri May 16 06:44:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 22:44:36 -0700 Subject: [Patches] [ python-Patches-736857 ] interpreter final destination location Message-ID: Patches item #736857, was opened at 2003-05-13 08:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736857&group_id=5470 Category: Distutils and setup.py Group: None Status: Open >Resolution: Later Priority: 5 Submitted By: Tim Magill (tmagill) Assigned to: Nobody/Anonymous (nobody) Summary: interpreter final destination location Initial Comment: New command line option to specify the string to be substituted in the "#!" line at the beginning of scripts ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-16 07:44 Message: Logged In: YES user_id=21627 As a new feature, I think it is too late to integrate it into Python 2.3, so it should be postponed for now. I find the feature itself relatively straight-forward to add it to distutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736857&group_id=5470 From noreply@sourceforge.net Fri May 16 07:09:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 23:09:15 -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: Open Resolution: None 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-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 Fri May 16 07:10:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 23:10:00 -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: Open Resolution: None 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-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 Fri May 16 09:52:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 01:52:31 -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 wrobell 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: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: DESTDIR improvement Initial Comment: Byte compile correctly with DESTDIR. ---------------------------------------------------------------------- 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 Fri May 16 13:00:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 05:00:24 -0700 Subject: [Patches] [ python-Patches-737999 ] minor codeop fixes Message-ID: Patches item #737999, was opened at 2003-05-15 02:55 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737999&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Samuele Pedroni (pedronis) >Assigned to: Samuele Pedroni (pedronis) Summary: minor codeop fixes Initial Comment: *) compile_command("",eval) -> None , previously raised syntax error about "pass" *) symbol must be eval or single, now raises ValueError accordingly as specified in the documentation patch both for 2.3 and 2.2 maint for codeop.py and test/test_codeop.py (beefed up) (for Jython at the moment we use the test suite of 2.2 maint, that's why this is relevant) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-05-16 13:00 Message: Logged In: YES user_id=6656 Given that codeop has *never* lived up to its promise to raise ValueError on 'exec', perhaps the docs should be fixed rather than the code? (I don't understand the point of supporting anything but 'single', but...). Certainly this change *should not* be made on the 22-maint branch. Can you check in your tests to both branches and port Guido's codeop.py change? Fixing up the docs gets you extra points, I think :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737999&group_id=5470 From noreply@sourceforge.net Fri May 16 22:42:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 14:42:09 -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: Open Resolution: None 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-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 May 17 00:15:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 16:15:36 -0700 Subject: [Patches] [ python-Patches-731607 ] make threading join() method return a value Message-ID: Patches item #731607, was opened at 2003-05-02 14:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: make threading join() method return a value Initial Comment: This patch makes the join() method of a threading module Thread return the value that was returned by the callable that is running in the thread. It came about because I needed to split a process into a number of threads, join them all, and then check what each of them returned before proceeding. It against the current CVS tree, tested on Linux. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:15 Message: Logged In: YES user_id=357491 Closing and rejecting. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 16:47 Message: Logged In: YES user_id=357491 If no one else speaks up on this patch by May 15 I am going to close it and reject it. ---------------------------------------------------------------------- Comment By: Matthew Boedicker (mboedick) Date: 2003-05-04 20:23 Message: Logged In: YES user_id=119895 I wasn't subclassing Thread, just instantiating it and passing in a target. I didn't think of writing a wrapper, but that would work for me. I still think having join() return something that might be useful in some circumstances is better than having it return something which is always useless (None), and easier than dealing with Queues or wrappers. Anyway, thanks for feedback. I'll probably use the wrapper approach for now. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-04 17:22 Message: Logged In: YES user_id=357491 But don't you have the requirement that the code know that it is running in a thread when you made your subclass of threading.thread? And even if you didn't, why can't you just wrap the code to catch the return value and push it into the queue in a threading class? I am not going to reject this patch, Matthew, until someone else with commit privs comes in and says they don't like the patch either, so no need to worry... yet. =) ---------------------------------------------------------------------- Comment By: Matthew Boedicker (mboedick) Date: 2003-05-04 17:03 Message: Logged In: YES user_id=119895 The problem with using a Queue is that it requires whatever is running in the thread to be aware it is running in a thread. It would force non-threaded programs using that method to deal with Queues. With the patch, there would be a standard, intuitive way to return data to the caller that worked whether the method was running in a separate thread or not. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-02 14:35 Message: Logged In: YES user_id=357491 I don't think this is truly necessary. If you needed to know what they would return just insert it into a Queue and when the 'join' calls finish check the Queue to see what was added. It also deviates from Java's threading setup which 'threading' is based on. I'm -1 on this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470 From noreply@sourceforge.net Sat May 17 01:41:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 17:41:18 -0700 Subject: [Patches] [ python-Patches-508665 ] Improvement of cgi.parse_qsl function Message-ID: Patches item #508665, was opened at 2002-01-25 12:23 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=508665&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Improvement of cgi.parse_qsl function Initial Comment: I found the parsing function "parse_qsl" in the module "cgi" to have some flaws. Especially, empty names are allowed, even if empty values are explicitly disallowed. If the latter are allowed, "?name=" is accepted, while "?name" is ignored. Often you want to use links like "?logout" or "?help". This is not possible, even if empty values are explicitly allowed. Also, "strict parsing" objects to "?name=", while it ignores "?name=a=b=c". My improvement suggestion: ------------- use ---------- for name_value in pairs: if strict_parsing: nv = name_value.split('=', 2) if len(nv) != 2 or not len(nv[0]): raise ValueError, "bad query field: %s" % `name_value` else: nv = name_value.split('=', 1).append('') if not len(nv[0]): continue if len(nv[1]) or keep_blank_values: name = urllib.unquote(nv[0].replace('+', ' ')) value = urllib.unquote(nv[1].replace('+', ' ')) r.append((name, value)) ----------- instead of -------- for name_value in pairs: nv = name_value.split('=', 1) if len(nv) != 2: if strict_parsing: raise ValueError, "bad query field: %s" % `name_value` continue if len(nv[1]) or keep_blank_values: name = urllib.unquote(nv[0].replace('+', ' ')) value = urllib.unquote(nv[1].replace('+', ' ')) r.append((name, value)) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 17:41 Message: Logged In: YES user_id=357491 The issue of "name=" compared to "name=a=b=c" has changed; both are allowed under strict parsing while "name" is not. The isue with "name" not being made a key with a blank value is still there. Christoph, any chance you can create a patch against the CVS version of cgi? ---------------------------------------------------------------------- Comment By: Christoph Zwerschke (cito) Date: 2002-01-25 12:41 Message: Logged In: YES user_id=193957 -------- better use: ---------- 

for name_value in pairs:
    if strict_parsing:
        nv = name_value.split('=', 2)
        if len(nv) != 2 or not len(nv[0]):
            raise ValueError, "bad query field: %s" % 
`name_value`
    else:
        nv = name_value.split('=', 1)
        if not len(nv[0]):
            continue
        if len(nv) != 2:
            nv.append('')
    if len(nv[1]) or keep_blank_values:
        name = urllib.unquote(nv[0].replace('+', ' '))
        value = urllib.unquote(nv[1].replace('+', ' '))
        r.append((name, value))
---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=508665&group_id=5470 From noreply@sourceforge.net Sat May 17 01:47:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 17:47:28 -0700 Subject: [Patches] [ python-Patches-508730 ] CGIHTTPServer execfile should save cwd Message-ID: Patches item #508730, was opened at 2002-01-25 15:41 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=508730&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Grassi (dgrassi) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer execfile should save cwd Initial Comment: In CGIHTTPServer when running a script via execfile the cwd is not saved and restored. If the executed script changes the cwd subsequent requests will fail because self.translate_path in SimpleHTTPServer relies on the cwd. One fix is to suround the execfile call with save_cwd = os.getcwd() and os.chdir(save_cwd) Here is the proposed fix starting at line 254: + save_cwd = os.getcwd() try: try: sys.argv = [scriptfile] if '=' not in decoded_query: sys.argv.append(decoded_query) sys.stdout = self.wfile sys.stdin = self.rfile execfile(scriptfile, {"__name__": "__main__"}) finally: + os.chdir(save_cwd) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 17:47 Message: Logged In: YES user_id=357491 Since a patch is in the comments I am making this a patch instead of a bug. As for the idea, it seems good to me. Anyone else care to comment? ---------------------------------------------------------------------- Comment By: Dan Grassi (dgrassi) Date: 2002-01-25 15:55 Message: Logged In: YES user_id=366473 Here is the (hopefully) properly indented fix: + save_cwd = os.getcwd() try: try: sys.argv = [scriptfile] if '=' not in decoded_query: sys.argv.append(decoded_query) sys.stdout = self.wfile sys.stdin = self.rfile execfile(scriptfile, {"__name__": "__main__"}) finally: + os.chdir(save_cwd) ---------------------------------------------------------------------- Comment By: Dan Grassi (dgrassi) Date: 2002-01-25 15:48 Message: Logged In: YES user_id=366473 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=508730&group_id=5470 From noreply@sourceforge.net Sat May 17 03:02:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 19:02:20 -0700 Subject: [Patches] [ python-Patches-547176 ] rlcompleter does not expand on [ ] Message-ID: Patches item #547176, was opened at 2002-04-22 10:39 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=547176&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jaco Schieke (schiekjd) Assigned to: Nobody/Anonymous (nobody) Summary: rlcompleter does not expand on [ ] Initial Comment: A thread on comp.lang.python details the problem: http://groups.google.com/groups? hl=en&threadm=b5ddd682.0204180902.2866a9c0% 40posting.google.com&rnum=1&prev=/groups%3Fhl%3Den% 26selm%3Db5ddd682.0204180902.2866a9c0% 2540posting.google.com rlcompleter.py does not expand correctly on something like: >>> sim[0]. since m = re.match(r"(\w+(\.\w+)*)\.(\w*)", text) does not allow for brackets in the match. I propose: m = re.match(r"([\w\[\]]+(\.[\w\[\]]+)*)\.(\w*)", text) to fix this on line 127 in cvs version 1.11 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:02 Message: Logged In: YES user_id=357491 Making this a patch since one is included. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-04 12:26 Message: Logged In: YES user_id=670441 This isn't really a bug, as (at least currently) this behavior is mentioned in the documentation for rlcompleter (at least it's in the docstring). The reason a[0]. isn't completed is that we want to avoid executing arbitrary code. The current completion mechanism is already a bit dangerous as an object's getattr could be called to execute code with unknown side effects while completing. It just seems to dangerous to allow indexing, as lots of objects use this for their own purposes. If this behavior is determined desirable despite the danger, someone with commit privileges should say so, and then someone can submit a patch (I could do it). Probably this bug should just be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=547176&group_id=5470 From noreply@sourceforge.net Sat May 17 03:46:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 19:46:55 -0700 Subject: [Patches] [ python-Patches-737999 ] minor codeop fixes Message-ID: Patches item #737999, was opened at 2003-05-15 03:55 Message generated for change (Comment added) made by pedronis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737999&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Samuele Pedroni (pedronis) Summary: minor codeop fixes Initial Comment: *) compile_command("",eval) -> None , previously raised syntax error about "pass" *) symbol must be eval or single, now raises ValueError accordingly as specified in the documentation patch both for 2.3 and 2.2 maint for codeop.py and test/test_codeop.py (beefed up) (for Jython at the moment we use the test suite of 2.2 maint, that's why this is relevant) ---------------------------------------------------------------------- >Comment By: Samuele Pedroni (pedronis) Date: 2003-05-17 04:46 Message: Logged In: YES user_id=61408 committed: test_codeop.py 1.6 test_codeop.py 1.3.12.1 (release22-maint) codeop.py 1.5.16.1 (release22-maint) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-16 14:00 Message: Logged In: YES user_id=6656 Given that codeop has *never* lived up to its promise to raise ValueError on 'exec', perhaps the docs should be fixed rather than the code? (I don't understand the point of supporting anything but 'single', but...). Certainly this change *should not* be made on the 22-maint branch. Can you check in your tests to both branches and port Guido's codeop.py change? Fixing up the docs gets you extra points, I think :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737999&group_id=5470 From noreply@sourceforge.net Sat May 17 13:38:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 05:38:44 -0700 Subject: [Patches] [ python-Patches-739124 ] Add use_default_colors support to curses module. Message-ID: Patches item #739124, was opened at 2003-05-17 14:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=739124&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jörg Lehmann (joergl) Assigned to: Nobody/Anonymous (nobody) Summary: Add use_default_colors support to curses module. Initial Comment: This trivial patch adds support for the use_default_colors function to the curses module, if supported by the (n)curses library. This functionality is needed, if one wants to use transparency in a ncurses application. Included is a corresponding patch for the curses test module and the curses module's documentation. It would be nice, if this patch could be included in Python2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=739124&group_id=5470 From noreply@sourceforge.net Sun May 18 00:25:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 16:25:25 -0700 Subject: [Patches] [ python-Patches-738094 ] for i in range(N) optimization Message-ID: Patches item #738094, was opened at 2003-05-15 02:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Keim (s_keim) >Assigned to: Guido van Rossum (gvanrossum) Summary: for i in range(N) optimization Initial Comment: This patch is intended to special case the built-in range function in the common "for i in range(...):" construct. The goal is to make range() return an iterator instead of creating a real list, and then being able to depreciate the xrange type. It has once been suggested to make the compiler aware of the "for i in range(N):" construct and to make it able to produce optimized bytecode. But this solution is really hard to achieve because you have to ensure that the range built-in is not overridden. The patch take an opposite approach: it let the range built-in function looks at its execution context, and return an iterator if the next frame opcode to be executed is the GET_ITER opcode. Speed increase for the piece of code "for i in range(N): pass" : N (speed gain) 10 (+ 64%) 100 (+ 29%) 1000 (+ 23%) 10000 (+ 68%) 100000 (+108%) Since the patch only affect a small construct of the language, performance improvements for real applications are less impressive but they are still interesting: pystone.py (+7%) test_userstring.py (+8%) test_datetime.py (+20%) Note that the performance loss for "A = range(10)" is not measurable (less than 1%). If the patch is accepted, the same recipe may be applicable in some few other places. So the Py_IsIterationContext function must probably live somewhere else (is there a standard location for byte-code dependent stuff?). Maybe other opcodes (for sample JUMP_IF_FALSE) could provide other useful specialization contexts. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:25 Message: Logged In: YES user_id=80475 Assigning to Guido to see whether he is interested because it makes xrange less necessary or whether he thinks it is a horrendous hack --or maybe both ;-) ---------------------------------------------------------------------- Comment By: Sebastien Keim (s_keim) Date: 2003-05-15 10:14 Message: Logged In: YES user_id=498191 I have also thought about slicing, map and filter which could all be replaced by itertools equivalents , but I have failed to find a way to ensure that the argument lists aren't mutated during the for loop. Maybe it could be interesting to investigate into copy on write semantic for lists objects? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-15 09:33 Message: Logged In: YES user_id=80475 zip() would benefit greatly from your approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 From noreply@sourceforge.net Sun May 18 00:35:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 16:35:02 -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-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 Sun May 18 01:50:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 17:50:54 -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-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 Sun May 18 02:04:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 18:04:44 -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-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 Sun May 18 02:45:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 18:45:54 -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-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 Sun May 18 02:51:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 18:51:58 -0700 Subject: [Patches] [ python-Patches-732174 ] build of html docs broken (liboptparse.tex) Message-ID: Patches item #732174, was opened at 2003-05-04 09:47 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Raymond Hettinger (rhettinger) Summary: build of html docs broken (liboptparse.tex) Initial Comment: The last known working versions is 1.6. 1.7 doesn't build anymore. latex2html returns [...] Reading aux file: /build/packages/python2.3/python2.3-2.2.102/Doc/lib.aux ... Processing macros ...,,,,++................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Subroutine do_cmd_leftmargin redefined at (eval 732) line 1. defining handler for \leftmargin using \leftmargini .............Undefined subroutine &main::do_cmd_leftmargini called at (eval 732) line 1. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-17 21:51 Message: Logged In: YES user_id=31435 Assigning to Raymond for practice in finding the Submit button . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 From noreply@sourceforge.net Sun May 18 02:59:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 18:59:10 -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-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 Sun May 18 03:02:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 19:02:17 -0700 Subject: [Patches] [ python-Patches-732174 ] build of html docs broken (liboptparse.tex) Message-ID: Patches item #732174, was opened at 2003-05-04 08:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Raymond Hettinger (rhettinger) Summary: build of html docs broken (liboptparse.tex) Initial Comment: The last known working versions is 1.6. 1.7 doesn't build anymore. latex2html returns [...] Reading aux file: /build/packages/python2.3/python2.3-2.2.102/Doc/lib.aux ... Processing macros ...,,,,++................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Subroutine do_cmd_leftmargin redefined at (eval 732) line 1. defining handler for \leftmargin using \leftmargini .............Undefined subroutine &main::do_cmd_leftmargini called at (eval 732) line 1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-17 20:51 Message: Logged In: YES user_id=31435 Assigning to Raymond for practice in finding the Submit button . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 From noreply@sourceforge.net Sun May 18 03:52:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 19:52:48 -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-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 Sun May 18 04:18:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 20:18:02 -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-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 Sun May 18 20:02:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 12:02:59 -0700 Subject: [Patches] [ python-Patches-732174 ] build of html docs broken (liboptparse.tex) Message-ID: Patches item #732174, was opened at 2003-05-04 13:47 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Raymond Hettinger (rhettinger) Summary: build of html docs broken (liboptparse.tex) Initial Comment: The last known working versions is 1.6. 1.7 doesn't build anymore. latex2html returns [...] Reading aux file: /build/packages/python2.3/python2.3-2.2.102/Doc/lib.aux ... Processing macros ...,,,,++................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Subroutine do_cmd_leftmargin redefined at (eval 732) line 1. defining handler for \leftmargin using \leftmargini .............Undefined subroutine &main::do_cmd_leftmargini called at (eval 732) line 1. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-05-18 19:02 Message: Logged In: YES user_id=60903 Reopened. Please practice on other reports ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-18 01:51 Message: Logged In: YES user_id=31435 Assigning to Raymond for practice in finding the Submit button . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 From noreply@sourceforge.net Sun May 18 20:08:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 12:08:33 -0700 Subject: [Patches] [ python-Patches-732174 ] build of html docs broken (liboptparse.tex) Message-ID: Patches item #732174, was opened at 2003-05-04 13:47 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: build of html docs broken (liboptparse.tex) Initial Comment: The last known working versions is 1.6. 1.7 doesn't build anymore. latex2html returns [...] Reading aux file: /build/packages/python2.3/python2.3-2.2.102/Doc/lib.aux ... Processing macros ...,,,,++................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Subroutine do_cmd_leftmargin redefined at (eval 732) line 1. defining handler for \leftmargin using \leftmargini .............Undefined subroutine &main::do_cmd_leftmargini called at (eval 732) line 1. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-05-18 19:08 Message: Logged In: YES user_id=60903 Attached is a patch to fix the build of the info docs. The change to libre.tex maybe controversial, as it works around a problem in py2texi.el. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-05-18 19:02 Message: Logged In: YES user_id=60903 Reopened. Please practice on other reports ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-18 01:51 Message: Logged In: YES user_id=31435 Assigning to Raymond for practice in finding the Submit button . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 From noreply@sourceforge.net Sun May 18 21:28:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 13:28:48 -0700 Subject: [Patches] [ python-Patches-732174 ] build of html docs broken (liboptparse.tex) Message-ID: Patches item #732174, was opened at 2003-05-04 08:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: build of html docs broken (liboptparse.tex) Initial Comment: The last known working versions is 1.6. 1.7 doesn't build anymore. latex2html returns [...] Reading aux file: /build/packages/python2.3/python2.3-2.2.102/Doc/lib.aux ... Processing macros ...,,,,++................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Subroutine do_cmd_leftmargin redefined at (eval 732) line 1. defining handler for \leftmargin using \leftmargini .............Undefined subroutine &main::do_cmd_leftmargini called at (eval 732) line 1. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 15:28 Message: Logged In: YES user_id=80475 The latest version is 1.9. Fred made changes to make it build again. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-05-18 14:08 Message: Logged In: YES user_id=60903 Attached is a patch to fix the build of the info docs. The change to libre.tex maybe controversial, as it works around a problem in py2texi.el. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-05-18 14:02 Message: Logged In: YES user_id=60903 Reopened. Please practice on other reports ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-17 20:51 Message: Logged In: YES user_id=31435 Assigning to Raymond for practice in finding the Submit button . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 From noreply@sourceforge.net Sun May 18 21:46:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 13:46:40 -0700 Subject: [Patches] [ python-Patches-732174 ] build of html docs broken (liboptparse.tex) Message-ID: Patches item #732174, was opened at 2003-05-04 13:47 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: build of html docs broken (liboptparse.tex) Initial Comment: The last known working versions is 1.6. 1.7 doesn't build anymore. latex2html returns [...] Reading aux file: /build/packages/python2.3/python2.3-2.2.102/Doc/lib.aux ... Processing macros ...,,,,++................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Subroutine do_cmd_leftmargin redefined at (eval 732) line 1. defining handler for \leftmargin using \leftmargini .............Undefined subroutine &main::do_cmd_leftmargini called at (eval 732) line 1. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-05-18 20:46 Message: Logged In: YES user_id=60903 Which version? py2texi.el is at 1.3 and unchanged the last six months. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 20:28 Message: Logged In: YES user_id=80475 The latest version is 1.9. Fred made changes to make it build again. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-05-18 19:08 Message: Logged In: YES user_id=60903 Attached is a patch to fix the build of the info docs. The change to libre.tex maybe controversial, as it works around a problem in py2texi.el. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-05-18 19:02 Message: Logged In: YES user_id=60903 Reopened. Please practice on other reports ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-18 01:51 Message: Logged In: YES user_id=31435 Assigning to Raymond for practice in finding the Submit button . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 From noreply@sourceforge.net Sun May 18 22:18:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 14:18:44 -0700 Subject: [Patches] [ python-Patches-738094 ] for i in range(N) optimization Message-ID: Patches item #738094, was opened at 2003-05-15 03:14 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Keim (s_keim) Assigned to: Guido van Rossum (gvanrossum) Summary: for i in range(N) optimization Initial Comment: This patch is intended to special case the built-in range function in the common "for i in range(...):" construct. The goal is to make range() return an iterator instead of creating a real list, and then being able to depreciate the xrange type. It has once been suggested to make the compiler aware of the "for i in range(N):" construct and to make it able to produce optimized bytecode. But this solution is really hard to achieve because you have to ensure that the range built-in is not overridden. The patch take an opposite approach: it let the range built-in function looks at its execution context, and return an iterator if the next frame opcode to be executed is the GET_ITER opcode. Speed increase for the piece of code "for i in range(N): pass" : N (speed gain) 10 (+ 64%) 100 (+ 29%) 1000 (+ 23%) 10000 (+ 68%) 100000 (+108%) Since the patch only affect a small construct of the language, performance improvements for real applications are less impressive but they are still interesting: pystone.py (+7%) test_userstring.py (+8%) test_datetime.py (+20%) Note that the performance loss for "A = range(10)" is not measurable (less than 1%). If the patch is accepted, the same recipe may be applicable in some few other places. So the Py_IsIterationContext function must probably live somewhere else (is there a standard location for byte-code dependent stuff?). Maybe other opcodes (for sample JUMP_IF_FALSE) could provide other useful specialization contexts. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-18 17:18 Message: Logged In: YES user_id=6380 I'm interested, but have to ponder more, which will have to wait until I'm back from vacation. I expect that any hope to deprecate xrange() will prove naive -- people will want to pass ranges around between functions or reuse them (e.g. this happens a lot in timing tests). Maybe in Python 3.0 I can make range() act as an iterator generator. You'd have to say list(range(N)) to get an actual list then. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 19:25 Message: Logged In: YES user_id=80475 Assigning to Guido to see whether he is interested because it makes xrange less necessary or whether he thinks it is a horrendous hack --or maybe both ;-) ---------------------------------------------------------------------- Comment By: Sebastien Keim (s_keim) Date: 2003-05-15 11:14 Message: Logged In: YES user_id=498191 I have also thought about slicing, map and filter which could all be replaced by itertools equivalents , but I have failed to find a way to ensure that the argument lists aren't mutated during the for loop. Maybe it could be interesting to investigate into copy on write semantic for lists objects? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-15 10:33 Message: Logged In: YES user_id=80475 zip() would benefit greatly from your approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 From noreply@sourceforge.net Mon May 19 00:46:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 16:46:18 -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-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 May 19 00:51:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 16:51:07 -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-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 May 19 10:48:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 02:48:32 -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 nijel 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: Open Resolution: None 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: 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 Mon May 19 10:51:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 02:51:37 -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: Open Resolution: None 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-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 Mon May 19 14:29:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 06:29:32 -0700 Subject: [Patches] [ python-Patches-518625 ] Return objects in Tkinter Message-ID: Patches item #518625, was opened at 2002-02-17 01:36 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=518625&group_id=5470 Category: Tkinter Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Return objects in Tkinter Initial Comment: This patch uses the Tcl object API to convert return values to Python objects. For boolean, bytearray, double, int, list, and string objects, the equivalent Python objects are constructed (Unicode for Tcl string). For untyped objects, strings are returned. For all other objects, a Python wrapper object is returned which supports a tp_str conversion. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-19 15:29 Message: Logged In: YES user_id=45365 According to some of the Tcl/Tk folks there is a problem with this patch, in that Tcl objects really *are* strings, and any typing is purely an implementation speedup shortcut. This showed up when Tkinter got a floating point value for tcl_version on MacOSX. Details are in bug report #729317. I'm adding this comment purely to make sure this bit of knowledge doesn't get lost. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-26 10:28 Message: Logged In: YES user_id=21627 Since there were no further comments, committed as Tkinter.py 1.166 NEWS 1.543 _tkinter.c 1.131 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-22 14:25 Message: Logged In: YES user_id=6380 I can't answer that question, since I don't know what's out in the field. If you don't get response from python-dev, let's try this and see how it fares during the alpha tests. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-22 14:20 Message: Logged In: YES user_id=21627 I was originally asked to put this on SF for review because the potential backwards incompatibility in return types. IDLE seems to work fine with this change, so I expect incompatibility to come up rarely. Can I commit this as-is, with the suggestion that applications that break with this can do import Tkinter Tkinter.want_objects = 0 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-22 13:10 Message: Logged In: YES user_id=6380 Looks OK in theory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=518625&group_id=5470 From noreply@sourceforge.net Mon May 19 15:05:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 07:05:46 -0700 Subject: [Patches] [ python-Patches-508665 ] Improvement of cgi.parse_qsl function Message-ID: Patches item #508665, was opened at 2002-01-25 21:23 Message generated for change (Comment added) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=508665&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Improvement of cgi.parse_qsl function Initial Comment: I found the parsing function "parse_qsl" in the module "cgi" to have some flaws. Especially, empty names are allowed, even if empty values are explicitly disallowed. If the latter are allowed, "?name=" is accepted, while "?name" is ignored. Often you want to use links like "?logout" or "?help". This is not possible, even if empty values are explicitly allowed. Also, "strict parsing" objects to "?name=", while it ignores "?name=a=b=c". My improvement suggestion: ------------- use ---------- for name_value in pairs: if strict_parsing: nv = name_value.split('=', 2) if len(nv) != 2 or not len(nv[0]): raise ValueError, "bad query field: %s" % `name_value` else: nv = name_value.split('=', 1).append('') if not len(nv[0]): continue if len(nv[1]) or keep_blank_values: name = urllib.unquote(nv[0].replace('+', ' ')) value = urllib.unquote(nv[1].replace('+', ' ')) r.append((name, value)) ----------- instead of -------- for name_value in pairs: nv = name_value.split('=', 1) if len(nv) != 2: if strict_parsing: raise ValueError, "bad query field: %s" % `name_value` continue if len(nv[1]) or keep_blank_values: name = urllib.unquote(nv[0].replace('+', ' ')) value = urllib.unquote(nv[1].replace('+', ' ')) r.append((name, value)) ---------------------------------------------------------------------- >Comment By: Christoph Zwerschke (cito) Date: 2003-05-19 16:05 Message: Logged In: YES user_id=193957 The problem with empty names is still the same. Is this what you need? cvs diff cgi.py (in directory C:\Temp\python\python\dist\src\Lib\) Index: cgi.py ================================================ =================== RCS file: /cvsroot/python/python/dist/src/Lib/cgi.py,v retrieving revision 1.76 diff -r1.76 cgi.py 212,214c212,214 < nv = name_value.split('=', 1) < if len(nv) != 2: < if strict_parsing: --- > if strict_parsing: > nv = name_value.split('=', 2) > if len(nv) != 2 or not len(nv[0]): 216c216,221 < continue --- > else: > nv = name_value.split('=', 1) > if not len(nv[0]): > continue > if len(nv) != 2: > nv.append('') ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 02:41 Message: Logged In: YES user_id=357491 The issue of "name=" compared to "name=a=b=c" has changed; both are allowed under strict parsing while "name" is not. The isue with "name" not being made a key with a blank value is still there. Christoph, any chance you can create a patch against the CVS version of cgi? ---------------------------------------------------------------------- Comment By: Christoph Zwerschke (cito) Date: 2002-01-25 21:41 Message: Logged In: YES user_id=193957 -------- better use: ---------- 

for name_value in pairs:
    if strict_parsing:
        nv = name_value.split('=', 2)
        if len(nv) != 2 or not len(nv[0]):
            raise ValueError, "bad query field: %s" % 
`name_value`
    else:
        nv = name_value.split('=', 1)
        if not len(nv[0]):
            continue
        if len(nv) != 2:
            nv.append('')
    if len(nv[1]) or keep_blank_values:
        name = urllib.unquote(nv[0].replace('+', ' '))
        value = urllib.unquote(nv[1].replace('+', ' '))
        r.append((name, value))
---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=508665&group_id=5470 From noreply@sourceforge.net Mon May 19 23:32:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 15:32:29 -0700 Subject: [Patches] [ python-Patches-499513 ] robotparser.py fails on some URLs Message-ID: Patches item #499513, was opened at 2002-01-04 19:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470 Category: Library (Lib) Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Martin v. Löwis (loewis) Summary: robotparser.py fails on some URLs Initial Comment: I am using Python 2.1.1. The URL http://www.chaosreigns.com/robots.txt results in an empty RobotParser object. Reason is that the file object returned from the URLOpener does not have a readlines() attribute. I patched the robotparser.py to use readline() instead of readlines(). Furthermore I removed the unnecessary redirection limit code which is already in FancyURLopener. Greetings, Bastian ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-20 00:32 Message: Logged In: YES user_id=21627 Backport to 2.2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-18 11:43 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as robotparser.py 1.12. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2002-01-04 20:02 Message: Logged In: YES user_id=9205 Updated patch with copyright ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-04 19:49 Message: Logged In: YES user_id=6380 I'll gladly apply your patch. Would you mind to also supply a patch for the copyright statement? It says "Python 2.0 open source license" but that's no longer the current license. How about the PSF license agreement for Python 2.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470 From noreply@sourceforge.net Mon May 19 23:33:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 15:33:06 -0700 Subject: [Patches] [ python-Patches-497420 ] ftplib: ftp anonymous password Message-ID: Patches item #497420, was opened at 2001-12-28 21:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=497420&group_id=5470 Category: Library (Lib) Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Eduardo Pérez (eperez) >Assigned to: Martin v. Löwis (loewis) Summary: ftplib: ftp anonymous password Initial Comment: I've seen that ftplib sends the user name when doing ANONYMOUS ftp gets. I see a lot of problems: - Sending the user name if the user doesn't know that it's sent doesn't protect the user state of ANONYMOUS - Spyware is not a good idea, most users don't like it. - Sending the user name helps SPAM instead of stopping it. Many ftp sites use this information to send you unsolicited email. - Sending the user name doesn't help ftp sites to know who the cracker is, crackers are not stupid to send their email address. - Sending the user name can be used to discriminate the user. By all of these reasons I argue that ftplib to don't send the user email by default. Some time ago two very important ftp clients wget and lftp stopped sending the user name as password based on my input. As more and more ftp clients are moving to this anonymous@ password (for example the kde kio ftp, qt3, gnome-xml, Net::FTP) I recommend you to apply the patch. I send you the bugfix. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-20 00:33 Message: Logged In: YES user_id=21627 Backport to 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 21:55 Message: Logged In: YES user_id=6380 Thanks! You're right. Checked in as ftplib.py 1.63. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=497420&group_id=5470 From noreply@sourceforge.net Tue May 20 02:16:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 18:16:12 -0700 Subject: [Patches] [ python-Patches-740200 ] preserving a few bits to make Stackless compatibility easier Message-ID: Patches item #740200, was opened at 2003-05-20 03: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=740200&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian Tismer (tismer) Assigned to: Nobody/Anonymous (nobody) Summary: preserving a few bits to make Stackless compatibility easier Initial Comment: These few patches allow the Stackless project to have its own branch of PyTypeObject and PyMethodDef structures, while maintaining binary compatibility to current and older Python environments. I would like to thank Guido for his support for the Stackless 3.0 branch of Python! Christian Tismer, May 2003 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740200&group_id=5470 From noreply@sourceforge.net Tue May 20 02:21:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 18:21:47 -0700 Subject: [Patches] [ python-Patches-740202 ] preserving a few bits to get Stackless compatibility (sec) Message-ID: Patches item #740202, was opened at 2003-05-20 03:21 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=740202&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian Tismer (tismer) Assigned to: Nobody/Anonymous (nobody) Summary: preserving a few bits to get Stackless compatibility (sec) Initial Comment: These few patches allow the Stackless project to have its own branch of PyTypeObject and PyMethodDef structures, while maintaining binary compatibility to current and older Python environments. I would like to thank Guido for his support for the Stackless 3.0 branch of Python! Christian Tismer, May 2003 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740202&group_id=5470 From noreply@sourceforge.net Tue May 20 02:23:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 18:23:01 -0700 Subject: [Patches] [ python-Patches-740200 ] preserving a few bits to make Stackless compatibility easier Message-ID: Patches item #740200, was opened at 2003-05-20 03:16 Message generated for change (Settings changed) made by tismer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740200&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Deleted Resolution: None Priority: 5 Submitted By: Christian Tismer (tismer) Assigned to: Nobody/Anonymous (nobody) Summary: preserving a few bits to make Stackless compatibility easier Initial Comment: These few patches allow the Stackless project to have its own branch of PyTypeObject and PyMethodDef structures, while maintaining binary compatibility to current and older Python environments. I would like to thank Guido for his support for the Stackless 3.0 branch of Python! Christian Tismer, May 2003 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740200&group_id=5470 From noreply@sourceforge.net Tue May 20 03:01:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 19:01:31 -0700 Subject: [Patches] [ python-Patches-740200 ] preserving a few bits to make Stackless compatibility easier Message-ID: Patches item #740200, was opened at 2003-05-19 21:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740200&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Deleted Resolution: None Priority: 5 Submitted By: Christian Tismer (tismer) Assigned to: Nobody/Anonymous (nobody) Summary: preserving a few bits to make Stackless compatibility easier Initial Comment: These few patches allow the Stackless project to have its own branch of PyTypeObject and PyMethodDef structures, while maintaining binary compatibility to current and older Python environments. I would like to thank Guido for his support for the Stackless 3.0 branch of Python! Christian Tismer, May 2003 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-19 22:01 Message: Logged In: YES user_id=31435 Christian, did you intend to delete this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740200&group_id=5470 From noreply@sourceforge.net Tue May 20 07:17:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 23:17:31 -0700 Subject: [Patches] [ python-Patches-497420 ] ftplib: ftp anonymous password Message-ID: Patches item #497420, was opened at 2001-12-28 21:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=497420&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Eduardo Pérez (eperez) Assigned to: Martin v. Löwis (loewis) Summary: ftplib: ftp anonymous password Initial Comment: I've seen that ftplib sends the user name when doing ANONYMOUS ftp gets. I see a lot of problems: - Sending the user name if the user doesn't know that it's sent doesn't protect the user state of ANONYMOUS - Spyware is not a good idea, most users don't like it. - Sending the user name helps SPAM instead of stopping it. Many ftp sites use this information to send you unsolicited email. - Sending the user name doesn't help ftp sites to know who the cracker is, crackers are not stupid to send their email address. - Sending the user name can be used to discriminate the user. By all of these reasons I argue that ftplib to don't send the user email by default. Some time ago two very important ftp clients wget and lftp stopped sending the user name as password based on my input. As more and more ftp clients are moving to this anonymous@ password (for example the kde kio ftp, qt3, gnome-xml, Net::FTP) I recommend you to apply the patch. I send you the bugfix. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-20 08:17 Message: Logged In: YES user_id=21627 Backport committed as 1.60.10.4 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-20 00:33 Message: Logged In: YES user_id=21627 Backport to 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 21:55 Message: Logged In: YES user_id=6380 Thanks! You're right. Checked in as ftplib.py 1.63. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=497420&group_id=5470 From noreply@sourceforge.net Tue May 20 07:19:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 23:19:56 -0700 Subject: [Patches] [ python-Patches-499513 ] robotparser.py fails on some URLs Message-ID: Patches item #499513, was opened at 2002-01-04 19:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Martin v. Löwis (loewis) Summary: robotparser.py fails on some URLs Initial Comment: I am using Python 2.1.1. The URL http://www.chaosreigns.com/robots.txt results in an empty RobotParser object. Reason is that the file object returned from the URLOpener does not have a readlines() attribute. I patched the robotparser.py to use readline() instead of readlines(). Furthermore I removed the unnecessary redirection limit code which is already in FancyURLopener. Greetings, Bastian ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-20 08:19 Message: Logged In: YES user_id=21627 Backport committed as 1.10.16.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-20 00:32 Message: Logged In: YES user_id=21627 Backport to 2.2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-18 11:43 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as robotparser.py 1.12. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2002-01-04 20:02 Message: Logged In: YES user_id=9205 Updated patch with copyright ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-04 19:49 Message: Logged In: YES user_id=6380 I'll gladly apply your patch. Would you mind to also supply a patch for the copyright statement? It says "Python 2.0 open source license" but that's no longer the current license. How about the PSF license agreement for Python 2.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470 From noreply@sourceforge.net Tue May 20 08:57:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 00:57:14 -0700 Subject: [Patches] [ python-Patches-740301 ] HP-UX support for unixccompiler.py Message-ID: Patches item #740301, was opened at 2003-05-20 07: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=740301&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX support for unixccompiler.py Initial Comment: gcc on hp-ux uses the native linker, so if gcc is used there, the normal gcc flags for linker do not apply. I propose the attached patch to unixccompiler.py. The patch also adds +s, which means that SHLIB_PATH is honored (the same as LD_LIBRARY_PATH on Linux/Solaris). I don't have the HP-UX native compiler, but I would think that this patch should also fix that, as it shares the common linker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740301&group_id=5470 From noreply@sourceforge.net Tue May 20 15:52:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 07:52:02 -0700 Subject: [Patches] [ python-Patches-740202 ] preserving a few bits to get Stackless compatibility (sec) Message-ID: Patches item #740202, was opened at 2003-05-20 03:21 Message generated for change (Comment added) made by tismer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740202&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian Tismer (tismer) Assigned to: Nobody/Anonymous (nobody) Summary: preserving a few bits to get Stackless compatibility (sec) Initial Comment: These few patches allow the Stackless project to have its own branch of PyTypeObject and PyMethodDef structures, while maintaining binary compatibility to current and older Python environments. I would like to thank Guido for his support for the Stackless 3.0 branch of Python! Christian Tismer, May 2003 ---------------------------------------------------------------------- >Comment By: Christian Tismer (tismer) Date: 2003-05-20 16:52 Message: Logged In: YES user_id=105700 I think I can drop the requirement of bits in the ml_flags structure. My request reduced therefore to just the one bit in the type object flags. The attached patch is smallest possible and involves object.h, only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740202&group_id=5470 From noreply@sourceforge.net Tue May 20 16:16:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 08:16:29 -0700 Subject: [Patches] [ python-Patches-740202 ] preserving a few bits to get Stackless compatibility (sec) Message-ID: Patches item #740202, was opened at 2003-05-20 03:21 Message generated for change (Settings changed) made by tismer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740202&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Christian Tismer (tismer) Assigned to: Nobody/Anonymous (nobody) Summary: preserving a few bits to get Stackless compatibility (sec) Initial Comment: These few patches allow the Stackless project to have its own branch of PyTypeObject and PyMethodDef structures, while maintaining binary compatibility to current and older Python environments. I would like to thank Guido for his support for the Stackless 3.0 branch of Python! Christian Tismer, May 2003 ---------------------------------------------------------------------- Comment By: Christian Tismer (tismer) Date: 2003-05-20 16:52 Message: Logged In: YES user_id=105700 I think I can drop the requirement of bits in the ml_flags structure. My request reduced therefore to just the one bit in the type object flags. The attached patch is smallest possible and involves object.h, only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740202&group_id=5470 From noreply@sourceforge.net Wed May 21 01:43:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 17:43:29 -0700 Subject: [Patches] [ python-Patches-740827 ] add urldecode() method to urllib Message-ID: Patches item #740827, was opened at 2003-05-20 20: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=740827&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: add urldecode() method to urllib Initial Comment: Adds a urldecode() method to urllib. The method does the opposite of urlencode, turns a url-encoded string into a list of two-tuples of name/value pairs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 From noreply@sourceforge.net Wed May 21 04:21:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 20:21:40 -0700 Subject: [Patches] [ python-Patches-740827 ] add urldecode() method to urllib Message-ID: Patches item #740827, was opened at 2003-05-20 17:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: add urldecode() method to urllib Initial Comment: Adds a urldecode() method to urllib. The method does the opposite of urlencode, turns a url-encoded string into a list of two-tuples of name/value pairs. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-20 20:21 Message: Logged In: YES user_id=357491 How is this different from cgi.parse_sql ? If it is not different, consider just having a wrapper for urldecode that calls cgi.parse_sql . Do you think urllib is the best place for this? What about urlparse? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 From noreply@sourceforge.net Wed May 21 14:04:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 06:04:34 -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-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 May 21 15:25:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 07:25:52 -0700 Subject: [Patches] [ python-Patches-740827 ] add urldecode() method to urllib Message-ID: Patches item #740827, was opened at 2003-05-20 20:43 Message generated for change (Comment added) made by mboedick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: add urldecode() method to urllib Initial Comment: Adds a urldecode() method to urllib. The method does the opposite of urlencode, turns a url-encoded string into a list of two-tuples of name/value pairs. ---------------------------------------------------------------------- >Comment By: Matthew Boedicker (mboedick) Date: 2003-05-21 10:25 Message: Logged In: YES user_id=119895 It is not different than cgi.parse_qsl. Must have missed that module when I was looking for this functionality. To me it seems like urlencode and urldecode (as well as quote, quote_plus, unquote, etc.) belong in urlparse. Do you think it would be valuable to include a pointer to cgi.parse_qsl in urllib or urllparse? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-20 23:21 Message: Logged In: YES user_id=357491 How is this different from cgi.parse_sql ? If it is not different, consider just having a wrapper for urldecode that calls cgi.parse_sql . Do you think urllib is the best place for this? What about urlparse? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 From noreply@sourceforge.net Wed May 21 17:00:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 09:00:37 -0700 Subject: [Patches] [ python-Patches-740827 ] add urldecode() method to urllib Message-ID: Patches item #740827, was opened at 2003-05-20 17:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: add urldecode() method to urllib Initial Comment: Adds a urldecode() method to urllib. The method does the opposite of urlencode, turns a url-encoded string into a list of two-tuples of name/value pairs. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-21 09:00 Message: Logged In: YES user_id=357491 I think so, but I don't know which one. I only use urllib.urlopen ever so if you have a specific suggestion from experience please make it and submit a patch. Since I don't use either modules extensively someone else is going to need to step in and help make any final decisions. ---------------------------------------------------------------------- Comment By: Matthew Boedicker (mboedick) Date: 2003-05-21 07:25 Message: Logged In: YES user_id=119895 It is not different than cgi.parse_qsl. Must have missed that module when I was looking for this functionality. To me it seems like urlencode and urldecode (as well as quote, quote_plus, unquote, etc.) belong in urlparse. Do you think it would be valuable to include a pointer to cgi.parse_qsl in urllib or urllparse? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-20 20:21 Message: Logged In: YES user_id=357491 How is this different from cgi.parse_sql ? If it is not different, consider just having a wrapper for urldecode that calls cgi.parse_sql . Do you think urllib is the best place for this? What about urlparse? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 From noreply@sourceforge.net Wed May 21 22:02:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 14:02:29 -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: Ka-Ping Yee (ping) 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-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 Wed May 21 23:12:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 15:12:37 -0700 Subject: [Patches] [ python-Patches-706707 ] time.tzset standards compliance update Message-ID: Patches item #706707, was opened at 2003-03-19 23:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706707&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 7 Submitted By: Stuart Bishop (zenzen) Assigned to: Neal Norwitz (nnorwitz) Summary: time.tzset standards compliance update Initial Comment: Update to configure.in and test_time.py to only use TZ environment variable format documented at http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 18:12 Message: Logged In: YES user_id=33168 Stuart, could you take a look at bug 728051? There is a time zone problem. I thought there were some other time zone problems on the snake-farm, but I don't see them now. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 11:52 Message: Logged In: YES user_id=33168 Checked in as: configure: 1.390 configure.in: 1.401 Lib/test/test_time.py: 1.14 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-11 11:38 Message: Logged In: YES user_id=6380 Neal, I think you can check it in now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 22:33 Message: Logged In: YES user_id=33168 Stuart, I saw the mails on py-dev, but am not sure about any conclusions. I tested the patch on Solaris 8 and Redhat 7.2. Solaris works (fails before the patch). Redhat fails with the patch, but I think it worked before the patch. I can check in to test on other architectures and back out if necessary. Let me know how to proceed. Thanks. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-04-06 22:19 Message: Logged In: YES user_id=46639 The bare except can go (just 'time.tzset()' without the try..except around it). The failure under Redhat is wierd - I can confirm that it works on a Redhat 7.2 box (as well as under OS X 10.2 and Solaris 2.8). The Australian timezone checks are testing that the timezone initialization stuff works in the southern hemisphere, and that time.altzone is being reset by tzset(). This will probably need to be taken to Python-dev unless you feel like applying the patch to HEAD and seeing who screams. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:46 Message: Logged In: YES user_id=33168 In the last chunk added, there is a bare except when calling time.tzset(). What are the possible exceptions? I don't want to have a bare except since this can mask a real error. The patch still fails for me on Linux (Redhat): * line 107: self.failUnless(time.tzname[1] == 'AEDT') - tzname has: ('AEST', 'AEST') * line 109: self.failUnlessEqual(time.daylight, 1) * line 111: self.failUnlessEqual(time.altzone, -39600) Haven't tried on other Unixes. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-03-27 15:12 Message: Logged In: YES user_id=46639 tzset3.diff is an updated diff against the CVS head. Fixes: -Don't test time.altzone for UTC - non-DST means altzone is undefined -Make sure dst timezone name is not the same as non-dst timezone name in TZ environment variable, to work around an apparent Solaris bug. -Extraneous cruft removed from test_time.py and configure.in - no more irrelevant comments. -More whitespace as per Tim's comments comments. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-21 16:28 Message: Logged In: YES user_id=33168 After patching, the test fails: File "/home/neal/build/python/2_3/Lib/test/test_time.py", line 115, in test_tzset self.failUnlessEqual(time.daylight,1) File "/home/neal/build/python/2.3/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 0 != 1 Also, why is the code commented out (via a string) on lines 120-144? Should these be removed? I see the comment about wallclock time, but don't understand why the code should be left in if we can't test it. I can understand a comment describing generally the issue. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-20 20:18 Message: Logged In: YES user_id=33168 I'll try to get to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-20 20:11 Message: Logged In: YES user_id=6380 Unassigning, as I won't hve time for this. But it is important - someone else should make sure this goes into 2.3b1! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-20 16:50 Message: Logged In: YES user_id=31435 Assigned to Guido, as I can't test it. Two notes: 1. Leaving commented-out code in config and the test suite doesn't appear to serve a purpose, although it will serve to confuse future readers ("why is this here? why is it commented out?"). 2. The Python style guide asks for a blank after commas in argument lists and tuples. We're not really in danger of stretching the screen here . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706707&group_id=5470 From noreply@sourceforge.net Thu May 22 03:27:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 19:27:58 -0700 Subject: [Patches] [ python-Patches-637217 ] inspect.getargspec: None instead of () Message-ID: Patches item #637217, was opened at 2002-11-12 08:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=637217&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nathan Srebro (nati) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec: None instead of () Initial Comment: When a function has no default arguments, getargspec (in module inspec) returns a fourth return-value of None: >>> inspect.getargspec(lambda x:x) (['x'], None, None, None) According to the documentation, the fourth return value, defaults, "is a tuple of default argument values; if this tuple has n elements, they correspond to the last n elements listed in args.". This suggests that if there are no default arguments, an empty tuple should be returned. This is also more consistent. Returning None requires special handling in code using this return value. Attached is a corrected version of getargspec (a check for 'defaults is None' is added). (This bug exists in both 2.2.2 and the current CVS) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-21 19:27 Message: Logged In: YES user_id=357491 Making this a patch since it has code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=637217&group_id=5470 From noreply@sourceforge.net Thu May 22 04:39:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 20:39:59 -0700 Subject: [Patches] [ python-Patches-640236 ] zlib.decompressobj under-described. Message-ID: Patches item #640236, was opened at 2002-11-18 10:48 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=640236&group_id=5470 >Category: None Group: None Status: Open Resolution: None 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: Brett Cannon (bcannon) Date: 2003-05-21 20: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 09: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 Thu May 22 08:40:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 00:40:44 -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 (Settings changed) 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: Raymond Hettinger (rhettinger) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&group_id=5470 From noreply@sourceforge.net Thu May 22 08:41:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 00:41:28 -0700 Subject: [Patches] [ python-Patches-683074 ] Optional output streams for dis Message-ID: Patches item #683074, was opened at 2003-02-08 15:22 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Raymond Hettinger (rhettinger) Summary: Optional output streams for dis Initial Comment: Right now the dis module uses print to output. This restricts it's use to interactive. You can't easily route the output to files, webpages, run re's on it, etc. This patch just adds an optional keyword parameter write that defaults to sys.stdout.write and replaces print statments with calls to write. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 From noreply@sourceforge.net Thu May 22 14:09:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 06:09:45 -0700 Subject: [Patches] [ python-Patches-683074 ] Optional output streams for dis Message-ID: Patches item #683074, was opened at 2003-02-08 14:22 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Raymond Hettinger (rhettinger) Summary: Optional output streams for dis Initial Comment: Right now the dis module uses print to output. This restricts it's use to interactive. You can't easily route the output to files, webpages, run re's on it, etc. This patch just adds an optional keyword parameter write that defaults to sys.stdout.write and replaces print statments with calls to write. ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2003-05-22 08:09 Message: Logged In: YES user_id=699438 Raymond, This actually got a thumbs down on python-dev. You can just close it out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 From noreply@sourceforge.net Thu May 22 15:21:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 07:21:45 -0700 Subject: [Patches] [ python-Patches-683074 ] Optional output streams for dis Message-ID: Patches item #683074, was opened at 2003-02-08 15:22 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: logistix (logistix) Assigned to: Raymond Hettinger (rhettinger) Summary: Optional output streams for dis Initial Comment: Right now the dis module uses print to output. This restricts it's use to interactive. You can't easily route the output to files, webpages, run re's on it, etc. This patch just adds an optional keyword parameter write that defaults to sys.stdout.write and replaces print statments with calls to write. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-22 10:21 Message: Logged In: YES user_id=31435 OK, closing this. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-05-22 09:09 Message: Logged In: YES user_id=699438 Raymond, This actually got a thumbs down on python-dev. You can just close it out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 From noreply@sourceforge.net Thu May 22 16:05:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 08:05:23 -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-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 May 22 17:18:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 09:18:42 -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-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 May 22 17:30:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 09:30:34 -0700 Subject: [Patches] [ python-Patches-683074 ] Optional output streams for dis Message-ID: Patches item #683074, was opened at 2003-02-08 15:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: logistix (logistix) Assigned to: Raymond Hettinger (rhettinger) Summary: Optional output streams for dis Initial Comment: Right now the dis module uses print to output. This restricts it's use to interactive. You can't easily route the output to files, webpages, run re's on it, etc. This patch just adds an optional keyword parameter write that defaults to sys.stdout.write and replaces print statments with calls to write. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:30 Message: Logged In: YES user_id=80475 Tim, there is a similar patch for pdb.py at www.python.org/sf/721464. Like Anthony's patch to cmd.py, I think it has a valid use case and should go in. Knowing why cmd.py was accepted and why dis.py was rejected, what do you think about pdb.py? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-22 09:21 Message: Logged In: YES user_id=31435 OK, closing this. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-05-22 08:09 Message: Logged In: YES user_id=699438 Raymond, This actually got a thumbs down on python-dev. You can just close it out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 From noreply@sourceforge.net Thu May 22 17:34:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 09:34:42 -0700 Subject: [Patches] [ python-Patches-683074 ] Optional output streams for dis Message-ID: Patches item #683074, was opened at 2003-02-08 15:22 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: logistix (logistix) Assigned to: Raymond Hettinger (rhettinger) Summary: Optional output streams for dis Initial Comment: Right now the dis module uses print to output. This restricts it's use to interactive. You can't easily route the output to files, webpages, run re's on it, etc. This patch just adds an optional keyword parameter write that defaults to sys.stdout.write and replaces print statments with calls to write. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-22 12:34 Message: Logged In: YES user_id=31435 Sorry, I don't have an opinion about pdb -- I've hardly ever used it. Do what you think is best, and Guido will hit you if he disagrees . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 12:30 Message: Logged In: YES user_id=80475 Tim, there is a similar patch for pdb.py at www.python.org/sf/721464. Like Anthony's patch to cmd.py, I think it has a valid use case and should go in. Knowing why cmd.py was accepted and why dis.py was rejected, what do you think about pdb.py? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-22 10:21 Message: Logged In: YES user_id=31435 OK, closing this. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-05-22 09:09 Message: Logged In: YES user_id=699438 Raymond, This actually got a thumbs down on python-dev. You can just close it out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 From noreply@sourceforge.net Thu May 22 18:33:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 10:33:29 -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-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 May 22 18:53:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 10:53:54 -0700 Subject: [Patches] [ python-Patches-683074 ] Optional output streams for dis Message-ID: Patches item #683074, was opened at 2003-02-08 14:22 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: logistix (logistix) Assigned to: Raymond Hettinger (rhettinger) Summary: Optional output streams for dis Initial Comment: Right now the dis module uses print to output. This restricts it's use to interactive. You can't easily route the output to files, webpages, run re's on it, etc. This patch just adds an optional keyword parameter write that defaults to sys.stdout.write and replaces print statments with calls to write. ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2003-05-22 12:53 Message: Logged In: YES user_id=699438 Basically, Guido was -1 saying you can redirect sys.stdout and no one else cared one way or the other. So it wasn't an outright rejection, more lack of interest. In my particular case, I was routing the output to a webserver, and was concerned about the thread safety of temporarily redirecting sys.stdout to a socket. After I sumbitted, I also realized I missed passing the write parameter into one of the calls. It should be easy to find but if you want a good patch let me know. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-22 11:34 Message: Logged In: YES user_id=31435 Sorry, I don't have an opinion about pdb -- I've hardly ever used it. Do what you think is best, and Guido will hit you if he disagrees . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:30 Message: Logged In: YES user_id=80475 Tim, there is a similar patch for pdb.py at www.python.org/sf/721464. Like Anthony's patch to cmd.py, I think it has a valid use case and should go in. Knowing why cmd.py was accepted and why dis.py was rejected, what do you think about pdb.py? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-22 09:21 Message: Logged In: YES user_id=31435 OK, closing this. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-05-22 08:09 Message: Logged In: YES user_id=699438 Raymond, This actually got a thumbs down on python-dev. You can just close it out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 From noreply@sourceforge.net Fri May 23 03:43:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 19:43:53 -0700 Subject: [Patches] [ python-Patches-742126 ] configure script is broken for OpenBSD 3.3 and up Message-ID: Patches item #742126, was opened at 2003-05-23 02: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=742126&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zachary Hamm (zshamm) Assigned to: Nobody/Anonymous (nobody) Summary: configure script is broken for OpenBSD 3.3 and up Initial Comment: configure.in has a fix for OpenBSD, something about broken select, anyway it limits this fix to only version 3.[012], which of course promptly breaks in 3.3. A healthy star has been added where once there were brackets... Of course autoconf will have to be run again. I think this is cleaner than just submitting a patch for the configure script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742126&group_id=5470 From noreply@sourceforge.net Thu May 22 22:34:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:34:42 -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 nnorwitz 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: Nobody/Anonymous (nobody) 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 17: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 Thu May 22 22:29:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:29:53 -0700 Subject: [Patches] [ python-Patches-703779 ] strange warnings messages in interpreter Message-ID: Patches item #703779, was opened at 2003-03-14 13:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=703779&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) >Assigned to: Nobody/Anonymous (nobody) Summary: strange warnings messages in interpreter Initial Comment: If the PYTHONSTARTUP environment variable is used, warnings will look strange. The warnings module uses __file__ to try to find the line causing the warning and print it out. __file__ is never reset after being set when processing the startup file. The attached patch fixes this by changing PyRun_SimpleFileExFlags to unset __file__ in the __main__ module dictionary entry after running a file, when it had been set by the routine in the first place. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:29 Message: Logged In: YES user_id=33168 Moving to patches ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=703779&group_id=5470 From noreply@sourceforge.net Fri May 23 13:48:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 05:48:00 -0700 Subject: [Patches] [ python-Patches-742290 ] unicode "support" for shlex.py Message-ID: Patches item #742290, was opened at 2003-05-23 14: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=742290&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode "support" for shlex.py Initial Comment: Due to shlex.py's use of cStringIO, it behaves badly when fed unicode strings. The attached patch fixes that by always using StringIO instead of cStringIO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742290&group_id=5470 From noreply@sourceforge.net Fri May 23 13:57:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 05:57:39 -0700 Subject: [Patches] [ python-Patches-742290 ] unicode "support" for shlex.py Message-ID: Patches item #742290, was opened at 2003-05-23 14:47 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742290&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode "support" for shlex.py Initial Comment: Due to shlex.py's use of cStringIO, it behaves badly when fed unicode strings. The attached patch fixes that by always using StringIO instead of cStringIO. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-23 14:57 Message: Logged In: YES user_id=92689 Ugh, I take that back: it doesn't fix it, there's a gross snippet in shlex.py that makes it barf: if self.posix: self.wordchars += ('??·???ÂÊÁËÈÍÎÏÌÓÔ?ÒÚÛÙ??¯???¸???' '¿¡¬????«»? ÀÃÕ????????÷ÿ??????') Help. I'd love to fix this, but I'm not sure what would be correct (my intuition says to just yank the above snippet, but I'm sure that'll make _someone_ unhappy...). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742290&group_id=5470 From noreply@sourceforge.net Fri May 23 22:11:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 14:11:34 -0700 Subject: [Patches] [ python-Patches-742598 ] SocketServer timeout, zombies Message-ID: Patches item #742598, was opened at 2003-05-23 21: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=742598&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Pomraning (pilcrow) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer timeout, zombies Initial Comment: Patch adds class variable 'timeout' to BaseServer, and methods await_request and handle_timeout. Backwards compatible API -- timeout is None by default, meaning await_request jumps directly to get_request and never calls handle_timeout. Facilitates periodic server bookkeeping (check config files, intervalic logging, etc.), if you supply your own serve loop. Additionally, ForkingMixin sets timeout to 300 seconds, and overrides handle_timeout to call collect_children. Upshot: n zombies linger in process table until 5 minutes pass or new request arrives, whichever comes first. docstring updates, too (s/reuse_address/allow_reuse_address, etc.) -Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742598&group_id=5470 From noreply@sourceforge.net Fri May 23 23:20:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 15:20:47 -0700 Subject: [Patches] [ python-Patches-742621 ] ast-branch: msvc project sync Message-ID: Patches item #742621, was opened at 2003-05-23 17: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=742621&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: msvc project sync Initial Comment: The PCBuild project files weren't updated to reflect the new files used by ast-branch. Attached is a patch to get it back into sync. It also adds references to Python-ast.h and code.h to zipimport.c and pyexpat.c so that they will compile properly. Parsermodule still won't compile [for obvious reasons ;-)] I couldn't figure out how to setup a command-line script in VC 6.0, so the adsl_c.py script would still need to be done manually to get a working compile. If anyone knows how the _ssl project was setup to run a python script, I'd appreciate some pointers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742621&group_id=5470 From noreply@sourceforge.net Sat May 24 13:32:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 05:32:05 -0700 Subject: [Patches] [ python-Patches-742290 ] unicode "support" for shlex.py Message-ID: Patches item #742290, was opened at 2003-05-23 14:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742290&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode "support" for shlex.py Initial Comment: Due to shlex.py's use of cStringIO, it behaves badly when fed unicode strings. The attached patch fixes that by always using StringIO instead of cStringIO. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 14:32 Message: Logged In: YES user_id=21627 To test whether a letter is a wordchar, you should check whether it .isalnum() or equals '_'. Then you can do away with self.wordchars, and it works the same for byte strings and Unicode strings. Non-ASCII characters in byte strings then work if locale.setlocale had been invoked. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-23 14:57 Message: Logged In: YES user_id=92689 Ugh, I take that back: it doesn't fix it, there's a gross snippet in shlex.py that makes it barf: if self.posix: self.wordchars += ('??·???ÂÊÁËÈÍÎÏÌÓÔ?ÒÚÛÙ??¯???¸???' '¿¡¬????«»? ÀÃÕ????????÷ÿ??????') Help. I'd love to fix this, but I'm not sure what would be correct (my intuition says to just yank the above snippet, but I'm sure that'll make _someone_ unhappy...). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742290&group_id=5470 From noreply@sourceforge.net Sat May 24 13:33:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 05:33:07 -0700 Subject: [Patches] [ python-Patches-742126 ] configure script is broken for OpenBSD 3.3 and up Message-ID: Patches item #742126, was opened at 2003-05-23 04:43 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742126&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zachary Hamm (zshamm) >Assigned to: Martin v. Löwis (loewis) Summary: configure script is broken for OpenBSD 3.3 and up Initial Comment: configure.in has a fix for OpenBSD, something about broken select, anyway it limits this fix to only version 3.[012], which of course promptly breaks in 3.3. A healthy star has been added where once there were brackets... Of course autoconf will have to be run again. I think this is cleaner than just submitting a patch for the configure script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742126&group_id=5470 From noreply@sourceforge.net Sat May 24 13:38:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 05:38:29 -0700 Subject: [Patches] [ python-Patches-742126 ] configure script is broken for OpenBSD 3.3 and up Message-ID: Patches item #742126, was opened at 2003-05-23 04:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742126&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Zachary Hamm (zshamm) Assigned to: Martin v. Löwis (loewis) Summary: configure script is broken for OpenBSD 3.3 and up Initial Comment: configure.in has a fix for OpenBSD, something about broken select, anyway it limits this fix to only version 3.[012], which of course promptly breaks in 3.3. A healthy star has been added where once there were brackets... Of course autoconf will have to be run again. I think this is cleaner than just submitting a patch for the configure script. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 14:38 Message: Logged In: YES user_id=21627 Please read the comment above the section you are editing. The "healthy star" is extremely unhealty, as it refers to future systems. How can you know the patch will still be needed in 3.4? Failure to compile if _XOPEN_SOURCE is defined is a bug in OpenBSD, and you should consider reporting it to them. So I have just added 3.3 to the list of broken systems, and committed the changes as configure.in 1.411, configure 1.400. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742126&group_id=5470 From noreply@sourceforge.net Sat May 24 16:52:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 08:52:07 -0700 Subject: [Patches] [ python-Patches-742741 ] check for true in diffrent paths, -pthread support Message-ID: Patches item #742741, was opened at 2003-05-24 17: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=742741&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: check for true in diffrent paths, -pthread support Initial Comment: This patch fixes/adds two things in configure.in 1) add support for the "-pthread" CC flag . (Tested on NetBSD-current, should work on FreeBSD and Linux, too) 2) /bin/true isn't available on NetBSD, so check for it in different places. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742741&group_id=5470 From noreply@sourceforge.net Sat May 24 16:54:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 08:54:56 -0700 Subject: [Patches] [ python-Patches-742741 ] check for true in diffrent paths, -pthread support Message-ID: Patches item #742741, was opened at 2003-05-24 17:52 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742741&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: check for true in diffrent paths, -pthread support Initial Comment: This patch fixes/adds two things in configure.in 1) add support for the "-pthread" CC flag . (Tested on NetBSD-current, should work on FreeBSD and Linux, too) 2) /bin/true isn't available on NetBSD, so check for it in different places. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-05-24 17:54 Message: Logged In: YES user_id=205 Forgot to mention that it's against Python 2.3cvs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742741&group_id=5470 From noreply@sourceforge.net Sat May 24 18:39:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 10:39:22 -0700 Subject: [Patches] [ python-Patches-742741 ] check for true in diffrent paths, -pthread support Message-ID: Patches item #742741, was opened at 2003-05-24 17:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742741&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: check for true in diffrent paths, -pthread support Initial Comment: This patch fixes/adds two things in configure.in 1) add support for the "-pthread" CC flag . (Tested on NetBSD-current, should work on FreeBSD and Linux, too) 2) /bin/true isn't available on NetBSD, so check for it in different places. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 19:39 Message: Logged In: YES user_id=21627 I just noticed a problem with the entire -Kthread/-Kpthread approach: there are specific additional checks needed for pthreads, e.g. for SCOPE_SYSTEM, for various Solaris versions, etc. Those need to happen independently of the means to activate threads. Would you please revise your patch to address this issue as well? ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-05-24 17:54 Message: Logged In: YES user_id=205 Forgot to mention that it's against Python 2.3cvs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742741&group_id=5470 From noreply@sourceforge.net Sat May 24 19:47:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 11:47:12 -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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742823&group_id=5470 From noreply@sourceforge.net Sat May 24 20:12:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 12:12:38 -0700 Subject: [Patches] [ python-Patches-740301 ] HP-UX support for unixccompiler.py Message-ID: Patches item #740301, was opened at 2003-05-20 09:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740301&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX support for unixccompiler.py Initial Comment: gcc on hp-ux uses the native linker, so if gcc is used there, the normal gcc flags for linker do not apply. I propose the attached patch to unixccompiler.py. The patch also adds +s, which means that SHLIB_PATH is honored (the same as LD_LIBRARY_PATH on Linux/Solaris). I don't have the HP-UX native compiler, but I would think that this patch should also fix that, as it shares the common linker. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 21:12 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. 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=740301&group_id=5470 From noreply@sourceforge.net Sun May 25 14:22:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 06:22:24 -0700 Subject: [Patches] [ python-Patches-742741 ] check for true in diffrent paths, -pthread support Message-ID: Patches item #742741, was opened at 2003-05-24 17:52 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742741&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: check for true in diffrent paths, -pthread support Initial Comment: This patch fixes/adds two things in configure.in 1) add support for the "-pthread" CC flag . (Tested on NetBSD-current, should work on FreeBSD and Linux, too) 2) /bin/true isn't available on NetBSD, so check for it in different places. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-05-25 15:22 Message: Logged In: YES user_id=205 Seperated some pthread related checks. They're happen now after the detection of the thread library and only if "$posix_threads" = "yes". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 19:39 Message: Logged In: YES user_id=21627 I just noticed a problem with the entire -Kthread/-Kpthread approach: there are specific additional checks needed for pthreads, e.g. for SCOPE_SYSTEM, for various Solaris versions, etc. Those need to happen independently of the means to activate threads. Would you please revise your patch to address this issue as well? ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-05-24 17:54 Message: Logged In: YES user_id=205 Forgot to mention that it's against Python 2.3cvs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742741&group_id=5470 From noreply@sourceforge.net Sun May 25 15:33:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 07:33:00 -0700 Subject: [Patches] [ python-Patches-719359 ] fix test_long failure on OSF/1 Message-ID: Patches item #719359, was opened at 2003-04-10 19:15 Message generated for change (Comment added) made by nnorwitz 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: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) 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: Neal Norwitz (nnorwitz) Date: 2003-05-25 10: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 Sun May 25 15:42:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 07:42:38 -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.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) >Assigned to: Tim Peters (tim_one) 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-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 Sun May 25 16:19:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 08:19:20 -0700 Subject: [Patches] [ python-Patches-719359 ] fix test_long failure on OSF/1 Message-ID: Patches item #719359, was opened at 2003-04-10 19:15 Message generated for change (Comment added) made by tim_one 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: Open Resolution: None 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: Tim Peters (tim_one) Date: 2003-05-25 11: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 10: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 Sun May 25 16:28:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 08:28:14 -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 tim_one 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: Open 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: 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 Sun May 25 17:40:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 09:40:53 -0700 Subject: [Patches] [ python-Patches-719359 ] fix test_long failure on OSF/1 Message-ID: Patches item #719359, was opened at 2003-04-10 19:15 Message generated for change (Comment added) made by nnorwitz 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: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Martin v. Löwis (loewis) 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: Neal Norwitz (nnorwitz) Date: 2003-05-25 12: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 11: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 10: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 Sun May 25 21:40:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 13:40:21 -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 loewis 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: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) 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 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 May 26 00:49:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 16:49:02 -0700 Subject: [Patches] [ python-Patches-719359 ] fix test_long failure on OSF/1 Message-ID: Patches item #719359, was opened at 2003-04-10 19:15 Message generated for change (Comment added) made by nnorwitz 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: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) 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: Neal Norwitz (nnorwitz) Date: 2003-05-25 19: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 16: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 12: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 11: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 10: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 May 26 06:38:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 22:38:20 -0700 Subject: [Patches] [ python-Patches-742741 ] check for true in diffrent paths, -pthread support Message-ID: Patches item #742741, was opened at 2003-05-24 17:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742741&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: check for true in diffrent paths, -pthread support Initial Comment: This patch fixes/adds two things in configure.in 1) add support for the "-pthread" CC flag . (Tested on NetBSD-current, should work on FreeBSD and Linux, too) 2) /bin/true isn't available on NetBSD, so check for it in different places. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-26 07:38 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure 1.401 configure.in 1.412 ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-05-25 15:22 Message: Logged In: YES user_id=205 Seperated some pthread related checks. They're happen now after the detection of the thread library and only if "$posix_threads" = "yes". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 19:39 Message: Logged In: YES user_id=21627 I just noticed a problem with the entire -Kthread/-Kpthread approach: there are specific additional checks needed for pthreads, e.g. for SCOPE_SYSTEM, for various Solaris versions, etc. Those need to happen independently of the means to activate threads. Would you please revise your patch to address this issue as well? ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-05-24 17:54 Message: Logged In: YES user_id=205 Forgot to mention that it's against Python 2.3cvs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742741&group_id=5470 From noreply@sourceforge.net Mon May 26 06:40:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 22:40:01 -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 loewis 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: Open >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 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 May 26 14:50:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 06:50:01 -0700 Subject: [Patches] [ python-Patches-735694 ] Pydoc.py fixes links Message-ID: Patches item #735694, was opened at 2003-05-10 08:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735694&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Raymond A. St. Marie (rastm2) >Assigned to: Neal Norwitz (nnorwitz) Summary: Pydoc.py fixes links Initial Comment: This is for Ka-Ping Yee. The links to certain python docs are incorrect in the document server link dictionary called "class Helper" about line 1377 to 1490' of pydoc.py . The corrected section of code is attached. You should be able to cut and paste the code right over the original code and save the file to fix all your links. The individual changes I made follow the code. Ping, if this helps, please drop me a line. I'm a newbie programmer, so make sure you look over the changes. It would make my day to get a word from a real programmer - if this is correct or otherwise. If it's already been fixed, then I'm sorry to waste you time. :) Thanks, Ray St. Marie Rastm2@aol.com ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 09:50 Message: Logged In: YES user_id=33168 Thanks for the patch. Some of the changes have been made already. I modified the patch a bit. You can browse the CVS repository to view the changes. Next time, please produce a context diff using cvs diff -c or diff -c against the current version of the file from CVS. It is easier to apply the patches. Checked in as Lib/pydoc.py 1.83 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=735694&group_id=5470 From noreply@sourceforge.net Mon May 26 15:12:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 07:12:46 -0700 Subject: [Patches] [ python-Patches-719359 ] fix test_long failure on OSF/1 Message-ID: Patches item #719359, was opened at 2003-04-10 19:15 Message generated for change (Comment added) made by nnorwitz 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: Neal Norwitz (nnorwitz) Date: 2003-05-26 10: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 01: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-25 19: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 16: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 12: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 11: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 10: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 Tue May 27 06:30:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 22:30:13 -0700 Subject: [Patches] [ python-Patches-744041 ] fix BaseHTTPServer for ipv6 Message-ID: Patches item #744041, was opened at 2003-05-27 05: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=744041&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: cypherpunks (cypherpunks) Assigned to: Nobody/Anonymous (nobody) Summary: fix BaseHTTPServer for ipv6 Initial Comment: trivial fix, tested with edna. would be really cool if it got into python 2.3... -- Erno Kuusela ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744041&group_id=5470 From noreply@sourceforge.net Tue May 27 08:43:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 00:43:35 -0700 Subject: [Patches] [ python-Patches-744104 ] Removed eval() from csv Message-ID: Patches item #744104, was opened at 2003-05-27 02: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=744104&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Skip Montanaro (montanaro) Summary: Removed 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 From noreply@sourceforge.net Tue May 27 08:44:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 00:44:54 -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: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Skip Montanaro (montanaro) >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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744104&group_id=5470 From noreply@sourceforge.net Tue May 27 13:47:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 05:47:35 -0700 Subject: [Patches] [ python-Patches-744233 ] Add link to __future__ in module index Message-ID: Patches item #744233, was opened at 2003-05-27 12: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=744233&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: Add link to __future__ in module index Initial Comment: The attached patch adds __future__ to the module index. It adds a libfuture.tex. This behaves more or less the same as libbltin.tex: it links to ../ref/module-future.html. I tried to sent this earlier and e-mailed to python-docs when it failed, but now I succeeded in sending a patch. I was unable to get cvs to add the new file to the diff, so I copied the directory to be able to do diff -Nrc. Gerrit Holl. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744233&group_id=5470 From noreply@sourceforge.net Tue May 27 13:52:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 05:52:56 -0700 Subject: [Patches] [ python-Patches-744238 ] Error in comparison documentation Message-ID: Patches item #744238, was opened at 2003-05-27 12:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744238&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: Error in comparison documentation Initial Comment: Hi, libstdtypes.tex line 147-148 reads: Objects of different types, except different numeric types, never compare equal; However, this is incorrect, because u"" == "" but u"".class != "".class. This should be: Objects of different types, except different numeric types and different string types, never compare equal; ...or something similar. The attached patch fixes this. yours, Gerrit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744238&group_id=5470 From noreply@sourceforge.net Tue May 27 16:13:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 08:13:22 -0700 Subject: [Patches] [ python-Patches-744321 ] Migrate to new-style classes Message-ID: Patches item #744321, was opened at 2003-05-27 15:13 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=744321&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Migrate to new-style classes Initial Comment: This patch changes all old-style classes to new-style classes in the standard library. This should be safe, because all exceptions derive from Exception, so they are not new-style classes as long as Exception isn't., and the exceptions module is built-in. This can be wished to prevent class Foo(HTTPLib, object) or similar. It is almost completely backwards-compatible, although in some rare cases a MRO-conflict may occur. The script I used to do this is as follows: #!/usr/bin/python import re import sys pattern = "(^ *class [A-Za-z_][A-Za-z0-9_]*[^()]+)(:)" for f in sys.argv[1:]: print "handling", f lines = open(f, 'r').readlines() fp = open(f, 'w') for line in lines: fp.write(re.sub(pattern, r"\1(object)\2", line)) ...and... $ python /tmp/repl.py $(find . -name "*.py" | grep -v lib-old) $ grep "^RCS " ~/newclass.diff | wc -l 279 $ find . -name "*.py" | wc -l 942 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744321&group_id=5470 From noreply@sourceforge.net Tue May 27 23:49:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 15:49:12 -0700 Subject: [Patches] [ python-Patches-728744 ] Fixes for setup.py in Mac/OSX/Docs Message-ID: Patches item #728744, was opened at 2003-04-28 07:52 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728744&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Jack Jansen (jackjansen) Summary: Fixes for setup.py in Mac/OSX/Docs Initial Comment: This patch allows the docs to be installed in a one-step process, e.g. python setup.py install, rather than the two or three steps required previously. I tried to use Python's built-in OSA support, but I could not get reliable results, so I used osascript instead. I'm not sure if my attempt to use OSA failed because I had no idea of what I was doing, or if there are some problems with the OSA support. I left the OSA support in, but commented out. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-28 00:49 Message: Logged In: YES user_id=45365 Thank you very much for finding this! I did manage to get this to work with a scripting module, so I used that in stead. I still don't understand _why_ it works the way it does, though:-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728744&group_id=5470 From noreply@sourceforge.net Wed May 28 02:59:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 18:59:41 -0700 Subject: [Patches] [ python-Patches-731328 ] AssertionError when building rpm under RedHat 9.1 Message-ID: Patches item #731328, was opened at 2003-05-02 09:56 Message generated for change (Comment added) made by niederberger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731328&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ricardo Niederberger Cabral (niederberger) Assigned to: Nobody/Anonymous (nobody) Summary: AssertionError when building rpm under RedHat 9.1 Initial Comment: When trying to build an rpm on RH 9: >From distutils __version__ = "1.0.3": File "distutils/command/bdist_rpm.py", line 316, in run assert len(rpms) == 1, \ AssertionError: unexpected number of RPM files found: ['build/bdist. linux-i686/rpm/RPMS/i386/imgSeek-0.7-1.i386.rpm', 'build/bdist. linux-i686/rpm/RPMS/i386/imgSeek-debuginfo-0.7-1.i386.rpm'] I had to remove the assert statement on bdist_rpm.py:316 in order to build my rpm since rpmbuild from RH always seems to generate this extra -debuginfo rpm. So attached is a patch (cvs rev 1.37) to simply copy all generated RPM's to the dist/ directory. ---------------------------------------------------------------------- >Comment By: Ricardo Niederberger Cabral (niederberger) Date: 2003-05-27 22:59 Message: Logged In: YES user_id=354686 Sorry for not replying faster and providing more info. SF tracker didn't email me about your comment, and I don't have the RH system at hand right now. Anyway, it generates: foo-version.i386.rpm foo-version.src.rpm foo-debuginfo-version.i386.rpm instead of only the binary and src rpm's I would get on Mandrake 9 for example, which is what bdist_rpm.py currently expects. I don't know exactly what goes inside this debug-info rpm, but i guess it's probably the binary one compiled with debug symbols on. I can provide more info if necessary in a few days. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 08:01 Message: Logged In: YES user_id=21627 Can you provide more information? What rpm gets generated, and what files does it contain? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731328&group_id=5470 From noreply@sourceforge.net Wed May 28 12:33:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 04:33:30 -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 jhylton 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: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Jeremy Hylton (jhylton) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742823&group_id=5470 From noreply@sourceforge.net Wed May 28 12:33:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 04:33:45 -0700 Subject: [Patches] [ python-Patches-742621 ] ast-branch: msvc project sync Message-ID: Patches item #742621, was opened at 2003-05-23 22:20 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742621&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Jeremy Hylton (jhylton) Summary: ast-branch: msvc project sync Initial Comment: The PCBuild project files weren't updated to reflect the new files used by ast-branch. Attached is a patch to get it back into sync. It also adds references to Python-ast.h and code.h to zipimport.c and pyexpat.c so that they will compile properly. Parsermodule still won't compile [for obvious reasons ;-)] I couldn't figure out how to setup a command-line script in VC 6.0, so the adsl_c.py script would still need to be done manually to get a working compile. If anyone knows how the _ssl project was setup to run a python script, I'd appreciate some pointers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742621&group_id=5470 From noreply@sourceforge.net Wed May 28 12:40:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 04:40:51 -0700 Subject: [Patches] [ python-Patches-744321 ] Migrate to new-style classes Message-ID: Patches item #744321, was opened at 2003-05-27 15:13 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744321&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Migrate to new-style classes Initial Comment: This patch changes all old-style classes to new-style classes in the standard library. This should be safe, because all exceptions derive from Exception, so they are not new-style classes as long as Exception isn't., and the exceptions module is built-in. This can be wished to prevent class Foo(HTTPLib, object) or similar. It is almost completely backwards-compatible, although in some rare cases a MRO-conflict may occur. The script I used to do this is as follows: #!/usr/bin/python import re import sys pattern = "(^ *class [A-Za-z_][A-Za-z0-9_]*[^()]+)(:)" for f in sys.argv[1:]: print "handling", f lines = open(f, 'r').readlines() fp = open(f, 'w') for line in lines: fp.write(re.sub(pattern, r"\1(object)\2", line)) ...and... $ python /tmp/repl.py $(find . -name "*.py" | grep -v lib-old) $ grep "^RCS " ~/newclass.diff | wc -l 279 $ find . -name "*.py" | wc -l 942 ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-28 11:40 Message: Logged In: YES user_id=31392 We'll do holistic refactoring of modules to upgrade them to new-style classes, rather than a blanket change. As you note, new-style classes aren't semantically identical to classic classes; the differences need to be accounted for. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744321&group_id=5470 From noreply@sourceforge.net Wed May 28 12:47:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 04:47:42 -0700 Subject: [Patches] [ python-Patches-731153 ] redirect fails in urllib2 Message-ID: Patches item #731153, was opened at 2003-05-02 04:58 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731153&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) >Assigned to: Jeremy Hylton (jhylton) Summary: redirect fails in urllib2 Initial Comment: There were two simple errors in urllib2's redirection code. In two cases, req.method was being invoked when the author meant req.get_method. The second error was the failure to make the redirected URL available to the redirect handler; I passed it as a parameter, but it could have been added as another instance variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731153&group_id=5470 From noreply@sourceforge.net Wed May 28 12:51:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 04:51:14 -0700 Subject: [Patches] [ python-Patches-742621 ] ast-branch: msvc project sync Message-ID: Patches item #742621, was opened at 2003-05-24 00:20 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742621&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Jeremy Hylton (jhylton) Summary: ast-branch: msvc project sync Initial Comment: The PCBuild project files weren't updated to reflect the new files used by ast-branch. Attached is a patch to get it back into sync. It also adds references to Python-ast.h and code.h to zipimport.c and pyexpat.c so that they will compile properly. Parsermodule still won't compile [for obvious reasons ;-)] I couldn't figure out how to setup a command-line script in VC 6.0, so the adsl_c.py script would still need to be done manually to get a working compile. If anyone knows how the _ssl project was setup to run a python script, I'd appreciate some pointers. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-05-28 13:51 Message: Logged In: YES user_id=11105 Logistix, to add a command line project in MSVC6, you select 'Add new Project to workspace' from the pcbuild workspace context menu, and in the dialog that appears you click the 'Makefile' icon in the projects tab, enter a project name, click ok and then you can enter the command lines to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742621&group_id=5470 From noreply@sourceforge.net Wed May 28 12:58:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 04:58:51 -0700 Subject: [Patches] [ python-Patches-744233 ] Add link to __future__ in module index Message-ID: Patches item #744233, was opened at 2003-05-27 12:47 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744233&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gerrit Holl (gerrit) >Assigned to: Jeremy Hylton (jhylton) Summary: Add link to __future__ in module index Initial Comment: The attached patch adds __future__ to the module index. It adds a libfuture.tex. This behaves more or less the same as libbltin.tex: it links to ../ref/module-future.html. I tried to sent this earlier and e-mailed to python-docs when it failed, but now I succeeded in sending a patch. I was unable to get cvs to add the new file to the diff, so I copied the directory to be able to do diff -Nrc. Gerrit Holl. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-28 11:58 Message: Logged In: YES user_id=31392 This patch isn't quite right, because the appendix has been removed from the reference manual. But it did remind me to finish the checkins I had started for the reorganization. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744233&group_id=5470 From noreply@sourceforge.net Wed May 28 13:56:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 05:56:22 -0700 Subject: [Patches] [ python-Patches-744877 ] Clarifications in libfuncs.tex Message-ID: Patches item #744877, was opened at 2003-05-28 12: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=744877&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: Clarifications in libfuncs.tex Initial Comment: This patch adds some clarifications is libfuncs.tex and removes some outdated information: * The filter() documentation now mentions list comprehensions in order to explain equality to another way to express the same. * The reference to string.atoi() in the int() documentation was removed, since string.atoi() is deprecated. * The sum() documentation mentions reduce() in order to explain equality to another way to express the same. I am not sure whether all those changes are wished: if 2 or less changes are wished, it surely is possible to only apply 2 or less changes ;). Is there a list with wishes for the documentation somewhere? Is it only the SF bug list or is there more? Gerrit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744877&group_id=5470 From noreply@sourceforge.net Thu May 29 01:59:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 17:59:26 -0700 Subject: [Patches] [ python-Patches-675864 ] patch for new func. string.findall Message-ID: Patches item #675864, was opened at 2003-01-27 18:00 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675864&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: patch for new func. string.findall Initial Comment: this finds all indices of a substring in a string returning in list form. Its not in pydoc2.3. This "patch" contains unittests. #!/usr/bin/python import string def findall(sub,s): if s =='' or sub =='': return [] ret=[] findval=0 pos=0 while findval != -1: findval = s.find(sub,pos) if findval != -1: ret.append(findval) pos = findval + len(sub) return ret if __name__ == '__main__': units = [ 'asdsad','l', 'l','asdlsds', 'l','lsdlsds', 'l','lsdsds', 'l','sdsds', 'l','sdsdsl', 'l','lsdsdsl', 'l','lsdlsdsl', 'l','l', 'l','ll', 'l','lll', 'lo','llollol', 'lo','llollolo', '','', '','asdasd', 'asdsad','' ] for i in range(0,len(units),2): sub,s = units[i],units[i+1] print "'%s' in '%s':"%(sub,s) print findall(sub,s) print "-"*30 print 'done' ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-28 17:59 Message: Logged In: YES user_id=357491 The string module is deprecated so adding anything to the module is a big no-no. If you still want to see this functionality it will require being added to the string type. I am also changing this to a patch since it has working code (albeit as-is it would be rejected). ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-31 01:31 Message: Logged In: YES user_id=479934 Theres now a indented version of that which was pasted above that is attached to this bug. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-27 18:01 Message: Logged In: YES user_id=479934 This might be done as an iterator as well, as re.findall also is complemented by an re.finditer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675864&group_id=5470 From noreply@sourceforge.net Thu May 29 18:00:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 10:00:02 -0700 Subject: [Patches] [ python-Patches-745620 ] build shared lib as ".so" for NetBSD Message-ID: Patches item #745620, was opened at 2003-05-29 19:00 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=745620&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: build shared lib as ".so" for NetBSD Initial Comment: Build the shared lib on NetBSD as ".so". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=745620&group_id=5470 From noreply@sourceforge.net Fri May 30 23:28:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 15:28:39 -0700 Subject: [Patches] [ python-Patches-746376 ] Prevent Jump to self Message-ID: Patches item #746376, was opened at 2003-05-30 17: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=746376&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent Jump to self Initial Comment: As discussed on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746376&group_id=5470 From noreply@sourceforge.net Fri May 30 23:57:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 15:57:39 -0700 Subject: [Patches] [ python-Patches-746376 ] Prevent Jump to self Message-ID: Patches item #746376, was opened at 2003-05-30 17:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746376&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent Jump to self Initial Comment: As discussed on python-dev. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-30 17:57 Message: Logged In: YES user_id=80475 Neil S. proposed a better approach of having JUMP_ABSOLUTE not use goto fast_next_opcode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746376&group_id=5470 From noreply@sourceforge.net Sat May 31 00:30:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 16:30:16 -0700 Subject: [Patches] [ python-Patches-745620 ] build shared lib as ".so" for NetBSD Message-ID: Patches item #745620, was opened at 2003-05-29 19:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=745620&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: build shared lib as ".so" for NetBSD Initial Comment: Build the shared lib on NetBSD as ".so". ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-31 01:30 Message: Logged In: YES user_id=21627 Isn't this the same as Linux*|GNU*? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=745620&group_id=5470 From noreply@sourceforge.net Sat May 31 00:31:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 16:31:26 -0700 Subject: [Patches] [ python-Patches-744041 ] fix BaseHTTPServer for ipv6 Message-ID: Patches item #744041, was opened at 2003-05-27 07:30 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744041&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: cypherpunks (cypherpunks) >Assigned to: Martin v. Löwis (loewis) Summary: fix BaseHTTPServer for ipv6 Initial Comment: trivial fix, tested with edna. would be really cool if it got into python 2.3... -- Erno Kuusela ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744041&group_id=5470 From noreply@sourceforge.net Sat May 31 01:04:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 17:04:38 -0700 Subject: [Patches] [ python-Patches-745620 ] build shared lib as ".so" for NetBSD Message-ID: Patches item #745620, was opened at 2003-05-29 19:00 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=745620&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: build shared lib as ".so" for NetBSD Initial Comment: Build the shared lib on NetBSD as ".so". ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-05-31 02:04 Message: Logged In: YES user_id=205 Yes, I copy&pasted it from the Linux*|GNU* case. I thought it would be a good idea to sepperate Linux & NetBSD... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-31 01:30 Message: Logged In: YES user_id=21627 Isn't this the same as Linux*|GNU*? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=745620&group_id=5470 From noreply@sourceforge.net Sat May 31 02:38:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 18:38:06 -0700 Subject: [Patches] [ python-Patches-746376 ] Prevent Jump to self Message-ID: Patches item #746376, was opened at 2003-05-30 17:28 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746376&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent Jump to self Initial Comment: As discussed on python-dev. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-30 17:57 Message: Logged In: YES user_id=80475 Neil S. proposed a better approach of having JUMP_ABSOLUTE not use goto fast_next_opcode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=746376&group_id=5470 From noreply@sourceforge.net Sat May 31 08:56:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 00:56:09 -0700 Subject: [Patches] [ python-Patches-744041 ] fix BaseHTTPServer for ipv6 Message-ID: Patches item #744041, was opened at 2003-05-27 07:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744041&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: cypherpunks (cypherpunks) Assigned to: Martin v. Löwis (loewis) Summary: fix BaseHTTPServer for ipv6 Initial Comment: trivial fix, tested with edna. would be really cool if it got into python 2.3... -- Erno Kuusela ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-31 09:56 Message: Logged In: YES user_id=21627 Thanks, applied as BaseHTTPServer 1.26. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744041&group_id=5470 From noreply@sourceforge.net Sat May 31 08:59:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 00:59:37 -0700 Subject: [Patches] [ python-Patches-745620 ] build shared lib as ".so" for NetBSD Message-ID: Patches item #745620, was opened at 2003-05-29 19:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=745620&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: build shared lib as ".so" for NetBSD Initial Comment: Build the shared lib on NetBSD as ".so". ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-31 09:59 Message: Logged In: YES user_id=21627 I think it serves readability better if identical cases are listed together. Committed as configure 1.403 configure.in 1.414 ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-05-31 02:04 Message: Logged In: YES user_id=205 Yes, I copy&pasted it from the Linux*|GNU* case. I thought it would be a good idea to sepperate Linux & NetBSD... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-31 01:30 Message: Logged In: YES user_id=21627 Isn't this the same as Linux*|GNU*? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=745620&group_id=5470 From noreply@sourceforge.net Sat May 31 09:03:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 01:03:49 -0700 Subject: [Patches] [ python-Patches-744877 ] Clarifications in libfuncs.tex Message-ID: Patches item #744877, was opened at 2003-05-28 14:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744877&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: Clarifications in libfuncs.tex Initial Comment: This patch adds some clarifications is libfuncs.tex and removes some outdated information: * The filter() documentation now mentions list comprehensions in order to explain equality to another way to express the same. * The reference to string.atoi() in the int() documentation was removed, since string.atoi() is deprecated. * The sum() documentation mentions reduce() in order to explain equality to another way to express the same. I am not sure whether all those changes are wished: if 2 or less changes are wished, it surely is possible to only apply 2 or less changes ;). Is there a list with wishes for the documentation somewhere? Is it only the SF bug list or is there more? Gerrit ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-31 10:03 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libfuncs.tex 1.133. All issues are tracked on SF, although wishlist items are best added to the RFE (request for enhancements) tracker (unless they are accompanied with patches, in which case the patch tracker is best). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744877&group_id=5470 From noreply@sourceforge.net Sat May 31 09:06:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 01:06:12 -0700 Subject: [Patches] [ python-Patches-744238 ] Error in comparison documentation Message-ID: Patches item #744238, was opened at 2003-05-27 14:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744238&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: Error in comparison documentation Initial Comment: Hi, libstdtypes.tex line 147-148 reads: Objects of different types, except different numeric types, never compare equal; However, this is incorrect, because u"" == "" but u"".class != "".class. This should be: Objects of different types, except different numeric types and different string types, never compare equal; ...or something similar. The attached patch fixes this. yours, Gerrit. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-31 10:06 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libstdtypes.tex 1.126 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=744238&group_id=5470 From noreply@sourceforge.net Sat May 31 09:11:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 01:11:28 -0700 Subject: [Patches] [ python-Patches-740301 ] HP-UX support for unixccompiler.py Message-ID: Patches item #740301, was opened at 2003-05-20 09:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740301&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX support for unixccompiler.py Initial Comment: gcc on hp-ux uses the native linker, so if gcc is used there, the normal gcc flags for linker do not apply. I propose the attached patch to unixccompiler.py. The patch also adds +s, which means that SHLIB_PATH is honored (the same as LD_LIBRARY_PATH on Linux/Solaris). I don't have the HP-UX native compiler, but I would think that this patch should also fix that, as it shares the common linker. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-31 10:11 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as unixccompiler.py 1.53. I'm a bit surprised that this patch is correct. We are talking about *runtime* library dir options here. I take it that HP-UX does not have the notion of runtime library dirs? as -L is surely used for link time library dirs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 21:12 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. 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=740301&group_id=5470