From noreply@sourceforge.net Tue Aug 1 00:51:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Jul 2000 16:51:08 -0700 Subject: [Patches] [Patch #101032] os.popen#.close() exit code under Windows enhancement Message-ID: <200007312351.QAA29078@delerium.i.sourceforge.net> Patch #101032 has been updated. Project: Category: core (C code) Status: Open Summary: os.popen#.close() exit code under Windows enhancement ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101032&group_id=5470 From noreply@sourceforge.net Tue Aug 1 01:42:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Jul 2000 17:42:10 -0700 Subject: [Patches] [Patch #101033] Use METH_VARARGS constant in Modules/ Message-ID: <200008010042.RAA31969@bush.i.sourceforge.net> Patch #101033 has been updated. Project: Category: core (C code) Status: Open Summary: Use METH_VARARGS constant in Modules/ ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101033&group_id=5470 From noreply@sourceforge.net Tue Aug 1 03:00:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Jul 2000 19:00:21 -0700 Subject: [Patches] [Patch #100705] Supporting PyXML Message-ID: <200008010200.TAA00565@delerium.i.sourceforge.net> Patch #100705 has been updated. Project: Category: None Status: Rejected Summary: Supporting PyXML Follow-Ups: Date: 2000-Jul-10 19:58 By: gstein Comment: I believe this patch should be rejected. Messing with __path__ is troublesome from a long-term viewpoint. I would urge the adoption of the scheme I posted to xml-sig: http://www.python.org/pipermail/xml-sig/2000-June/004512.html ------------------------------------------------------- Date: 2000-Jul-11 02:59 By: loewis Comment: Implementing Greg's scheme means that all modules of the xml package are loaded recursively when the first module in this hierarchy is imported. This patch avoids this startup overhead, as included modules are loaded on demand. ------------------------------------------------------- Date: 2000-Jul-11 22:51 By: fdrake Comment: I'll bring up the import-machinery issue at tomorrow's PythonLabs meeting; this came up at the last big meeting as well and needs to be dealt with to determine appropriate handling of this patch. This remains on my plate pending the results of tomorrow's meeting. ------------------------------------------------------- Date: 2000-Jul-31 19:00 By: fdrake Comment: An alternate approach was chosen to support overriding the xml package instead of extending the package. See Lib/xml/__init__.py for details. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100705&group_id=5470 From noreply@sourceforge.net Wed Aug 2 00:56:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 1 Aug 2000 16:56:25 -0700 Subject: [Patches] [Patch #101032] os.popen#.close() exit code under Windows enhancement Message-ID: <200008012356.QAA11262@delerium.i.sourceforge.net> Patch #101032 has been updated. Project: Category: core (C code) Status: Open Summary: os.popen#.close() exit code under Windows enhancement Follow-Ups: Date: 2000-Jul-31 16:57 By: db3l Comment: This is an enhancement to a prior patch (100941) originally supplied to add exit code processing to the win32pipe-based routines included in posixmodule.c. Based on the need for the higher order (os.popen# where # >=2) functions to close handles in different orders, and on discussion in c.l.py, this patch removes the risk of deadlock waiting for the child previously present in certain cases. It adds tracking of all file handles returned from an os.popen* call and only waits for the child process, returning the exit code, on the closure of the final file handle to that child. It also touches the w9xpopen.c file in order to properly bubble up exit codes under Windows 95/98 to permit these changes to work on those platforms as well. The patch is rooted in the dist/src directory. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101032&group_id=5470 From noreply@sourceforge.net Wed Aug 2 11:48:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 2 Aug 2000 03:48:07 -0700 Subject: [Patches] [Patch #100720] We don't want to link with libnet on non-BeOS systems Message-ID: <200008021048.DAA30577@delerium.i.sourceforge.net> Patch #100720 has been updated. Project: Category: None Status: Closed Summary: We don't want to link with libnet on non-BeOS systems Follow-Ups: Date: 2000-Jul-03 17:18 By: tim_one Comment: Assigned to Guido (another short config fix). ------------------------------------------------------- Date: 2000-Jul-27 13:22 By: gvanrossum Comment: Sure, check it in. (I think this might have been needed on other platforms at some point -- if that's still needed, we'll find out soon enough.) ------------------------------------------------------- Date: 2000-Aug-02 03:48 By: twouters Comment: This seems to be checked-in already, so it should be Closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100720&group_id=5470 From noreply@sourceforge.net Wed Aug 2 12:50:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 2 Aug 2000 04:50:39 -0700 Subject: [Patches] [Patch #101043] Description of what can go wrong in ioctl Message-ID: <200008021150.EAA01742@bush.i.sourceforge.net> Patch #101043 has been updated. Project: Category: documentation Status: Open Summary: Description of what can go wrong in ioctl ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101043&group_id=5470 From noreply@sourceforge.net Wed Aug 2 14:13:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 2 Aug 2000 06:13:29 -0700 Subject: [Patches] [Patch #101046] fcntlmodule: use PyArg_ParseTuple everywhere. Message-ID: <200008021313.GAA02726@delerium.i.sourceforge.net> Patch #101046 has been updated. Project: Category: Modules Status: Open Summary: fcntlmodule: use PyArg_ParseTuple everywhere. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101046&group_id=5470 From noreply@sourceforge.net Wed Aug 2 14:24:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 2 Aug 2000 06:24:23 -0700 Subject: [Patches] [Patch #101043] Description of what can go wrong in ioctl Message-ID: <200008021324.GAA04539@bush.i.sourceforge.net> Patch #101043 has been updated. Project: Category: documentation Status: Accepted Summary: Description of what can go wrong in ioctl ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101043&group_id=5470 From noreply@sourceforge.net Wed Aug 2 14:27:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 2 Aug 2000 06:27:17 -0700 Subject: [Patches] [Patch #101046] fcntlmodule: use PyArg_ParseTuple everywhere. Message-ID: <200008021327.GAA03191@delerium.i.sourceforge.net> Patch #101046 has been updated. Project: Category: Modules Status: Open Summary: fcntlmodule: use PyArg_ParseTuple everywhere. Follow-Ups: Date: 2000-Aug-02 06:27 By: gvanrossum Comment: The idea is fine, but you missed the fact that the code is trying to simulate "ii|i" by trying "(ii)" and then "(iii)". This should be collapsed too (in two places). If you fix this I'll accept it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101046&group_id=5470 From noreply@sourceforge.net Wed Aug 2 21:48:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 2 Aug 2000 13:48:06 -0700 Subject: [Patches] [Patch #101046] fcntlmodule: use PyArg_ParseTuple everywhere. Message-ID: <200008022048.NAA24420@bush.i.sourceforge.net> Patch #101046 has been updated. Project: Category: Modules Status: Accepted Summary: fcntlmodule: use PyArg_ParseTuple everywhere. Follow-Ups: Date: 2000-Aug-02 06:27 By: gvanrossum Comment: The idea is fine, but you missed the fact that the code is trying to simulate "ii|i" by trying "(ii)" and then "(iii)". This should be collapsed too (in two places). If you fix this I'll accept it. ------------------------------------------------------- Date: 2000-Aug-02 06:59 By: hooft Comment: I revised the patch. Still not too happy about all error messages: >>> fcntl.ioctl(1,2,fcntl) Traceback (most recent call last): File "", line 1, in ? TypeError: an integer is required But I don't know how to fix that. ------------------------------------------------------- Date: 2000-Aug-02 13:48 By: gvanrossum Comment: Done. That error messages comes from intobject.c, to fix it you would have to fix that file as well as PyArg_ParseTuple. Note: the module test.test_fcntl doesn't d a very thorough test -- it doesn't even test ioctl at all! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101046&group_id=5470 From noreply@sourceforge.net Wed Aug 2 22:07:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 2 Aug 2000 14:07:23 -0700 Subject: [Patches] [Patch #101043] Description of what can go wrong in ioctl Message-ID: <200008022107.OAA25674@bush.i.sourceforge.net> Patch #101043 has been updated. Project: Category: documentation Status: Closed Summary: Description of what can go wrong in ioctl Follow-Ups: Date: 2000-Aug-02 14:07 By: fdrake Comment: Accepted with minor editorial change to the last sentence. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101043&group_id=5470 From noreply@sourceforge.net Wed Aug 2 22:37:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 2 Aug 2000 14:37:41 -0700 Subject: [Patches] [Patch #101055] Cookie.py Message-ID: <200008022137.OAA20315@delerium.i.sourceforge.net> Patch #101055 has been updated. Project: Category: library Status: Open Summary: Cookie.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101055&group_id=5470 From noreply@sourceforge.net Thu Aug 3 11:08:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 03:08:37 -0700 Subject: [Patches] [Patch #101033] Use METH_VARARGS constant in Modules/ Message-ID: <200008031008.DAA10112@delerium.i.sourceforge.net> Patch #101033 has been updated. Project: Category: core (C code) Status: Open Summary: Use METH_VARARGS constant in Modules/ Follow-Ups: Date: 2000-Aug-03 03:08 By: marangoz Comment: So this replaces '1' with METH_VARARGS (good), but leaves the '0' in place (bad). What's the point, then? :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101033&group_id=5470 From noreply@sourceforge.net Thu Aug 3 12:56:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 04:56:56 -0700 Subject: [Patches] [Patch #101030] new zip() builtin Message-ID: <200008031156.EAA19956@bush.i.sourceforge.net> Patch #101030 has been updated. Project: Category: core (C code) Status: Accepted Summary: new zip() builtin Follow-Ups: Date: 2000-Jul-31 11:00 By: gvanrossum Comment: I won't even look at this until you've supplied a test_zip.py module. :-) Fred will probably like a doc patch, too... ------------------------------------------------------- Date: 2000-Jul-31 11:27 By: bwarsaw Comment: regr test and doc patches added ------------------------------------------------------- Date: 2000-Jul-31 11:38 By: gvanrossum Comment: Great! Note a minor bug in the test suite: exc=1 should only be set in the two except TypeError clauses, not in the mail try clauses! (After all you want it to raise an exception, so falling through the main clause is an *error*.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101030&group_id=5470 From noreply@sourceforge.net Thu Aug 3 13:40:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 05:40:57 -0700 Subject: [Patches] [Patch #101033] Use METH_VARARGS constant in Modules/ Message-ID: <200008031240.FAA21387@bush.i.sourceforge.net> Patch #101033 has been updated. Project: Category: core (C code) Status: Closed Summary: Use METH_VARARGS constant in Modules/ Follow-Ups: Date: 2000-Aug-03 03:08 By: marangoz Comment: So this replaces '1' with METH_VARARGS (good), but leaves the '0' in place (bad). What's the point, then? :-) ------------------------------------------------------- Date: 2000-Aug-03 05:40 By: akuchling Comment: A METH_OLDARGS constant was added, and Modules/ changed to use METH_OLDARGS instead of zero. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101033&group_id=5470 From noreply@sourceforge.net Thu Aug 3 14:54:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 06:54:06 -0700 Subject: [Patches] [Patch #101061] pyport.h and extern "C" Message-ID: <200008031354.GAA17002@delerium.i.sourceforge.net> Patch #101061 has been updated. Project: Category: core (C code) Status: Open Summary: pyport.h and extern "C" ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101061&group_id=5470 From Moshe Zadka Thu Aug 3 18:45:41 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 3 Aug 2000 20:45:41 +0300 (IDT) Subject: [Patches] Bug 110832 Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1841205112-965324741=:2575 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! My web-connection is acting up, so I'd appreciate it if anyone would submit the attached patch for me. The summary should be "Fixing bug 110832 -- urlparse.urljoin" Thanks in advance. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez ---559023410-1841205112-965324741=:2575 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=patch Content-ID: Content-Description: Content-Disposition: attachment; filename=patch Content-Transfer-Encoding: BASE64 SW5kZXg6IHVybHBhcnNlLnB5DQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS Q1MgZmlsZTogL2N2c3Jvb3QvcHl0aG9uL3B5dGhvbi9kaXN0L3NyYy9MaWIv dXJscGFyc2UucHksdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjI1DQpkaWZm IC1jIC1yMS4yNSB1cmxwYXJzZS5weQ0KKioqIHVybHBhcnNlLnB5CTIwMDAv MDYvMjAgMTg6MzI6MTYJMS4yNQ0KLS0tIHVybHBhcnNlLnB5CTIwMDAvMDgv MDMgMTc6Mzg6MDANCioqKioqKioqKioqKioqKg0KKioqIDE1NywxNzYgKioq Kg0KICAJCXNlZ21lbnRzWy0xXSA9ICcnDQogIAl3aGlsZSAnLicgaW4gc2Vn bWVudHM6DQogIAkJc2VnbWVudHMucmVtb3ZlKCcuJykNCiEgCXdoaWxlIDE6 DQohIAkJaSA9IDENCiEgCQluID0gbGVuKHNlZ21lbnRzKSAtIDENCiEgCQl3 aGlsZSBpIDwgbjoNCiEgCQkJaWYgc2VnbWVudHNbaV0gPT0gJy4uJyBhbmQg c2VnbWVudHNbaS0xXToNCiEgCQkJCWRlbCBzZWdtZW50c1tpLTE6aSsxXQ0K ISAJCQkJYnJlYWsNCiEgCQkJaSA9IGkrMQ0KISAJCWVsc2U6DQohIAkJCWJy ZWFrDQohIAlpZiBsZW4oc2VnbWVudHMpID09IDIgYW5kIHNlZ21lbnRzWzFd ID09ICcuLicgYW5kIHNlZ21lbnRzWzBdID09ICcnOg0KISAJCXNlZ21lbnRz Wy0xXSA9ICcnDQohIAllbGlmIGxlbihzZWdtZW50cykgPj0gMiBhbmQgc2Vn bWVudHNbLTFdID09ICcuLic6DQohIAkJc2VnbWVudHNbLTI6XSA9IFsnJ10N CiAgCXJldHVybiB1cmx1bnBhcnNlKChzY2hlbWUsIG5ldGxvYywgam9pbihz ZWdtZW50cywgJy8nKSwNCiAgCQkJICAgcGFyYW1zLCBxdWVyeSwgZnJhZ21l bnQpKQ0KICANCi0tLSAxNTcsMTcxIC0tLS0NCiAgCQlzZWdtZW50c1stMV0g PSAnJw0KICAJd2hpbGUgJy4nIGluIHNlZ21lbnRzOg0KICAJCXNlZ21lbnRz LnJlbW92ZSgnLicpDQohIAluZXdfc2VnbWVudHMgPSBbXQ0KISAJZm9yIHNl Z21lbnQgaW4gc2VnbWVudHNbMTpdOg0KISAJCWlmIHNlZ21lbnQgIT0gJy4u JzoNCiEgCQkJbmV3X3NlZ21lbnRzLmFwcGVuZChzZWdtZW50KQ0KISAJCWVs aWYgbmV3X3NlZ21lbnRzIGFuZCBuZXdfc2VnbWVudHNbLTFdICE9ICcuLic6 DQohIAkJCW5ld19zZWdtZW50cy5wb3AoKQ0KISAJCSNlbHNlOg0KISAJCQkj bmV3X3NlZ21lbnRzLmFwcGVuZChzZWdtZW50KQ0KISAJc2VnbWVudHMgPSBb c2VnbWVudHNbMF1dK25ld19zZWdtZW50cw0KICAJcmV0dXJuIHVybHVucGFy c2UoKHNjaGVtZSwgbmV0bG9jLCBqb2luKHNlZ21lbnRzLCAnLycpLA0KICAJ CQkgICBwYXJhbXMsIHF1ZXJ5LCBmcmFnbWVudCkpDQogIA0KKioqKioqKioq KioqKioqDQoqKiogMTk2LDIwOCAqKioqDQogICAgICAgIC4vZyAgICAgICAg PSA8VVJMOmh0dHA6Ly9hL2IvYy9nPg0KICAgICAgICBnLyAgICAgICAgID0g PFVSTDpodHRwOi8vYS9iL2MvZy8+DQogICAgICAgIC9nICAgICAgICAgPSA8 VVJMOmh0dHA6Ly9hL2c+DQohICAgICAgIC8vZyAgICAgICAgPSA8VVJMOmh0 dHA6Ly9nPg0KICAgICAgICA/eSAgICAgICAgID0gPFVSTDpodHRwOi8vYS9i L2MvZD95Pg0KICAgICAgICBnP3kgICAgICAgID0gPFVSTDpodHRwOi8vYS9i L2MvZz95Pg0KICAgICAgICBnP3kvLi94ICAgID0gPFVSTDpodHRwOi8vYS9i L2MvZz95Ly4veD4NCiAgICAgICAgLiAgICAgICAgICA9IDxVUkw6aHR0cDov L2EvYi9jLz4NCiAgICAgICAgLi8gICAgICAgICA9IDxVUkw6aHR0cDovL2Ev Yi9jLz4NCiEgICAgICAgLi4gICAgICAgICA9IDxVUkw6aHR0cDovL2EvYi8+ DQogICAgICAgIC4uLyAgICAgICAgPSA8VVJMOmh0dHA6Ly9hL2IvPg0KICAg ICAgICAuLi9nICAgICAgID0gPFVSTDpodHRwOi8vYS9iL2c+DQogICAgICAg IC4uLy4uICAgICAgPSA8VVJMOmh0dHA6Ly9hLz4NCi0tLSAxOTEsMjAzIC0t LS0NCiAgICAgICAgLi9nICAgICAgICA9IDxVUkw6aHR0cDovL2EvYi9jL2c+ DQogICAgICAgIGcvICAgICAgICAgPSA8VVJMOmh0dHA6Ly9hL2IvYy9nLz4N CiAgICAgICAgL2cgICAgICAgICA9IDxVUkw6aHR0cDovL2EvZz4NCiEgICAg ICAgLy9nICAgICAgICA9IDxVUkw6aHR0cDovL2cvPg0KICAgICAgICA/eSAg ICAgICAgID0gPFVSTDpodHRwOi8vYS9iL2MvZD95Pg0KICAgICAgICBnP3kg ICAgICAgID0gPFVSTDpodHRwOi8vYS9iL2MvZz95Pg0KICAgICAgICBnP3kv Li94ICAgID0gPFVSTDpodHRwOi8vYS9iL2MvZz95Ly4veD4NCiAgICAgICAg LiAgICAgICAgICA9IDxVUkw6aHR0cDovL2EvYi9jLz4NCiAgICAgICAgLi8g ICAgICAgICA9IDxVUkw6aHR0cDovL2EvYi9jLz4NCiEgICAgICAgLi4gICAg ICAgICA9IDxVUkw6aHR0cDovL2EvYj4NCiAgICAgICAgLi4vICAgICAgICA9 IDxVUkw6aHR0cDovL2EvYi8+DQogICAgICAgIC4uL2cgICAgICAgPSA8VVJM Omh0dHA6Ly9hL2IvZz4NCiAgICAgICAgLi4vLi4gICAgICA9IDxVUkw6aHR0 cDovL2EvPg0KSW5kZXg6IHRlc3QvdGVzdF91cmxwYXJzZS5weQ0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9jdnNyb290L3B5dGhvbi9w eXRob24vZGlzdC9zcmMvTGliL3Rlc3QvdGVzdF91cmxwYXJzZS5weSx2DQpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMQ0KZGlmZiAtYyAtcjEuMSB0ZXN0X3Vy bHBhcnNlLnB5DQoqKiogdGVzdC90ZXN0X3VybHBhcnNlLnB5CTIwMDAvMDgv MDMgMTc6Mjg6NTAJMS4xDQotLS0gdGVzdC90ZXN0X3VybHBhcnNlLnB5CTIw MDAvMDgvMDMgMTc6NDA6MjENCioqKioqKioqKioqKioqKg0KKioqIDAgKioq Kg0KLS0tIDEsNTAgLS0tLQ0KKyBpbXBvcnQgc3lzDQorIGltcG9ydCB0ZXN0 X3N1cHBvcnQNCisgaW1wb3J0IHVybHBhcnNlDQorIGltcG9ydCBzdHJpbmcN CisgDQorIGlmIHVybHBhcnNlLnVybGpvaW4oImh0dHA6Ly8xMjcuMC4wLjEv IiwgIi4uL3BhdGgiKSAhPSAiaHR0cDovLzEyNy4wLjAuMS9wYXRoIjoNCisg CXByaW50IHVybHBhcnNlLnVybGpvaW4oImh0dHA6Ly8xMjcuMC4wLjEvIiwg Ii4uL3BhdGgiKQ0KKyAJcmFpc2UgVmFsdWVFcnJvcigidXJscGFyc2UgZmFp bGVkIikNCisgDQorIGJhc2UgPSAiaHR0cDovL2EvYi9jL2QiDQorIA0KKyB0 ZXN0X2Nhc2VzID0gJycnXA0KKyAgICAgICBnOmggICAgICAgID0gPFVSTDpn Omg+DQorICAgICAgIGh0dHA6ZyAgICAgPSA8VVJMOmh0dHA6Ly9hL2IvYy9n Pg0KKyAgICAgICBodHRwOiAgICAgID0gPFVSTDpodHRwOi8vYS9iL2MvZD4N CisgICAgICAgZyAgICAgICAgICA9IDxVUkw6aHR0cDovL2EvYi9jL2c+DQor ICAgICAgIC4vZyAgICAgICAgPSA8VVJMOmh0dHA6Ly9hL2IvYy9nPg0KKyAg ICAgICBnLyAgICAgICAgID0gPFVSTDpodHRwOi8vYS9iL2MvZy8+DQorICAg ICAgIC9nICAgICAgICAgPSA8VVJMOmh0dHA6Ly9hL2c+DQorICAgICAgIC8v ZyAgICAgICAgPSA8VVJMOmh0dHA6Ly9nLz4NCisgICAgICAgP3kgICAgICAg ICA9IDxVUkw6aHR0cDovL2EvYi9jL2Q/eT4NCisgICAgICAgZz95ICAgICAg ICA9IDxVUkw6aHR0cDovL2EvYi9jL2c/eT4NCisgICAgICAgZz95Ly4veCAg ICA9IDxVUkw6aHR0cDovL2EvYi9jL2c/eS8uL3g+DQorICAgICAgIC4gICAg ICAgICAgPSA8VVJMOmh0dHA6Ly9hL2IvYy8+DQorICAgICAgIC4vICAgICAg ICAgPSA8VVJMOmh0dHA6Ly9hL2IvYy8+DQorICAgICAgIC4uICAgICAgICAg PSA8VVJMOmh0dHA6Ly9hL2I+DQorICAgICAgIC4uLyAgICAgICAgPSA8VVJM Omh0dHA6Ly9hL2IvPg0KKyAgICAgICAuLi9nICAgICAgID0gPFVSTDpodHRw Oi8vYS9iL2c+DQorICAgICAgIC4uLy4uICAgICAgPSA8VVJMOmh0dHA6Ly9h Lz4NCisgICAgICAgLi4vLi4vZyAgICA9IDxVUkw6aHR0cDovL2EvZz4NCisg ICAgICAgLi4vLi4vLi4vZyA9IDxVUkw6aHR0cDovL2EvZz4NCisgICAgICAg Li8uLi9nICAgICA9IDxVUkw6aHR0cDovL2EvYi9nPg0KKyAgICAgICAuL2cv LiAgICAgID0gPFVSTDpodHRwOi8vYS9iL2MvZy8+DQorICAgICAgIC8uL2cg ICAgICAgPSA8VVJMOmh0dHA6Ly9hLy4vZz4NCisgICAgICAgZy8uL2ggICAg ICA9IDxVUkw6aHR0cDovL2EvYi9jL2cvaD4NCisgICAgICAgZy8uLi9oICAg ICA9IDxVUkw6aHR0cDovL2EvYi9jL2g+DQorICAgICAgIGh0dHA6ZyAgICAg PSA8VVJMOmh0dHA6Ly9hL2IvYy9nPg0KKyAgICAgICBodHRwOiAgICAgID0g PFVSTDpodHRwOi8vYS9iL2MvZD4NCisgICAgICAgaHR0cDo/eSAgICAgICAg ID0gPFVSTDpodHRwOi8vYS9iL2MvZD95Pg0KKyAgICAgICBodHRwOmc/eSAg ICAgICAgPSA8VVJMOmh0dHA6Ly9hL2IvYy9nP3k+DQorICAgICAgIGh0dHA6 Zz95Ly4veCAgICA9IDxVUkw6aHR0cDovL2EvYi9jL2c/eS8uL3g+JycnDQor IA0KKyB0ZXN0X2Nhc2VzID0gc3RyaW5nLnNwbGl0KHRlc3RfY2FzZXMsICdc bicpDQorIGZvciBsaW5lIGluIHRlc3RfY2FzZXM6DQorIAlzb3VyY2UsIHRh cmdldCA9IG1hcChzdHJpbmcuc3RyaXAsIHN0cmluZy5zcGxpdChsaW5lLCAn PScpKQ0KKyAJcmVzdWx0ID0gJzxVUkw6JXM+JyAlIHVybHBhcnNlLnVybGpv aW4oYmFzZSwgc291cmNlKQ0KKyAJaWYgcmVzdWx0ICE9IHRhcmdldDoNCisg CQltZXNzYWdlID0gInVybGpvaW4oJShiYXNlKXMsICUoc291cmNlKXMpICJc DQorIAkJICAgICAgICAgICI9PSAlKHJlc3VsdClzICE9ICUodGFyZ2V0KXMi ICUgdmFycygpDQorIAkJcmFpc2UgVmFsdWVFcnJvcihtZXNzYWdlKQ0K ---559023410-1841205112-965324741=:2575-- From noreply@sourceforge.net Thu Aug 3 19:29:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 11:29:50 -0700 Subject: [Patches] [Patch #101062] Docs for the new parser markers introduced by Unicode Message-ID: <200008031829.LAA00514@bush.i.sourceforge.net> Patch #101062 has been updated. Project: Category: documentation Status: Open Summary: Docs for the new parser markers introduced by Unicode ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101062&group_id=5470 From noreply@sourceforge.net Thu Aug 3 19:34:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 11:34:38 -0700 Subject: [Patches] [Patch #101063] TeX-draft for docs of the new string methods Message-ID: <200008031834.LAA00693@bush.i.sourceforge.net> Patch #101063 has been updated. Project: Category: documentation Status: Open Summary: TeX-draft for docs of the new string methods ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101063&group_id=5470 From noreply@sourceforge.net Thu Aug 3 19:50:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 11:50:50 -0700 Subject: [Patches] [Patch #101063] TeX-draft for docs of the new string methods Message-ID: <200008031850.LAA01395@bush.i.sourceforge.net> Patch #101063 has been updated. Project: Category: documentation Status: Open Summary: TeX-draft for docs of the new string methods ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101063&group_id=5470 From noreply@sourceforge.net Thu Aug 3 19:50:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 11:50:52 -0700 Subject: [Patches] [Patch #101062] Docs for the new parser markers introduced by Unicode Message-ID: <200008031850.LAA01396@bush.i.sourceforge.net> Patch #101062 has been updated. Project: Category: documentation Status: Open Summary: Docs for the new parser markers introduced by Unicode ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101062&group_id=5470 From noreply@sourceforge.net Thu Aug 3 19:59:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 11:59:57 -0700 Subject: [Patches] [Patch #100899] a smaller unicode name database Message-ID: <200008031859.LAA27492@delerium.i.sourceforge.net> Patch #100899 has been updated. Project: Category: None Status: Open Summary: a smaller unicode name database Follow-Ups: Date: 2000-Jul-15 15:43 By: effbot Comment: duh. it's too large for sourceforge. if you want to play with it, get it from: http://w1.132.telia.com/~u13208596/uninames-patch.txt ------------------------------------------------------- Date: 2000-Aug-03 11:59 By: lemburg Comment: How is the work on this patch coming along ? Will it be ready for 2.0 ? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100899&group_id=5470 From noreply@sourceforge.net Thu Aug 3 20:03:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 12:03:33 -0700 Subject: [Patches] [Patch #101064] [Moshe] Fixing bug 110832 -- urlparse.urljoin Message-ID: <200008031903.MAA01764@bush.i.sourceforge.net> Patch #101064 has been updated. Project: Category: Modules Status: Open Summary: [Moshe] Fixing bug 110832 -- urlparse.urljoin ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101064&group_id=5470 From thomas@xs4all.net Thu Aug 3 20:05:21 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 3 Aug 2000 21:05:21 +0200 Subject: [Patches] Bug 110832 In-Reply-To: ; from moshez@math.huji.ac.il on Thu, Aug 03, 2000 at 08:45:41PM +0300 References: Message-ID: <20000803210521.E266@xs4all.nl> On Thu, Aug 03, 2000 at 08:45:41PM +0300, Moshe Zadka wrote: > My web-connection is acting up, so I'd appreciate it if anyone would > submit the attached patch for me. > The summary should be "Fixing bug 110832 -- urlparse.urljoin" Done, SF patch #101064. You should probably add some comment explaining the patch when you get the chance. (Btw, my web connection to SF was acting up as well, but seems better now. Maybe yours is too.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Thu Aug 3 20:06:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 12:06:46 -0700 Subject: [Patches] [Patch #101064] [Moshe] Fixing bug 110832 -- urlparse.urljoin Message-ID: <200008031906.MAA01908@bush.i.sourceforge.net> Patch #101064 has been updated. Project: Category: Modules Status: Open Summary: [Moshe] Fixing bug 110832 -- urlparse.urljoin Follow-Ups: Date: 2000-Aug-03 12:06 By: twouters Comment: Moshe's patch to fix bug #110832. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101064&group_id=5470 From noreply@sourceforge.net Thu Aug 3 20:15:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 12:15:27 -0700 Subject: [Patches] [Patch #101065] bogus counter for recursive PyObject_Compare() Message-ID: <200008031915.MAA28031@delerium.i.sourceforge.net> Patch #101065 has been updated. Project: Category: core (C code) Status: Open Summary: bogus counter for recursive PyObject_Compare() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101065&group_id=5470 From noreply@sourceforge.net Thu Aug 3 20:17:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 12:17:53 -0700 Subject: [Patches] [Patch #101065] bogus counter for recursive PyObject_Compare() Message-ID: <200008031917.MAA02269@bush.i.sourceforge.net> Patch #101065 has been updated. Project: Category: core (C code) Status: Open Summary: bogus counter for recursive PyObject_Compare() Follow-Ups: Date: 2000-Aug-03 12:17 By: marangoz Comment: Looks like _PyCompareState_nesting is not updated accordingly on err conditions. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101065&group_id=5470 From noreply@sourceforge.net Thu Aug 3 20:21:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 12:21:49 -0700 Subject: [Patches] [Patch #101062] Docs for the new parser markers introduced by Unicode Message-ID: <200008031921.MAA28316@delerium.i.sourceforge.net> Patch #101062 has been updated. Project: Category: documentation Status: Accepted Summary: Docs for the new parser markers introduced by Unicode Follow-Ups: Date: 2000-Aug-03 12:21 By: fdrake Comment: Check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101062&group_id=5470 From noreply@sourceforge.net Thu Aug 3 20:22:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 12:22:05 -0700 Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental) Message-ID: <200008031922.MAA28331@delerium.i.sourceforge.net> Patch #101022 has been updated. Project: Category: core (C code) Status: Postponed Summary: Removal of SET_LINENO (experimental) Follow-Ups: Date: 2000-Jul-30 16:12 By: marangoz Comment: For testing, as discussed on python-dev. For a gentle summary, see: http://www.python.org/pipermail/python-dev/2000-July/014364.html ------------------------------------------------------- Date: 2000-Jul-30 18:16 By: marangoz Comment: A nit: inline the argfetch in CALL_TRACE and goto the switch, instead of jumping to get_oparg which splits the sequence [fetch opcode, fetch oparg] -- this can slow things down. ------------------------------------------------------- Date: 2000-Jul-31 06:40 By: gvanrossum Comment: Status set to postponed to indicate that this is still experimental. ------------------------------------------------------- Date: 2000-Jul-31 07:57 By: marangoz Comment: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ------------------------------------------------------- Date: 2000-Jul-31 10:50 By: marangoz Comment: A last tiny fix of the SET_LINENO opcode for better b/w compatibility. Stopping here and entering standby mode for reactions & feedback. PS: the last idea about not duplicating co_code and tweaking the original with CALL_TRACE is a bad one. I remember Guido being against it because co_code could be used elsewhere (copied, written to disk, whatever) and he's right! Better operate on an internal copy created in ceval. ------------------------------------------------------- Date: 2000-Aug-03 12:22 By: marangoz Comment: Fix missing DECREF on error condition in start_tracing() + some renaming. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470 From noreply@sourceforge.net Thu Aug 3 20:32:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 12:32:38 -0700 Subject: [Patches] [Patch #101062] Docs for the new parser markers introduced by Unicode Message-ID: <200008031932.MAA02812@bush.i.sourceforge.net> Patch #101062 has been updated. Project: Category: documentation Status: Closed Summary: Docs for the new parser markers introduced by Unicode Follow-Ups: Date: 2000-Aug-03 12:21 By: fdrake Comment: Check it in! ------------------------------------------------------- Date: 2000-Aug-03 12:32 By: lemburg Comment: Ok. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101062&group_id=5470 From noreply@sourceforge.net Fri Aug 4 09:23:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 4 Aug 2000 01:23:14 -0700 Subject: [Patches] [Patch #101071] whichdb.py: add missing "try:" statement Message-ID: <200008040823.BAA19784@delerium.i.sourceforge.net> Patch #101071 has been updated. Project: Category: library Status: Open Summary: whichdb.py: add missing "try:" statement ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101071&group_id=5470 From noreply@sourceforge.net Fri Aug 4 09:47:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 4 Aug 2000 01:47:26 -0700 Subject: [Patches] [Patch #101071] whichdb.py: add missing "try:" statement Message-ID: <200008040847.BAA27108@bush.i.sourceforge.net> Patch #101071 has been updated. Project: Category: library Status: Closed Summary: whichdb.py: add missing "try:" statement Follow-Ups: Date: 2000-Aug-04 01:47 By: twouters Comment: Nice catch ! Commited, thanx. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101071&group_id=5470 From noreply@sourceforge.net Sun Aug 6 13:33:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 05:33:18 -0700 Subject: [Patches] [Patch #100699] Augmented Assignment, the Python Way (huge) Message-ID: <200008061233.FAA24300@bush.i.sourceforge.net> Patch #100699 has been updated. Project: Category: core (C code) Status: Open Summary: Augmented Assignment, the Python Way (huge) Follow-Ups: Date: 2000-Jun-30 17:49 By: twouters Comment: This patch adds augmented assignment (+=, **=, etc) to Python, in a manner which seems consistent with Guido and Tim's wishes (for as far as I know them.) Guido has already stated this patch will not make it to Python 2.0, so the first to read this should probably set the state to 'postponed'. I'll try and keep this patch up to date none the less, for peer (or rather parent ;) reviewal. The patch adds everything in one smack: Syntax, a new type of bytecode (2-argument), 9 new bytecodes, 13 new API calls, 11 new PyNumber_Methods members, 2 new PySequence_Methods members, and support for the new functionality in builtin types and supplied Python classes. Oh, and a test suite. None the less, it isn't that intrusive a patch, and the simplicity of the implementation still boggles me. For more information, see http://www.xs4all.nl/~thomas/python/ Comments greatly appreciated! Contact me on thomas@xs4all.net (I'm not on python-dev) ------------------------------------------------------- Date: 2000-Jun-30 18:10 By: gvanrossum Comment: Cool! We'll look at this after 2.0 is released... ------------------------------------------------------- Date: 2000-Jul-13 13:53 By: jhylton Comment: This patch needs to be postponed until the PEP is written. ------------------------------------------------------- Date: 2000-Jul-25 06:37 By: gvanrossum Comment: Not ready to be checked in, but Thomas is working on it! This will be in 2.0 after all... ------------------------------------------------------- Date: 2000-Aug-06 05:33 By: twouters Comment: New version of the patch, that eliminates the need for 2-argument opcodes and the GETSET_* opcodes. Instead, INPLACE_* opcodes are used, that mirror the BINARY_* opcodes, and two new 'utility' opcodes: ROT_FOUR and DUP_TOPX (duplicates the top items on the stack.) The PEP documenting this implementation will follow soon. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100699&group_id=5470 From noreply@sourceforge.net Sun Aug 6 16:33:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 08:33:53 -0700 Subject: [Patches] [Patch #101096] enable/disable interface for GC module Message-ID: <200008061533.IAA22288@delerium.i.sourceforge.net> Patch #101096 has been updated. Project: Category: core (C code) Status: Open Summary: enable/disable interface for GC module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101096&group_id=5470 From noreply@sourceforge.net Sun Aug 6 16:55:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 08:55:31 -0700 Subject: [Patches] [Patch #101096] enable/disable interface for GC module Message-ID: <200008061555.IAA22865@delerium.i.sourceforge.net> Patch #101096 has been updated. Project: Category: core (C code) Status: Open Summary: enable/disable interface for GC module Follow-Ups: Date: 2000-Aug-06 08:39 By: nascheme Comment: Update module documentation. ------------------------------------------------------- Date: 2000-Aug-06 08:49 By: none Comment: Unless someone has objections, in which case -- speak fast, I'll check this in. I am definitely +1. The point is that the GC thresholds are intended to tune the collector, while people are usually more interested in whether it is on or off. Maybe an additional "is_enabled()" function would be nice too... ------------------------------------------------------- Date: 2000-Aug-06 08:55 By: marangoz Comment: PS: oops, that comment was from me :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101096&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:48:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:48:35 -0700 Subject: [Patches] [Patch #101061] pyport.h and extern "C" Message-ID: <200008062048.NAA07102@bush.i.sourceforge.net> Patch #101061 has been updated. Project: Category: core (C code) Status: Open Summary: pyport.h and extern "C" Follow-Ups: Date: 2000-Aug-03 06:56 By: htrd Comment: An existing comment in this file says... some C++ #include's don't like to be included inside an extern "C" ....however numerous standard #includes were inside that extern "C". This patch just reorders a few things, so all the #includes are at the top, outside the extern "C". ------------------------------------------------------- Date: 2000-Aug-06 13:48 By: marangoz Comment: What exactly breaks with the current setup that is solved by this patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101061&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:54:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:54:14 -0700 Subject: [Patches] [Patch #101096] enable/disable interface for GC module Message-ID: <200008062054.NAA07274@bush.i.sourceforge.net> Patch #101096 has been updated. Project: Category: core (C code) Status: Accepted Summary: enable/disable interface for GC module Follow-Ups: Date: 2000-Aug-06 08:39 By: nascheme Comment: Update module documentation. ------------------------------------------------------- Date: 2000-Aug-06 08:49 By: none Comment: Unless someone has objections, in which case -- speak fast, I'll check this in. I am definitely +1. The point is that the GC thresholds are intended to tune the collector, while people are usually more interested in whether it is on or off. Maybe an additional "is_enabled()" function would be nice too... ------------------------------------------------------- Date: 2000-Aug-06 08:55 By: marangoz Comment: PS: oops, that comment was from me :-) ------------------------------------------------------- Date: 2000-Aug-06 11:20 By: nascheme Comment: - Add is_enabled() function. - test_gc now uses the three new functions ------------------------------------------------------- Date: 2000-Aug-06 13:54 By: marangoz Comment: Status: Accepted. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101096&group_id=5470 From noreply@sourceforge.net Sun Aug 6 23:53:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 15:53:43 -0700 Subject: [Patches] [Patch #101096] enable/disable interface for GC module Message-ID: <200008062253.PAA11169@bush.i.sourceforge.net> Patch #101096 has been updated. Project: Category: core (C code) Status: Closed Summary: enable/disable interface for GC module Follow-Ups: Date: 2000-Aug-06 08:39 By: nascheme Comment: Update module documentation. ------------------------------------------------------- Date: 2000-Aug-06 08:49 By: none Comment: Unless someone has objections, in which case -- speak fast, I'll check this in. I am definitely +1. The point is that the GC thresholds are intended to tune the collector, while people are usually more interested in whether it is on or off. Maybe an additional "is_enabled()" function would be nice too... ------------------------------------------------------- Date: 2000-Aug-06 08:55 By: marangoz Comment: PS: oops, that comment was from me :-) ------------------------------------------------------- Date: 2000-Aug-06 11:20 By: nascheme Comment: - Add is_enabled() function. - test_gc now uses the three new functions ------------------------------------------------------- Date: 2000-Aug-06 13:54 By: marangoz Comment: Status: Accepted. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101096&group_id=5470 From noreply@sourceforge.net Mon Aug 7 02:43:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 18:43:13 -0700 Subject: [Patches] [Patch #101102] dict.setdefault() Message-ID: <200008070143.SAA16282@bush.i.sourceforge.net> Patch #101102 has been updated. Project: Category: core (C code) Status: Open Summary: dict.setdefault() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101102&group_id=5470 From noreply@sourceforge.net Mon Aug 7 02:45:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 18:45:04 -0700 Subject: [Patches] [Patch #101102] dict.setdefault() Message-ID: <200008070145.SAA16391@bush.i.sourceforge.net> Patch #101102 has been updated. Project: Category: core (C code) Status: Open Summary: dict.setdefault() Follow-Ups: Date: 2000-Aug-06 18:45 By: bwarsaw Comment: dict.setdefault() is like dict.get() except that if the key is missing, the fail object is both returned and inserted into the dictionary as the value of the key. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101102&group_id=5470 From noreply@sourceforge.net Mon Aug 7 03:07:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 19:07:11 -0700 Subject: [Patches] [Patch #101103] smtplib.py doesn't calculate fqdn correctly Message-ID: <200008070207.TAA17045@bush.i.sourceforge.net> Patch #101103 has been updated. Project: Category: library Status: Open Summary: smtplib.py doesn't calculate fqdn correctly ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101103&group_id=5470 From noreply@sourceforge.net Mon Aug 7 03:08:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 19:08:50 -0700 Subject: [Patches] [Patch #101103] smtplib.py doesn't calculate fqdn correctly Message-ID: <200008070208.TAA17069@bush.i.sourceforge.net> Patch #101103 has been updated. Project: Category: library Status: Open Summary: smtplib.py doesn't calculate fqdn correctly Follow-Ups: Date: 2000-Aug-06 19:08 By: bwarsaw Comment: A bug report submitted to the Mailman project[1], describes the situation where smtplib.py may choose a non-FQDN hostname for HELO/EHLO. Here is a patch to use the algorithm described in the socket module documentation. [1] http://sourceforge.net/bugs/?func=detailbug&bug_id=110935&group_id=103 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101103&group_id=5470 From noreply@sourceforge.net Mon Aug 7 04:53:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 20:53:39 -0700 Subject: [Patches] [Patch #101104] Optional object mem allocator Message-ID: <200008070353.UAA20232@bush.i.sourceforge.net> Patch #101104 has been updated. Project: Category: core (C code) Status: Open Summary: Optional object mem allocator ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101104&group_id=5470 From noreply@sourceforge.net Mon Aug 7 05:05:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 21:05:23 -0700 Subject: [Patches] [Patch #101104] Optional object mem allocator Message-ID: <200008070405.VAA20631@bush.i.sourceforge.net> Patch #101104 has been updated. Project: Category: core (C code) Status: Open Summary: Optional object mem allocator Follow-Ups: Date: 2000-Aug-06 21:05 By: marangoz Comment: A stab on obmalloc.c -- an optional object allocator. A configure "--with(out)-pymalloc" option is introduced for enabling specialized mallocs. Off by default. The code is included conditionally at the end of object.c obmalloc.c contains only the core malloc functionality. No profiling, nor debugging are there -- these would come as separate (and optional) modules: memprof.c & memdebug.c in the Modules/ directory and will exploit the hooks of the allocator. I've managed to draw a rather nice diagram in the comments at the top of obmalloc.c explaining what this stuff is all about. Look there. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101104&group_id=5470 From noreply@sourceforge.net Mon Aug 7 13:58:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 05:58:51 -0700 Subject: [Patches] [Patch #100851] traceback.py, with unicode exceptions Message-ID: <200008071258.FAA05212@bush.i.sourceforge.net> Patch #100851 has been updated. Project: Category: None Status: Accepted Summary: traceback.py, with unicode exceptions Follow-Ups: Date: 2000-Jul-11 03:58 By: htrd Comment: traceback.py can format an exception as a string - but what happens when an exception is raised during the string conversion? In this case it is better to discard the inner exception, to allow the original exception to be reported. The migration to unicode strings makes this quite common. Old code might report a failue with something like.... raise IWasntExpectingThisError('nobody expects %s' % x) An alternative fix is to change __str__ for exceptions to handle the exception. This would be neater, but I chose to follow the example set by PyErr_PrintEx which has a comment: /* If an error happened here, don't show it. XXX This is wrong, but too many callers rely on this behavior. */ ------------------------------------------------------- Date: 2000-Jul-27 13:25 By: gvanrossum Comment: Actually I like this, but instead of the id() of the value you should show its type, e.g. "" % type(value). ------------------------------------------------------- Date: 2000-Aug-01 09:18 By: htrd Comment: Updated patch now formats tracebacks using type(value).__name__ Traceback (most recent call last): File "", line 1, in ? ValueError: ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100851&group_id=5470 From noreply@sourceforge.net Mon Aug 7 14:30:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 06:30:18 -0700 Subject: [Patches] [Patch #101104] Optional object mem allocator Message-ID: <200008071330.GAA06239@bush.i.sourceforge.net> Patch #101104 has been updated. Project: Category: core (C code) Status: Open Summary: Optional object mem allocator Follow-Ups: Date: 2000-Aug-06 21:05 By: marangoz Comment: A stab on obmalloc.c -- an optional object allocator. A configure "--with(out)-pymalloc" option is introduced for enabling specialized mallocs. Off by default. The code is included conditionally at the end of object.c obmalloc.c contains only the core malloc functionality. No profiling, nor debugging are there -- these would come as separate (and optional) modules: memprof.c & memdebug.c in the Modules/ directory and will exploit the hooks of the allocator. I've managed to draw a rather nice diagram in the comments at the top of obmalloc.c explaining what this stuff is all about. Look there. ------------------------------------------------------- Date: 2000-Aug-07 06:30 By: twouters Comment: Small nit: you shouldn't edit config.h.in yourself, it's autogenerated from acconfig.h and configure.in (with 'autoheader', part of 'autoconf.) You should define WITH_PYMALLOC in acconfig.h, not config.h.in, and run 'autoheader' and 'autoconf' to generate a new 'configure'. I'm in the process of testing this patch on Linux and BSDI, by the way :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101104&group_id=5470 From noreply@sourceforge.net Mon Aug 7 16:57:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 08:57:47 -0700 Subject: [Patches] [Patch #101106] getopt.py extensions (REJECT version) Message-ID: <200008071557.IAA11467@bush.i.sourceforge.net> Patch #101106 has been updated. Project: Category: library Status: Open Summary: getopt.py extensions (REJECT version) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101106&group_id=5470 From noreply@sourceforge.net Mon Aug 7 16:59:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 08:59:59 -0700 Subject: [Patches] [Patch #101107] libgetopt.py extensions (REJECT version) Message-ID: <200008071559.IAA11606@bush.i.sourceforge.net> Patch #101107 has been updated. Project: Category: documentation Status: Open Summary: libgetopt.py extensions (REJECT version) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101107&group_id=5470 From noreply@sourceforge.net Mon Aug 7 17:01:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 09:01:55 -0700 Subject: [Patches] [Patch #101108] getopt.py extensions (APPEND version) Message-ID: <200008071601.JAA11645@bush.i.sourceforge.net> Patch #101108 has been updated. Project: Category: None Status: Open Summary: getopt.py extensions (APPEND version) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101108&group_id=5470 From noreply@sourceforge.net Mon Aug 7 17:03:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 09:03:16 -0700 Subject: [Patches] [Patch #101109] libgetopt.tex extensions (APPEND version) Message-ID: <200008071603.JAA11765@bush.i.sourceforge.net> Patch #101109 has been updated. Project: Category: documentation Status: Open Summary: libgetopt.tex extensions (APPEND version) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101109&group_id=5470 From noreply@sourceforge.net Mon Aug 7 17:05:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 09:05:10 -0700 Subject: [Patches] [Patch #101110] test_getopt.py: new test module Message-ID: <200008071605.JAA11793@bush.i.sourceforge.net> Patch #101110 has been updated. Project: Category: library Status: Open Summary: test_getopt.py: new test module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101110&group_id=5470 From noreply@sourceforge.net Mon Aug 7 17:19:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 09:19:41 -0700 Subject: [Patches] [Patch #101104] Optional object mem allocator Message-ID: <200008071619.JAA04032@delerium.i.sourceforge.net> Patch #101104 has been updated. Project: Category: core (C code) Status: Open Summary: Optional object mem allocator Follow-Ups: Date: 2000-Aug-06 21:05 By: marangoz Comment: A stab on obmalloc.c -- an optional object allocator. A configure "--with(out)-pymalloc" option is introduced for enabling specialized mallocs. Off by default. The code is included conditionally at the end of object.c obmalloc.c contains only the core malloc functionality. No profiling, nor debugging are there -- these would come as separate (and optional) modules: memprof.c & memdebug.c in the Modules/ directory and will exploit the hooks of the allocator. I've managed to draw a rather nice diagram in the comments at the top of obmalloc.c explaining what this stuff is all about. Look there. ------------------------------------------------------- Date: 2000-Aug-07 06:30 By: twouters Comment: Small nit: you shouldn't edit config.h.in yourself, it's autogenerated from acconfig.h and configure.in (with 'autoheader', part of 'autoconf.) You should define WITH_PYMALLOC in acconfig.h, not config.h.in, and run 'autoheader' and 'autoconf' to generate a new 'configure'. I'm in the process of testing this patch on Linux and BSDI, by the way :) ------------------------------------------------------- Date: 2000-Aug-07 09:19 By: marangoz Comment: Thanks. Fixed (acconfig.h) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101104&group_id=5470 From noreply@sourceforge.net Tue Aug 8 12:35:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 04:35:21 -0700 Subject: [Patches] [Patch #101010] replace use of INT_PTR with uintptr_t (fix MSVC 5.0 build) Message-ID: <200008081135.EAA16732@bush.i.sourceforge.net> Patch #101010 has been updated. Project: Category: core (C code) Status: Closed Summary: replace use of INT_PTR with uintptr_t (fix MSVC 5.0 build) Follow-Ups: Date: 2000-Jul-28 12:58 By: tmick Comment: This replaces a stopgap fix for MSVC 5.0 building of thread_nt.h by Fredrik. See the thread on python-dev: http://www.python.org/pipermail/python-dev/2000-June/011766.html Fredrik, could you see if this patch works for you (compiling with MSVC 5.0) and then assign it back to me? Thanks ------------------------------------------------------- Date: 2000-Aug-08 04:35 By: effbot Comment: Worked just fine. I went ahead and checked it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101010&group_id=5470 From noreply@sourceforge.net Tue Aug 8 12:38:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 04:38:35 -0700 Subject: [Patches] [Patch #100990] disable partial UTF-16 support in unicodeobject.c Message-ID: <200008081138.EAA16861@bush.i.sourceforge.net> Patch #100990 has been updated. Project: Category: core (C code) Status: Out of date Summary: disable partial UTF-16 support in unicodeobject.c Follow-Ups: Date: 2000-Aug-08 04:38 By: effbot Comment: Recent checkins by MAL cover the comparision part of this patch, but not the codec changes. Feel free to salvage those parts, or reject/delete the entire patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100990&group_id=5470 From noreply@sourceforge.net Tue Aug 8 13:06:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 05:06:02 -0700 Subject: [Patches] [Patch #100990] disable partial UTF-16 support in unicodeobject.c Message-ID: <200008081206.FAA10120@delerium.i.sourceforge.net> Patch #100990 has been updated. Project: Category: core (C code) Status: Closed Summary: disable partial UTF-16 support in unicodeobject.c Follow-Ups: Date: 2000-Aug-08 04:38 By: effbot Comment: Recent checkins by MAL cover the comparision part of this patch, but not the codec changes. Feel free to salvage those parts, or reject/delete the entire patch. ------------------------------------------------------- Date: 2000-Aug-08 05:06 By: lemburg Comment: I'd rather leave the UTF-8 support for surrogates in there. It doesn't do any harm and complies with the other possibilities of adding surrogate pairs to the Unicode object contents, e.g. directly via u"". I'll also remove the error handling in the UTF-16 codec to accomodate for the above strategy. PS: I've closed the patch... hope that's the correct status. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100990&group_id=5470 From noreply@sourceforge.net Tue Aug 8 17:12:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 09:12:14 -0700 Subject: [Patches] [Patch #101102] dict.setdefault() Message-ID: <200008081612.JAA26407@bush.i.sourceforge.net> Patch #101102 has been updated. Project: Category: core (C code) Status: Closed Summary: dict.setdefault() Follow-Ups: Date: 2000-Aug-06 18:45 By: bwarsaw Comment: dict.setdefault() is like dict.get() except that if the key is missing, the fail object is both returned and inserted into the dictionary as the value of the key. ------------------------------------------------------- Date: 2000-Aug-08 09:12 By: gvanrossum Comment: Accepted and checked in. (The patch here has one bug: the function name for the error message is "get" instead of "setdefault". Fixed in the checked-in version.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101102&group_id=5470 From noreply@sourceforge.net Tue Aug 8 18:19:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 10:19:46 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008081719.KAA21340@delerium.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Open Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 05:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 18:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 02:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 16:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 07:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-27 22:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 14:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Tue Aug 8 18:19:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 10:19:10 -0700 Subject: [Patches] [Patch #100895] safe version of PyErr_Format Message-ID: <200008081719.KAA21323@delerium.i.sourceforge.net> Patch #100895 has been updated. Project: Category: core (C code) Status: Open Summary: safe version of PyErr_Format Follow-Ups: Date: 2000-Jul-17 14:56 By: effbot Comment: minor tweaks (mostly comments), based on input from moshe. ------------------------------------------------------- Date: 2000-Jul-17 23:23 By: moshez Comment: I'm +1 on that! It will plug one more security hole in Python, and seems a "good enough" replacement for an unsure snprintf() ------------------------------------------------------- Date: 2000-Aug-08 10:19 By: effbot Comment: regenerated, since moshez reported that it didn't apply cleanly to the current CVS tree. reassigned, since it's been sitting here for ages. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From noreply@sourceforge.net Tue Aug 8 21:25:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 13:25:18 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008082025.NAB02972@bush.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Tue Aug 8 21:36:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 13:36:30 -0700 Subject: [Patches] [Patch #101121] cosmetic cleanup of cgi.py, using Guido's style conventions Message-ID: <200008082036.NAA03420@bush.i.sourceforge.net> Patch #101121 has been updated. Project: Category: library Status: Open Summary: cosmetic cleanup of cgi.py, using Guido's style conventions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101121&group_id=5470 From noreply@sourceforge.net Wed Aug 9 05:14:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 21:14:15 -0700 Subject: [Patches] [Patch #101126] mimify.py: mods for new getopt, & tab->spaces Message-ID: <200008090414.VAA19401@bush.i.sourceforge.net> Patch #101126 has been updated. Project: Category: library Status: Open Summary: mimify.py: mods for new getopt, & tab->spaces ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101126&group_id=5470 From noreply@sourceforge.net Wed Aug 9 05:21:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 21:21:59 -0700 Subject: [Patches] [Patch #101127] lib-old/dircmp.py mods for new getopt.py Message-ID: <200008090421.VAA19772@bush.i.sourceforge.net> Patch #101127 has been updated. Project: Category: library Status: Open Summary: lib-old/dircmp.py mods for new getopt.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101127&group_id=5470 From noreply@sourceforge.net Wed Aug 9 06:26:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 22:26:15 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008090526.WAA22248@bush.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Rejected Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 05:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 18:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 02:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 16:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 07:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-27 22:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 14:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- Date: 2000-Aug-08 22:26 By: tim_one Comment: Changed status to Rejected, but left assigned to me (I'll Open it again when it's updated). As I said at the bottom of my last comment on this, you cannot assume sizeof(short)==2: please get rid of the new big-endian/little-endian trickery. The code is not portable as-is. Even on machines where sizeof(short) does equal 2, shorts in the opcode stream are not guaranteed to be naturally aligned, and trying to access them as if they were can lead to anything from a core dump to an expensive trap to the OS to fix up the unaligned read. And on the only machines where this gimmick could actually pay (a little-endian machine where sizeof(short)==2 *and* the HW doesn't penalize unnatural alignment), the compiler should be smart enough to optimize the old expression for us. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Wed Aug 9 10:59:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 02:59:44 -0700 Subject: [Patches] [Patch #101129] add indices() and irange() to built-ins Message-ID: <200008090959.CAA00338@bush.i.sourceforge.net> Patch #101129 has been updated. Project: Category: core (C code) Status: Open Summary: add indices() and irange() to built-ins ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101129&group_id=5470 From noreply@sourceforge.net Wed Aug 9 12:36:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 04:36:09 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008091136.EAA04319@bush.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Rejected Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 05:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 18:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 02:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 16:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 07:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-27 22:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 14:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- Date: 2000-Aug-08 22:26 By: tim_one Comment: Changed status to Rejected, but left assigned to me (I'll Open it again when it's updated). As I said at the bottom of my last comment on this, you cannot assume sizeof(short)==2: please get rid of the new big-endian/little-endian trickery. The code is not portable as-is. Even on machines where sizeof(short) does equal 2, shorts in the opcode stream are not guaranteed to be naturally aligned, and trying to access them as if they were can lead to anything from a core dump to an expensive trap to the OS to fix up the unaligned read. And on the only machines where this gimmick could actually pay (a little-endian machine where sizeof(short)==2 *and* the HW doesn't penalize unnatural alignment), the compiler should be smart enough to optimize the old expression for us. ------------------------------------------------------- Date: 2000-Aug-09 04:36 By: gvanrossum Comment: I think that all Tim wants is that you undo the changes you made to the NEXTARG() macro. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Wed Aug 9 14:17:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 06:17:20 -0700 Subject: [Patches] [Patch #100654] list comprehensions in Python (for 1.7) Message-ID: <200008091317.GAA08398@bush.i.sourceforge.net> Patch #100654 has been updated. Project: Category: core (C code) Status: Open Summary: list comprehensions in Python (for 1.7) Follow-Ups: Date: 2000-Jun-28 07:07 By: gvanrossum Comment: This one's for Tim to thaw later. ------------------------------------------------------- Date: 2000-Jul-09 15:45 By: twouters Comment: The new patch is a CVS diff, which makes it kind of hard to apply (it'll only apply with the right GNU patch, with 'POSIXLY_CORRECT' defined, and with the moon in the right phase, which it currently isn't, apparently ;) POSIXLY_CORRECT also has some other effects, like that patch refuses to create new files :P Can I ask for a normal recursive-diff so I can recreate the range-list-literal patch relative to this one ? ------------------------------------------------------- Date: 2000-Jul-24 06:15 By: montanaro Comment: This new patch is simply an update to keep up with the recent ANSIfication of the Python source... ------------------------------------------------------- Date: 2000-Jul-27 13:08 By: gvanrossum Comment: I actually like this a lot (am running with it myself!), but the patch needs to be reworked so that it requires [(x,x) for x in ...] instead of allowing [x,x for x in ...]. It also may require integration with the range literals syntax, but that should be relatively minor. ------------------------------------------------------- Date: 2000-Jul-27 13:29 By: montanaro Comment: Okay, the grammar stuff is a little bit beyond me and I don't have the time to investigate it fully at the moment. *** Perhaps someone can give me a little direction... *** ------------------------------------------------------- Date: 2000-Jul-28 00:12 By: ping Comment: I'm pretty sure i know how to do this (just replace the list-making clause of the "atom:" production with: '[' [test [list_iter | ',' testlist]] ']' then update com_list_constructor and the LSQB clause of com_atom appropriately), but i still much prefer a style that uses a separator -- if not between clauses, then at least between the expression and the conditions. My favourite: [x*2, for x in spam, if x > 3] The separator after the expression can be comma, semicolon, or omitted; the separator between conditions can be any of these as well as colon. (Greg's original patch chooses "nothing-nothing"; i choose "comma-comma".) The results of Greg Wilson's survey may also be useful. Once a decision is made, it should be easy to adjust the grammar for any of these twelve possibilities. So all we need is a Pronouncement. :) ------------------------------------------------------- Date: 2000-Aug-09 06:17 By: montanaro Comment: (I submitted an update last night, but it appears not to have "taken". Is that because I'm changing the status from "rejected" to "open".) This is a corrected patch from Ka-Ping Yee that adds the parens requirement for tuples in the leading expression, e.g.: [(x,x**2) for x in range(5)] instead of Greg Ewing's original syntax which allowed [x,x**2 for x in range(5)] ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470 From noreply@sourceforge.net Wed Aug 9 17:55:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 09:55:13 -0700 Subject: [Patches] [Patch #101134] for 1.6: removing rint() occurences from config* Message-ID: <200008091655.JAA18186@bush.i.sourceforge.net> Patch #101134 has been updated. Project: Category: None Status: Open Summary: for 1.6: removing rint() occurences from config* ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101134&group_id=5470 From noreply@sourceforge.net Wed Aug 9 17:55:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 09:55:56 -0700 Subject: [Patches] [Patch #101134] for 1.6: removing rint() occurences from config* Message-ID: <200008091655.JAA18208@bush.i.sourceforge.net> Patch #101134 has been updated. Project: Category: Build Status: Open Summary: for 1.6: removing rint() occurences from config* ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101134&group_id=5470 From noreply@sourceforge.net Wed Aug 9 21:14:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 13:14:52 -0700 Subject: [Patches] [Patch #101135] 'import x as y' and 'from x import y as z' Message-ID: <200008092014.NAA08040@delerium.i.sourceforge.net> Patch #101135 has been updated. Project: Category: core (C code) Status: Open Summary: 'import x as y' and 'from x import y as z' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470 From noreply@sourceforge.net Wed Aug 9 21:23:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 13:23:05 -0700 Subject: [Patches] [Patch #101135] 'import x as y' and 'from x import y as z' Message-ID: <200008092023.NAA25880@bush.i.sourceforge.net> Patch #101135 has been updated. Project: Category: core (C code) Status: Open Summary: 'import x as y' and 'from x import y as z' Follow-Ups: Date: 2000-Aug-09 13:23 By: twouters Comment: This patch adds the oft-proposed 'import as' syntax, to both 'import module' and 'from module import ...', but without making 'as' a reserved word (by using the technique Tim Peters proposed on python-dev.) 'import spam as egg' is a very simple patch to compile.c, which doesn't need changes to the VM, but 'from spam import dog as meat' needs a new bytecode, which this patch calls 'FROM_IMPORT_AS'. The bytecode loads an object from a module onto the stack, so a STORE_NAME can store it later. This can't be done by the normal FROM_IMPORT opcode, because it needs to take the special case of '*' into account. Also, because it uses 'STORE_NAME', it's now possible to mix 'import' and 'global', like so: global X from foo import X as X The patch still generates the old code for from foo import X (without 'as') mostly to save on bytecode size, and for the 'compatibility' with mixing 'global' and 'from .. import'... I'm not sure what's the best thing to do. The patch doesn't include a test suite or documentation, yet. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470 From noreply@sourceforge.net Wed Aug 9 22:48:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 14:48:40 -0700 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <200008092148.OAA28983@bush.i.sourceforge.net> Patch #101137 has been updated. Project: Category: Modules Status: Open Summary: Add raw packet support to socketmodule.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Wed Aug 9 23:07:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 15:07:22 -0700 Subject: [Patches] [Patch #101138] 'for i indexing a in l': exposing the for-loop counter Message-ID: <200008092207.PAA11991@delerium.i.sourceforge.net> Patch #101138 has been updated. Project: Category: core (C code) Status: Open Summary: 'for i indexing a in l': exposing the for-loop counter ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101138&group_id=5470 From noreply@sourceforge.net Wed Aug 9 23:10:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 15:10:07 -0700 Subject: [Patches] [Patch #101138] 'for i indexing a in l': exposing the for-loop counter Message-ID: <200008092210.PAA12107@delerium.i.sourceforge.net> Patch #101138 has been updated. Project: Category: core (C code) Status: Open Summary: 'for i indexing a in l': exposing the for-loop counter Follow-Ups: Date: 2000-Aug-09 15:10 By: twouters Comment: This patch adds a way to get the loop counter in Python for-loops. The syntax is one Just quoted on python-dev today, which he attributes to Tim (and was probably proposed by half the thinking Python community by now ;) It's a quick and dirty hack, but it works. There might be refcounting bugs and much more efficient ways to do it, but it works ;) It also lacks a test case and documentation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101138&group_id=5470 From noreply@sourceforge.net Thu Aug 10 10:52:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 02:52:42 -0700 Subject: [Patches] [Patch #101134] for 1.6: removing rint() occurences from config* Message-ID: <200008100952.CAA00768@delerium.i.sourceforge.net> Patch #101134 has been updated. Project: Category: Build Status: Closed Summary: for 1.6: removing rint() occurences from config* ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101134&group_id=5470 From noreply@sourceforge.net Thu Aug 10 11:23:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 03:23:17 -0700 Subject: [Patches] [Patch #101103] smtplib.py doesn't calculate fqdn correctly Message-ID: <200008101023.DAA19925@bush.i.sourceforge.net> Patch #101103 has been updated. Project: Category: library Status: Open Summary: smtplib.py doesn't calculate fqdn correctly Follow-Ups: Date: 2000-Aug-06 19:08 By: bwarsaw Comment: A bug report submitted to the Mailman project[1], describes the situation where smtplib.py may choose a non-FQDN hostname for HELO/EHLO. Here is a patch to use the algorithm described in the socket module documentation. [1] http://sourceforge.net/bugs/?func=detailbug&bug_id=110935&group_id=103 ------------------------------------------------------- Date: 2000-Aug-10 03:23 By: nowonder Comment: Looks alright to me. Works fine, too. Remark: In case there is no fqdn in [hostname]+aliases, this routine selects the last entry in aliases (or hostname if aliases is empty). I guess that is okay (aliases being what they are), but if not adding "else: name = hostname" to the for-loop will do the trick of selecting hostname in those cases. Meta-remark: I would like to change the Status to Accepted, but the Patch Manager Guidelines state I have to be morally equivalent to Guido to do that. So I better leave it at Open. Quoting from these guidelines: "Is the Guido bottleneck avoidable?" ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101103&group_id=5470 From noreply@sourceforge.net Thu Aug 10 13:56:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 05:56:40 -0700 Subject: [Patches] [Patch #101103] smtplib.py doesn't calculate fqdn correctly Message-ID: <200008101256.FAA06548@delerium.i.sourceforge.net> Patch #101103 has been updated. Project: Category: library Status: Accepted Summary: smtplib.py doesn't calculate fqdn correctly Follow-Ups: Date: 2000-Aug-06 19:08 By: bwarsaw Comment: A bug report submitted to the Mailman project[1], describes the situation where smtplib.py may choose a non-FQDN hostname for HELO/EHLO. Here is a patch to use the algorithm described in the socket module documentation. [1] http://sourceforge.net/bugs/?func=detailbug&bug_id=110935&group_id=103 ------------------------------------------------------- Date: 2000-Aug-10 03:23 By: nowonder Comment: Looks alright to me. Works fine, too. Remark: In case there is no fqdn in [hostname]+aliases, this routine selects the last entry in aliases (or hostname if aliases is empty). I guess that is okay (aliases being what they are), but if not adding "else: name = hostname" to the for-loop will do the trick of selecting hostname in those cases. Meta-remark: I would like to change the Status to Accepted, but the Patch Manager Guidelines state I have to be morally equivalent to Guido to do that. So I better leave it at Open. Quoting from these guidelines: "Is the Guido bottleneck avoidable?" ------------------------------------------------------- Date: 2000-Aug-10 05:56 By: gvanrossum Comment: Check it in. I agree with your suggestion to change the patch. Please also change ``string.find(name, '.') >= 0'' into the much clearer ``'.' in name''. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101103&group_id=5470 From noreply@sourceforge.net Thu Aug 10 15:06:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 07:06:31 -0700 Subject: [Patches] [Patch #101103] smtplib.py doesn't calculate fqdn correctly Message-ID: <200008101406.HAA27255@bush.i.sourceforge.net> Patch #101103 has been updated. Project: Category: library Status: Closed Summary: smtplib.py doesn't calculate fqdn correctly Follow-Ups: Date: 2000-Aug-06 19:08 By: bwarsaw Comment: A bug report submitted to the Mailman project[1], describes the situation where smtplib.py may choose a non-FQDN hostname for HELO/EHLO. Here is a patch to use the algorithm described in the socket module documentation. [1] http://sourceforge.net/bugs/?func=detailbug&bug_id=110935&group_id=103 ------------------------------------------------------- Date: 2000-Aug-10 03:23 By: nowonder Comment: Looks alright to me. Works fine, too. Remark: In case there is no fqdn in [hostname]+aliases, this routine selects the last entry in aliases (or hostname if aliases is empty). I guess that is okay (aliases being what they are), but if not adding "else: name = hostname" to the for-loop will do the trick of selecting hostname in those cases. Meta-remark: I would like to change the Status to Accepted, but the Patch Manager Guidelines state I have to be morally equivalent to Guido to do that. So I better leave it at Open. Quoting from these guidelines: "Is the Guido bottleneck avoidable?" ------------------------------------------------------- Date: 2000-Aug-10 05:56 By: gvanrossum Comment: Check it in. I agree with your suggestion to change the patch. Please also change ``string.find(name, '.') >= 0'' into the much clearer ``'.' in name''. ------------------------------------------------------- Date: 2000-Aug-10 07:06 By: nowonder Comment: Okay, I checked it in (with the two modifications). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101103&group_id=5470 From noreply@sourceforge.net Thu Aug 10 15:23:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 07:23:24 -0700 Subject: [Patches] [Patch #101141] Make 'Grammar' when necessary Message-ID: <200008101423.HAA27804@bush.i.sourceforge.net> Patch #101141 has been updated. Project: Category: None Status: Open Summary: Make 'Grammar' when necessary ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101141&group_id=5470 From noreply@sourceforge.net Thu Aug 10 15:25:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 07:25:50 -0700 Subject: [Patches] [Patch #101141] Make 'Grammar' when necessary Message-ID: <200008101425.HAA27926@bush.i.sourceforge.net> Patch #101141 has been updated. Project: Category: None Status: Open Summary: Make 'Grammar' when necessary Follow-Ups: Date: 2000-Aug-10 07:25 By: twouters Comment: Add Grammar to the subdirectories to recursively 'make', to solve Peter's problem of trying out a patch that touches Grammar and not typing 'make' in 'Grammar' by hand ;-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101141&group_id=5470 From noreply@sourceforge.net Thu Aug 10 16:44:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 08:44:26 -0700 Subject: [Patches] [Patch #101061] pyport.h and extern "C" Message-ID: <200008101544.IAA12503@delerium.i.sourceforge.net> Patch #101061 has been updated. Project: Category: core (C code) Status: Accepted Summary: pyport.h and extern "C" Follow-Ups: Date: 2000-Aug-03 06:56 By: htrd Comment: An existing comment in this file says... some C++ #include's don't like to be included inside an extern "C" ....however numerous standard #includes were inside that extern "C". This patch just reorders a few things, so all the #includes are at the top, outside the extern "C". ------------------------------------------------------- Date: 2000-Aug-06 13:48 By: marangoz Comment: What exactly breaks with the current setup that is solved by this patch? ------------------------------------------------------- Date: 2000-Aug-07 01:16 By: htrd Comment: Various standard headers are #included inside a.... #ifdef __cplusplus extern "C" { #endif If pyport.h is included inside a C++ program then those standard headers might enable various C++-specific extensions, which might fail inside an extern "C" Specifically in MSVC 6 this leads to.... e:\program files\microsoft visual studio\vc98\include\math.h(514) : error C2894: templates cannot be declared to have 'C' linkage ------------------------------------------------------- Date: 2000-Aug-10 08:44 By: marangoz Comment: Ok, understood. Assigned to marangoz, Status: Accepted. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101061&group_id=5470 From noreply@sourceforge.net Thu Aug 10 16:52:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 08:52:16 -0700 Subject: [Patches] [Patch #101065] bogus counter for recursive PyObject_Compare() Message-ID: <200008101552.IAA12705@delerium.i.sourceforge.net> Patch #101065 has been updated. Project: Category: core (C code) Status: Open Summary: bogus counter for recursive PyObject_Compare() Follow-Ups: Date: 2000-Aug-03 12:17 By: marangoz Comment: Looks like _PyCompareState_nesting is not updated accordingly on err conditions. ------------------------------------------------------- Date: 2000-Aug-10 08:52 By: marangoz Comment: Jeremy, if you don't give a penny about this patch, reassign it back to me and if nobody chimes in in the meantime, I'll check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101065&group_id=5470 From noreply@sourceforge.net Thu Aug 10 17:03:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 09:03:17 -0700 Subject: [Patches] [Patch #101030] new zip() builtin Message-ID: <200008101603.JAA13069@delerium.i.sourceforge.net> Patch #101030 has been updated. Project: Category: core (C code) Status: Closed Summary: new zip() builtin Follow-Ups: Date: 2000-Jul-31 11:00 By: gvanrossum Comment: I won't even look at this until you've supplied a test_zip.py module. :-) Fred will probably like a doc patch, too... ------------------------------------------------------- Date: 2000-Jul-31 11:27 By: bwarsaw Comment: regr test and doc patches added ------------------------------------------------------- Date: 2000-Jul-31 11:38 By: gvanrossum Comment: Great! Note a minor bug in the test suite: exc=1 should only be set in the two except TypeError clauses, not in the mail try clauses! (After all you want it to raise an exception, so falling through the main clause is an *error*.) ------------------------------------------------------- Date: 2000-Aug-10 09:03 By: nowonder Comment: it's checked in, so it should be closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101030&group_id=5470 From noreply@sourceforge.net Thu Aug 10 17:11:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 09:11:21 -0700 Subject: [Patches] [Patch #101046] fcntlmodule: use PyArg_ParseTuple everywhere. Message-ID: <200008101611.JAA13366@delerium.i.sourceforge.net> Patch #101046 has been updated. Project: Category: Modules Status: Closed Summary: fcntlmodule: use PyArg_ParseTuple everywhere. Follow-Ups: Date: 2000-Aug-02 06:27 By: gvanrossum Comment: The idea is fine, but you missed the fact that the code is trying to simulate "ii|i" by trying "(ii)" and then "(iii)". This should be collapsed too (in two places). If you fix this I'll accept it. ------------------------------------------------------- Date: 2000-Aug-02 06:59 By: hooft Comment: I revised the patch. Still not too happy about all error messages: >>> fcntl.ioctl(1,2,fcntl) Traceback (most recent call last): File "", line 1, in ? TypeError: an integer is required But I don't know how to fix that. ------------------------------------------------------- Date: 2000-Aug-02 13:48 By: gvanrossum Comment: Done. That error messages comes from intobject.c, to fix it you would have to fix that file as well as PyArg_ParseTuple. Note: the module test.test_fcntl doesn't d a very thorough test -- it doesn't even test ioctl at all! ------------------------------------------------------- Date: 2000-Aug-10 09:11 By: nowonder Comment: this has been checked in, so it should be closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101046&group_id=5470 From noreply@sourceforge.net Thu Aug 10 17:16:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 09:16:29 -0700 Subject: [Patches] [Patch #101141] Make 'Grammar' when necessary Message-ID: <200008101616.JAA13513@delerium.i.sourceforge.net> Patch #101141 has been updated. Project: Category: None Status: Open Summary: Make 'Grammar' when necessary Follow-Ups: Date: 2000-Aug-10 07:25 By: twouters Comment: Add Grammar to the subdirectories to recursively 'make', to solve Peter's problem of trying out a patch that touches Grammar and not typing 'make' in 'Grammar' by hand ;-) ------------------------------------------------------- Date: 2000-Aug-10 09:16 By: twouters Comment: oops, this is the order I meant to put the directories in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101141&group_id=5470 From noreply@sourceforge.net Thu Aug 10 19:26:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 11:26:07 -0700 Subject: [Patches] [Patch #101145] co_flags fix for classes generated by Tools/compile.py Message-ID: <200008101826.LAA04050@bush.i.sourceforge.net> Patch #101145 has been updated. Project: Category: demos and tools Status: Open Summary: co_flags fix for classes generated by Tools/compile.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101145&group_id=5470 From noreply@sourceforge.net Thu Aug 10 21:56:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 13:56:03 -0700 Subject: [Patches] [Patch #101146] Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Message-ID: <200008102056.NAA09461@bush.i.sourceforge.net> Patch #101146 has been updated. Project: Category: core (C code) Status: Open Summary: Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101146&group_id=5470 From noreply@sourceforge.net Thu Aug 10 21:59:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 13:59:22 -0700 Subject: [Patches] [Patch #101146] Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Message-ID: <200008102059.NAA09524@bush.i.sourceforge.net> Patch #101146 has been updated. Project: Category: core (C code) Status: Open Summary: Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Follow-Ups: Date: 2000-Aug-10 13:59 By: twouters Comment: Remove the UNPACK_TUPLE and UNPACK_LIST opcodes in favor of a single UNPACK_SEQUENCE opcode, since both the implementation and the generation of the UNPACK opcodes are identical. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101146&group_id=5470 From noreply@sourceforge.net Fri Aug 11 00:30:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 16:30:30 -0700 Subject: [Patches] [Patch #101152] smtplib uses send() without verifying the amount of data sen Message-ID: <200008102330.QAA14735@bush.i.sourceforge.net> Patch #101152 has been updated. Project: Category: library Status: Open Summary: smtplib uses send() without verifying the amount of data sen ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101152&group_id=5470 From noreply@sourceforge.net Fri Aug 11 00:30:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 16:30:15 -0700 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py Message-ID: <200008102330.QAA28916@delerium.i.sourceforge.net> Patch #101151 has been updated. Project: Category: library Status: Open Summary: expose public get_fqdn function in smtplib.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101151&group_id=5470 From noreply@sourceforge.net Fri Aug 11 00:32:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 16:32:42 -0700 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py Message-ID: <200008102332.QAA28968@delerium.i.sourceforge.net> Patch #101151 has been updated. Project: Category: library Status: Open Summary: expose public get_fqdn function in smtplib.py Follow-Ups: Date: 2000-Aug-10 16:32 By: nowonder Comment: expose get_fqdn function rather than calling internal _get_fqdn_hostname function. Only call from helo() and ehlo() if needed. refer from documentation's mentioning of algorithm for fqdn to implementation of get_fqdn. should there be docs for quotedata() and get_fqdn() in libsmtplib.tex? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101151&group_id=5470 From noreply@sourceforge.net Fri Aug 11 01:07:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 17:07:33 -0700 Subject: [Patches] [Patch #101065] bogus counter for recursive PyObject_Compare() Message-ID: <200008110007.RAA30118@delerium.i.sourceforge.net> Patch #101065 has been updated. Project: Category: core (C code) Status: Closed Summary: bogus counter for recursive PyObject_Compare() Follow-Ups: Date: 2000-Aug-03 12:17 By: marangoz Comment: Looks like _PyCompareState_nesting is not updated accordingly on err conditions. ------------------------------------------------------- Date: 2000-Aug-10 08:52 By: marangoz Comment: Jeremy, if you don't give a penny about this patch, reassign it back to me and if nobody chimes in in the meantime, I'll check it in. ------------------------------------------------------- Date: 2000-Aug-10 17:07 By: marangoz Comment: Ok, nevermind :-) Turns out it's a subtle non-critical bug that slows down the comparisons due to missing decrements. Explanation: after NESTING_LIMIT executions of the statement: if (++_PyCompareState_nesting > NESTING_LIMIT) { ... } the latter was always evaluated to true, because the counter was not decremented outside of the if block, causing PyObject_Compare() to always execute the expensive version of the comparisons, involving make_pair(), the inprogress dict, etc. Reassigning back to marangoz, checking in, status: Closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101065&group_id=5470 From noreply@sourceforge.net Fri Aug 11 05:04:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 21:04:08 -0700 Subject: [Patches] [Patch #100895] safe version of PyErr_Format Message-ID: <200008110404.VAA05305@delerium.i.sourceforge.net> Patch #100895 has been updated. Project: Category: core (C code) Status: Rejected Summary: safe version of PyErr_Format Follow-Ups: Date: 2000-Jul-17 14:56 By: effbot Comment: minor tweaks (mostly comments), based on input from moshe. ------------------------------------------------------- Date: 2000-Jul-17 23:23 By: moshez Comment: I'm +1 on that! It will plug one more security hole in Python, and seems a "good enough" replacement for an unsure snprintf() ------------------------------------------------------- Date: 2000-Aug-08 10:19 By: effbot Comment: regenerated, since moshez reported that it didn't apply cleanly to the current CVS tree. reassigned, since it's been sitting here for ages. ------------------------------------------------------- Date: 2000-Aug-10 21:04 By: tim_one Comment: Rejected and back to /F. Major: no docs! Format strings processed by this have different semantics than anyone could guess (e.g., flags are ignored, width is ignored, some format codes are copied verbatim). Reverse-engineering the code each time there's a question is just too painful. You're basically inventing a new sublanguage here, so document what the heck it is & means. Mechanical: There's a "step 1" but no "step 2" . We shouldn't be #ifdef'ing on prototypes anymore. Guido did not yield to the push for 4-space indents in C code, so this should use hard tabs. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From noreply@sourceforge.net Fri Aug 11 05:08:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 21:08:36 -0700 Subject: [Patches] [Patch #100835] PC/config.h: support for gnu-win32 and lcc-win32 Message-ID: <200008110408.VAA05445@delerium.i.sourceforge.net> Patch #100835 has been updated. Project: Category: None Status: Open Summary: PC/config.h: support for gnu-win32 and lcc-win32 Follow-Ups: Date: 2000-Jul-10 04:43 By: RLiebscher Comment: This patch makes it possible to use gnu-win32 and lcc-win32 (http://www.cs.virginia.edu/~lcc-win32/) compilers to build extension modules. It adds compiler specific sections to PC/config.h . It also extends the Borland compiler section. This has then two parts, one for Win32 and the other one for the rest. The Win32 part should be almost complete. *** This patch is not intended to make it possible to compile Python with these compilers, it is intended to be able to use these compilers to build extension modules. **** ------------------------------------------------------- Date: 2000-Jul-10 04:44 By: RLiebscher Comment: This patch makes it possible to use gnu-win32 and lcc-win32 (http://www.cs.virginia.edu/~lcc-win32/) compilers to build extension modules. It adds compiler specific sections to PC/config.h . It also extends the Borland compiler section. This has then two parts, one for Win32 and the other one for the rest. The Win32 part should be almost complete. *** This patch is not intended to make it possible to compile Python with these compilers, it is intended to be able to use these compilers to build extension modules. **** ------------------------------------------------------- Date: 2000-Jul-13 13:22 By: jhylton Comment: Assigned to Tim because he is handling Windows build issues ------------------------------------------------------- Date: 2000-Aug-10 21:08 By: tim_one Comment: Left open and assigned to Mark Hammond. Mark, you have any objections to this? I have no way to test any of it, and I doubt any of us do. If you don't object to the patch by eyeball either, please Accept it and either check it in or assign it to someone else (I don't have a working "patch" yet!). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100835&group_id=5470 From noreply@sourceforge.net Fri Aug 11 05:25:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 21:25:53 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008110425.VAA05987@delerium.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Open Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 05:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 18:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 02:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 16:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 07:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-27 22:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 14:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- Date: 2000-Aug-08 22:26 By: tim_one Comment: Changed status to Rejected, but left assigned to me (I'll Open it again when it's updated). As I said at the bottom of my last comment on this, you cannot assume sizeof(short)==2: please get rid of the new big-endian/little-endian trickery. The code is not portable as-is. Even on machines where sizeof(short) does equal 2, shorts in the opcode stream are not guaranteed to be naturally aligned, and trying to access them as if they were can lead to anything from a core dump to an expensive trap to the OS to fix up the unaligned read. And on the only machines where this gimmick could actually pay (a little-endian machine where sizeof(short)==2 *and* the HW doesn't penalize unnatural alignment), the compiler should be smart enough to optimize the old expression for us. ------------------------------------------------------- Date: 2000-Aug-09 04:36 By: gvanrossum Comment: I think that all Tim wants is that you undo the changes you made to the NEXTARG() macro. ------------------------------------------------------- Date: 2000-Aug-10 14:51 By: cgw Comment: Understood. I've now put the NEXTARG macro back to its original form; sorry for overlooking this on the previous pass. ------------------------------------------------------- Date: 2000-Aug-10 21:25 By: tim_one Comment: Changed to Open and assigned to Vladimir. Vlad, have any comments on this? Care to test it? I'm inclined to accept it now "by eyeball", because it does fix some bugs. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Fri Aug 11 08:38:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 00:38:45 -0700 Subject: [Patches] [Patch #101138] 'for i indexing a in l': exposing the for-loop counter Message-ID: <200008110738.AAA12155@delerium.i.sourceforge.net> Patch #101138 has been updated. Project: Category: core (C code) Status: Open Summary: 'for i indexing a in l': exposing the for-loop counter Follow-Ups: Date: 2000-Aug-09 15:10 By: twouters Comment: This patch adds a way to get the loop counter in Python for-loops. The syntax is one Just quoted on python-dev today, which he attributes to Tim (and was probably proposed by half the thinking Python community by now ;) It's a quick and dirty hack, but it works. There might be refcounting bugs and much more efficient ways to do it, but it works ;) It also lacks a test case and documentation. ------------------------------------------------------- Date: 2000-Aug-11 00:27 By: hooft Comment: Do we need a new keyword for this functionality, or can we use zip? Maybe adding zip-magic would help, but: >>> a=['a','b','c','d'] >>> for i,el in zip(xrange(9999999),a): ... print i,el ... 0 a 1 b 2 c 3 d ------------------------------------------------------- Date: 2000-Aug-11 00:33 By: hooft Comment: Or: >>> class indexing: ... def __init__(self,a): ... self.data=a ... def __getitem__(self,i): ... return i,self.data[i] ... >>> for i,el in indexing(a): ... print i,el ... 0 a 1 b 2 c 3 d >>> ------------------------------------------------------- Date: 2000-Aug-11 00:38 By: twouters Comment: The patch exposes the already-present loop counter to python code, rather than just adding a list of ranges to loop over. That is one of the reasons to make it a syntactic change: other techniques to use the builtin loop counter would require psychic interpreters ;) The patch does *not* introduce a new keyword, by the way. the 'indexing' name is just a NAME, not a real keyword, and can be used as a variable just fine. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101138&group_id=5470 From noreply@sourceforge.net Fri Aug 11 08:58:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 00:58:15 -0700 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py Message-ID: <200008110758.AAA30485@bush.i.sourceforge.net> Patch #101151 has been updated. Project: Category: library Status: Open Summary: expose public get_fqdn function in smtplib.py Follow-Ups: Date: 2000-Aug-10 16:32 By: nowonder Comment: expose get_fqdn function rather than calling internal _get_fqdn_hostname function. Only call from helo() and ehlo() if needed. refer from documentation's mentioning of algorithm for fqdn to implementation of get_fqdn. should there be docs for quotedata() and get_fqdn() in libsmtplib.tex? ------------------------------------------------------- Date: 2000-Aug-11 00:58 By: twouters Comment: Looks okay, though perhaps the function should be named 'make_fqdn()' instead of 'get_fqdn' -- you're passing it a name to operate on, after all. That's just a personal preference. I'll let it float for a few days to let someone else knowledgable in the area of SMTP give their opinion on the whole FQDN issue, but as far as I'm concerned, this patch is accepted. Am I the moral equivalent of Guido here ? I have no clue :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101151&group_id=5470 From noreply@sourceforge.net Fri Aug 11 09:33:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 01:33:04 -0700 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py Message-ID: <200008110833.BAA13838@delerium.i.sourceforge.net> Patch #101151 has been updated. Project: Category: library Status: Open Summary: expose public get_fqdn function in smtplib.py Follow-Ups: Date: 2000-Aug-10 16:32 By: nowonder Comment: expose get_fqdn function rather than calling internal _get_fqdn_hostname function. Only call from helo() and ehlo() if needed. refer from documentation's mentioning of algorithm for fqdn to implementation of get_fqdn. should there be docs for quotedata() and get_fqdn() in libsmtplib.tex? ------------------------------------------------------- Date: 2000-Aug-11 00:58 By: twouters Comment: Looks okay, though perhaps the function should be named 'make_fqdn()' instead of 'get_fqdn' -- you're passing it a name to operate on, after all. That's just a personal preference. I'll let it float for a few days to let someone else knowledgable in the area of SMTP give their opinion on the whole FQDN issue, but as far as I'm concerned, this patch is accepted. Am I the moral equivalent of Guido here ? I have no clue :-) ------------------------------------------------------- Date: 2000-Aug-11 01:33 By: nowonder Comment: as I write in my mail to python-dev, I have found three other occurences of the algorithm. Maybe this should go in some more general place. Where? BTW: I like make_fqdn() better. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101151&group_id=5470 From noreply@sourceforge.net Fri Aug 11 09:40:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 01:40:43 -0700 Subject: [Patches] [Patch #101141] Make 'Grammar' when necessary Message-ID: <200008110840.BAA14046@delerium.i.sourceforge.net> Patch #101141 has been updated. Project: Category: Build Status: Accepted Summary: Make 'Grammar' when necessary Follow-Ups: Date: 2000-Aug-10 07:25 By: twouters Comment: Add Grammar to the subdirectories to recursively 'make', to solve Peter's problem of trying out a patch that touches Grammar and not typing 'make' in 'Grammar' by hand ;-) ------------------------------------------------------- Date: 2000-Aug-10 09:16 By: twouters Comment: oops, this is the order I meant to put the directories in. ------------------------------------------------------- Date: 2000-Aug-11 01:40 By: nowonder Comment: Although I am NOT feeling morally equivalent to Guido, I changed the status to 'Accepted'. The change is trivial and should not pose any problems. waiting-to-be-struck-by-lightning-ly y'rs Peter ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101141&group_id=5470 From noreply@sourceforge.net Fri Aug 11 10:08:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 02:08:30 -0700 Subject: [Patches] [Patch #101152] smtplib uses send() without verifying the amount of data sen Message-ID: <200008110908.CAA14898@delerium.i.sourceforge.net> Patch #101152 has been updated. Project: Category: library Status: Open Summary: smtplib uses send() without verifying the amount of data sen Follow-Ups: Date: 2000-Aug-11 02:08 By: nowonder Comment: I just reviewed the patch by sight, but shouldn't it be str[ttl:] instead of str[slen:]? I cannot see anything being ever sent with your version. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101152&group_id=5470 From noreply@sourceforge.net Fri Aug 11 10:51:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 02:51:25 -0700 Subject: [Patches] [Patch #101146] Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Message-ID: <200008110951.CAA01465@bush.i.sourceforge.net> Patch #101146 has been updated. Project: Category: core (C code) Status: Open Summary: Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Follow-Ups: Date: 2000-Aug-10 13:59 By: twouters Comment: Remove the UNPACK_TUPLE and UNPACK_LIST opcodes in favor of a single UNPACK_SEQUENCE opcode, since both the implementation and the generation of the UNPACK opcodes are identical. ------------------------------------------------------- Date: 2000-Aug-11 02:51 By: nowonder Comment: Looks fine on visual inspection and works for me, too. Someone else should review this, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101146&group_id=5470 From noreply@sourceforge.net Fri Aug 11 12:52:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 04:52:43 -0700 Subject: [Patches] [Patch #101061] pyport.h and extern "C" Message-ID: <200008111152.EAA20161@delerium.i.sourceforge.net> Patch #101061 has been updated. Project: Category: core (C code) Status: Closed Summary: pyport.h and extern "C" Follow-Ups: Date: 2000-Aug-03 06:56 By: htrd Comment: An existing comment in this file says... some C++ #include's don't like to be included inside an extern "C" ....however numerous standard #includes were inside that extern "C". This patch just reorders a few things, so all the #includes are at the top, outside the extern "C". ------------------------------------------------------- Date: 2000-Aug-06 13:48 By: marangoz Comment: What exactly breaks with the current setup that is solved by this patch? ------------------------------------------------------- Date: 2000-Aug-07 01:16 By: htrd Comment: Various standard headers are #included inside a.... #ifdef __cplusplus extern "C" { #endif If pyport.h is included inside a C++ program then those standard headers might enable various C++-specific extensions, which might fail inside an extern "C" Specifically in MSVC 6 this leads to.... e:\program files\microsoft visual studio\vc98\include\math.h(514) : error C2894: templates cannot be declared to have 'C' linkage ------------------------------------------------------- Date: 2000-Aug-10 08:44 By: marangoz Comment: Ok, understood. Assigned to marangoz, Status: Accepted. ------------------------------------------------------- Date: 2000-Aug-11 04:52 By: marangoz Comment: Checked in. Status: Closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101061&group_id=5470 From noreply@sourceforge.net Fri Aug 11 15:50:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 07:50:13 -0700 Subject: [Patches] [Patch #101152] smtplib uses send() without verifying the amount of data sen Message-ID: <200008111450.HAA11043@bush.i.sourceforge.net> Patch #101152 has been updated. Project: Category: library Status: Rejected Summary: smtplib uses send() without verifying the amount of data sen Follow-Ups: Date: 2000-Aug-11 02:08 By: nowonder Comment: I just reviewed the patch by sight, but shouldn't it be str[ttl:] instead of str[slen:]? I cannot see anything being ever sent with your version. ------------------------------------------------------- Date: 2000-Aug-11 07:50 By: gvanrossum Comment: The behavior that this patch is trying to fix (send() not sending all bytes) doesn't actually exist, at least not to the docs we've found. So the patch is rejected. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101152&group_id=5470 From special@buoinet.net Fri Aug 11 16:43:56 2000 From: special@buoinet.net (special@buoinet.net) Date: Fri, 11 Aug 2000 11:43:56 -0400 Subject: [Patches] $9.95/ mo web hosting Message-ID: Sir: I noticed your website and am simply offering you what could be a much better deal on your web hosting... If you think you might be interested, go to our site: http://www.buoinet.net see what we have to offer... Our hosting plans start at $9.95... Thanks again for your time - you wont be getting any more email from us unless you email us requesting more information. If you represent a web design firm, we offer bulk discounting as well. Very Truly Yours -Mike Carlson www.buoinet.net This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, http://www.senate.gov/~murkowski/commercialemail/S771index.html Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word "remove" in the subject line. From noreply@sourceforge.net Fri Aug 11 20:04:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 12:04:23 -0700 Subject: [Patches] [Patch #100510] largefile support for Win64 (and some other fixes) Message-ID: <200008111904.MAA03016@delerium.i.sourceforge.net> Patch #100510 has been updated. Project: Category: core (C code) Status: Closed Summary: largefile support for Win64 (and some other fixes) Follow-Ups: Date: 2000-Jun-06 19:56 By: tmick Comment: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. ------------------------------------------------------- Date: 2000-Jun-06 19:58 By: tmick Comment: This patch adds largefile support for Win64 and Linux64 (the latter already motly worked I think), and fixes some possible buffer overflows on all systems with largefile support. NOTE: this patch depends on my earlier patch to PC/config.h and configure.in for SIZEOF_OFF_T and SIZEOF_FPOS_T. (see: "[Patches] changes to configure.in and PC/config.h for 64-bit systems") Win64 largefile support involved fixing file_seek, file_tell, and file_truncate to properly handle large indeces and to use the proper Win64 system APIs. Win64 does not have 64-bit capable versions of ftell and fseek, this could be worked around with fgetpos() and fsetpos() (and _telli64(), and 64-bit tell()). _portable_ftell() and _portable_fseek() were written to hold the platform dependent logic. You are still restricted to 32-bits for single reads and writes. Previously _chsize was used blindly as the replacement for ftruncate() in Win32. In fact, _chsize() is not 64-bit capable so and appropriate overflow check was added. There are some type histrionics involved because off_t is only 32-bits on Win64. fpos_t is 64-bits, however, so fpos_t is used for Win64. As well, the patch adds some necessary overflow checks (raising OverflowError when an overflow is detected). See file_read for example. A forthcoming patch adds a test to the test suite for this largefile support. ------------------------------------------------------- Date: 2000-Jun-27 07:50 By: gvanrossum Comment: Tim- after you're fine with this, please assign to someone with a Linux box for further review. ------------------------------------------------------- Date: 2000-Jun-29 17:07 By: tim_one Comment: Looks good to me. Passed on to Fred. Fred, Guido wants someone to check this on Linux. Since you have the 64-bit Linux development disk, you're elected . ------------------------------------------------------- Date: 2000-Jul-09 23:37 By: tim_one Comment: Fred, do something with this or assign it to some other Unix geek? ------------------------------------------------------- Date: 2000-Jul-13 17:21 By: fdrake Comment: This looks good on platforms I have easy access to (linux/x86, linux/ia32 simulator). I do not have Linux+LFS (large file support; a kernel patch) installed on any machines, and could not test in that environment without having a separate machine to use as a test bed. Accepted as is; we can work out any problems that arise as needed, but it doesn't seem to break things. ------------------------------------------------------- Date: 2000-Jul-31 08:03 By: gvanrossum Comment: This was accepted ages ago. What are you waiting for? ------------------------------------------------------- Date: 2000-Aug-11 12:04 By: tmick Comment: Sorry about the delay. Had to make some small changes to get the old patch to apply. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100510&group_id=5470 From noreply@sourceforge.net Fri Aug 11 20:04:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 12:04:13 -0700 Subject: [Patches] [Patch #100511] test largefile support (test_largefile.py) Message-ID: <200008111904.MAA03013@delerium.i.sourceforge.net> Patch #100511 has been updated. Project: Category: library Status: Closed Summary: test largefile support (test_largefile.py) Follow-Ups: Date: 2000-Jun-06 19:58 By: tmick Comment: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. ------------------------------------------------------- Date: 2000-Jun-06 19:58 By: tmick Comment: This patch adds a test for largefiles (creating, seeking, telling, etc.). The test skips if there is no largefile support. There is one further problem. The test basically involves creating a file greater than 2GB and playing with it. On UN*X systems with sparse files this is no problem. On Win64 (which I have heard *can* do sparse files, but not in Python yet), however, >2GB space and a *long* time is required to run the test. I don't think it is reasonable to turn this on by default... so here is what I did. I extended regrtest.py to accept the --have-resources switch. This sets test_support.use_large_resources, which is checked in test_largefile.py. By default 'use_large_resources' is false. On Win64, then, by default the largefile test is skipped but can be run via the --have-resources switch to regrtest.py or by running the test directly. This seems to me the Right Thing. The affected files are: Lib/test/regrtest.py Lib/test/test_support.py Lib/test/test_largefile.py (new) Lib/test/output/test_largefile (new) ------------------------------------------------------- Date: 2000-Jun-29 17:13 By: tim_one Comment: Fred, can you test this on a Linux with > 2Gb files (needs the --have-resources switch; read Trent's comment), or pass it on to someone who can? I can't do more than stare at this, and nothing in my staring hit my eye. Well, Guido may hate the long option name (--have-resources), especially given that even with all those letters , it's not really self-describing. ------------------------------------------------------- Date: 2000-Jun-30 08:08 By: tmick Comment: --have-at-least-2GB-on-hard-drive-and-am-going-for-coffee- ------------------------------------------------------- Date: 2000-Jul-09 23:37 By: tim_one Comment: Fred, do something with this or assign it to some other Unix geek? ------------------------------------------------------- Date: 2000-Jul-13 17:23 By: fdrake Comment: Looks good to me, and properly skips the large file test on my Linux box. A second iteration may be useful to provide separate options for different resources (cpu/disk/ram), but it's not clearly needed at this time. Accepted as-is. ------------------------------------------------------- Date: 2000-Jul-31 08:03 By: gvanrossum Comment: This was accepted ages agon -- what are you waiting for? ------------------------------------------------------- Date: 2000-Aug-11 12:04 By: tmick Comment: Sorry about the delay. Had to make some small changes to get the old patch to apply. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100511&group_id=5470 From noreply@sourceforge.net Fri Aug 11 20:13:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 12:13:41 -0700 Subject: [Patches] [Patch #101146] Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Message-ID: <200008111913.MAA03344@delerium.i.sourceforge.net> Patch #101146 has been updated. Project: Category: core (C code) Status: Open Summary: Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Follow-Ups: Date: 2000-Aug-10 13:59 By: twouters Comment: Remove the UNPACK_TUPLE and UNPACK_LIST opcodes in favor of a single UNPACK_SEQUENCE opcode, since both the implementation and the generation of the UNPACK opcodes are identical. ------------------------------------------------------- Date: 2000-Aug-11 02:51 By: nowonder Comment: Looks fine on visual inspection and works for me, too. Someone else should review this, too. ------------------------------------------------------- Date: 2000-Aug-11 12:13 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101146&group_id=5470 From noreply@sourceforge.net Fri Aug 11 20:14:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 12:14:44 -0700 Subject: [Patches] [Patch #101146] Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Message-ID: <200008111914.MAA03357@delerium.i.sourceforge.net> Patch #101146 has been updated. Project: Category: core (C code) Status: Open Summary: Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Follow-Ups: Date: 2000-Aug-10 13:59 By: twouters Comment: Remove the UNPACK_TUPLE and UNPACK_LIST opcodes in favor of a single UNPACK_SEQUENCE opcode, since both the implementation and the generation of the UNPACK opcodes are identical. ------------------------------------------------------- Date: 2000-Aug-11 02:51 By: nowonder Comment: Looks fine on visual inspection and works for me, too. Someone else should review this, too. ------------------------------------------------------- Date: 2000-Aug-11 12:13 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- Date: 2000-Aug-11 12:14 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101146&group_id=5470 From noreply@sourceforge.net Fri Aug 11 21:36:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 13:36:52 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200008112036.NAA22939@bush.i.sourceforge.net> Patch #101162 has been updated. Project: Category: None Status: Open Summary: a Python/C API testing framework (simple simple) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Fri Aug 11 21:37:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 13:37:15 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200008112037.NAA23048@bush.i.sourceforge.net> Patch #101162 has been updated. Project: Category: None Status: Open Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Fri Aug 11 21:42:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 13:42:40 -0700 Subject: [Patches] [Patch #101146] Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Message-ID: <200008112042.NAA23238@bush.i.sourceforge.net> Patch #101146 has been updated. Project: Category: core (C code) Status: Open Summary: Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Follow-Ups: Date: 2000-Aug-10 13:59 By: twouters Comment: Remove the UNPACK_TUPLE and UNPACK_LIST opcodes in favor of a single UNPACK_SEQUENCE opcode, since both the implementation and the generation of the UNPACK opcodes are identical. ------------------------------------------------------- Date: 2000-Aug-11 02:51 By: nowonder Comment: Looks fine on visual inspection and works for me, too. Someone else should review this, too. ------------------------------------------------------- Date: 2000-Aug-11 12:13 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- Date: 2000-Aug-11 12:14 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- Date: 2000-Aug-11 13:42 By: gvanrossum Comment: Agree with #1 from Tim. Disagree with #2: this would be the first place where 1.6 and 2.0 differ in the bytecode. Suggestion to fix: keep opcode 93 assigned to UNPACK_LIST and keep the case for it in the switch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101146&group_id=5470 From noreply@sourceforge.net Fri Aug 11 21:48:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 13:48:27 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200008112048.NAA23422@bush.i.sourceforge.net> Patch #101162 has been updated. Project: Category: None Status: Open Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Fri Aug 11 22:10:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 14:10:41 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200008112110.OAA07335@delerium.i.sourceforge.net> Patch #101162 has been updated. Project: Category: None Status: Open Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Fri Aug 11 22:11:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 14:11:23 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200008112111.OAA07367@delerium.i.sourceforge.net> Patch #101162 has been updated. Project: Category: None Status: Open Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Fri Aug 11 22:44:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 14:44:36 -0700 Subject: [Patches] [Patch #101146] Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Message-ID: <200008112144.OAA08618@delerium.i.sourceforge.net> Patch #101146 has been updated. Project: Category: core (C code) Status: Open Summary: Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Follow-Ups: Date: 2000-Aug-10 13:59 By: twouters Comment: Remove the UNPACK_TUPLE and UNPACK_LIST opcodes in favor of a single UNPACK_SEQUENCE opcode, since both the implementation and the generation of the UNPACK opcodes are identical. ------------------------------------------------------- Date: 2000-Aug-11 02:51 By: nowonder Comment: Looks fine on visual inspection and works for me, too. Someone else should review this, too. ------------------------------------------------------- Date: 2000-Aug-11 12:13 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- Date: 2000-Aug-11 12:14 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- Date: 2000-Aug-11 13:42 By: gvanrossum Comment: Agree with #1 from Tim. Disagree with #2: this would be the first place where 1.6 and 2.0 differ in the bytecode. Suggestion to fix: keep opcode 93 assigned to UNPACK_LIST and keep the case for it in the switch. ------------------------------------------------------- Date: 2000-Aug-11 14:44 By: twouters Comment: I'm not sure how to interpret this bytecode compatibility argument. The current CVS tree already has a different bytecode magic than has Python 1.5.2, so the normal interpreter refuses to load the old bytecode. I was forced to download the source to pysol ever since installing the CVS tree, several months ago :-) Is there some way to determine (& use) different-but-compatible bytecodes I missed ? When (and how) is a clean break initiated, then ? A number of other proposed patches (augmented assignment, range literals, 'import as') also change bytecode, and 'import as' might need to remove (or change) a current bytecode as well. I'll upload a version that re-adds UNPACK_LIST (as DEPRECATED_UNPACK_LIST perhaps ?) to the switch later. Or if the patch is otherwise accepted, I'd prefer not to upload it, instead just check it in -- saves me a lot of work :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101146&group_id=5470 From noreply@sourceforge.net Fri Aug 11 22:57:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 14:57:30 -0700 Subject: [Patches] [Patch #101146] Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Message-ID: <200008112157.OAA25821@bush.i.sourceforge.net> Patch #101146 has been updated. Project: Category: core (C code) Status: Accepted Summary: Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Follow-Ups: Date: 2000-Aug-10 13:59 By: twouters Comment: Remove the UNPACK_TUPLE and UNPACK_LIST opcodes in favor of a single UNPACK_SEQUENCE opcode, since both the implementation and the generation of the UNPACK opcodes are identical. ------------------------------------------------------- Date: 2000-Aug-11 02:51 By: nowonder Comment: Looks fine on visual inspection and works for me, too. Someone else should review this, too. ------------------------------------------------------- Date: 2000-Aug-11 12:13 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- Date: 2000-Aug-11 12:14 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- Date: 2000-Aug-11 13:42 By: gvanrossum Comment: Agree with #1 from Tim. Disagree with #2: this would be the first place where 1.6 and 2.0 differ in the bytecode. Suggestion to fix: keep opcode 93 assigned to UNPACK_LIST and keep the case for it in the switch. ------------------------------------------------------- Date: 2000-Aug-11 14:44 By: twouters Comment: I'm not sure how to interpret this bytecode compatibility argument. The current CVS tree already has a different bytecode magic than has Python 1.5.2, so the normal interpreter refuses to load the old bytecode. I was forced to download the source to pysol ever since installing the CVS tree, several months ago :-) Is there some way to determine (& use) different-but-compatible bytecodes I missed ? When (and how) is a clean break initiated, then ? A number of other proposed patches (augmented assignment, range literals, 'import as') also change bytecode, and 'import as' might need to remove (or change) a current bytecode as well. I'll upload a version that re-adds UNPACK_LIST (as DEPRECATED_UNPACK_LIST perhaps ?) to the switch later. Or if the patch is otherwise accepted, I'd prefer not to upload it, instead just check it in -- saves me a lot of work :-) ------------------------------------------------------- Date: 2000-Aug-11 14:57 By: gvanrossum Comment: OK, I forgot all the other new bytecodes. Never mind. Check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101146&group_id=5470 From noreply@sourceforge.net Fri Aug 11 23:04:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 15:04:07 -0700 Subject: [Patches] [Patch #101135] 'import x as y' and 'from x import y as z' Message-ID: <200008112204.PAA26048@bush.i.sourceforge.net> Patch #101135 has been updated. Project: Category: core (C code) Status: Open Summary: 'import x as y' and 'from x import y as z' Follow-Ups: Date: 2000-Aug-09 13:23 By: twouters Comment: This patch adds the oft-proposed 'import as' syntax, to both 'import module' and 'from module import ...', but without making 'as' a reserved word (by using the technique Tim Peters proposed on python-dev.) 'import spam as egg' is a very simple patch to compile.c, which doesn't need changes to the VM, but 'from spam import dog as meat' needs a new bytecode, which this patch calls 'FROM_IMPORT_AS'. The bytecode loads an object from a module onto the stack, so a STORE_NAME can store it later. This can't be done by the normal FROM_IMPORT opcode, because it needs to take the special case of '*' into account. Also, because it uses 'STORE_NAME', it's now possible to mix 'import' and 'global', like so: global X from foo import X as X The patch still generates the old code for from foo import X (without 'as') mostly to save on bytecode size, and for the 'compatibility' with mixing 'global' and 'from .. import'... I'm not sure what's the best thing to do. The patch doesn't include a test suite or documentation, yet. ------------------------------------------------------- Date: 2000-Aug-11 15:04 By: twouters Comment: I now think the best thing to do is to split the 'IMPORT_FROM' opcode into two opcodes: 'IMPORT_ALL', which is used for 'from module import *', and 'IMPORT_FROM' (or another name, if that's desired) which loads a single name. IMPORT_ALL would store the retrieved objects into the local namespace directly, like IMPORT_FROM currently does; it doesn't use the stack other than to retrieve the module it loads the symbols from. IMPORT_FROM would act more like 'IMPORT_NAME', in that the object retrieved from the module is not stored directly in the local namespace, but instead pushed on the stack (that's what the IMPORT_FROM_AS bytecode in the current patch does) -- that means that for all normal 'from' imports, a STORE is generated, and a 'global' works on them just like with normal variable assignment. In the current patch, this is only true for 'from module import x as y' statements, not for the normal form. Assigned to Guido, since it's ultimately his decision (everyone else already voted ;-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470 From noreply@sourceforge.net Fri Aug 11 23:16:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 15:16:49 -0700 Subject: [Patches] [Patch #101146] Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Message-ID: <200008112216.PAA26440@bush.i.sourceforge.net> Patch #101146 has been updated. Project: Category: core (C code) Status: Closed Summary: Replace UNPACK_TUPLE and UNPACK_LIST with UNPACK_SEQUENCE Follow-Ups: Date: 2000-Aug-10 13:59 By: twouters Comment: Remove the UNPACK_TUPLE and UNPACK_LIST opcodes in favor of a single UNPACK_SEQUENCE opcode, since both the implementation and the generation of the UNPACK opcodes are identical. ------------------------------------------------------- Date: 2000-Aug-11 02:51 By: nowonder Comment: Looks fine on visual inspection and works for me, too. Someone else should review this, too. ------------------------------------------------------- Date: 2000-Aug-11 12:13 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- Date: 2000-Aug-11 12:14 By: tim_one Comment: Assigned to Guido for Final Pronouncement: looks fine to me too. Implications: 1. You're not going to want to reintroduce a distinction between unpacking tuples and lists someday. 2. The 2.0 PVM has no chance of running .pyc/.pyo from earlier versions. ------------------------------------------------------- Date: 2000-Aug-11 13:42 By: gvanrossum Comment: Agree with #1 from Tim. Disagree with #2: this would be the first place where 1.6 and 2.0 differ in the bytecode. Suggestion to fix: keep opcode 93 assigned to UNPACK_LIST and keep the case for it in the switch. ------------------------------------------------------- Date: 2000-Aug-11 14:44 By: twouters Comment: I'm not sure how to interpret this bytecode compatibility argument. The current CVS tree already has a different bytecode magic than has Python 1.5.2, so the normal interpreter refuses to load the old bytecode. I was forced to download the source to pysol ever since installing the CVS tree, several months ago :-) Is there some way to determine (& use) different-but-compatible bytecodes I missed ? When (and how) is a clean break initiated, then ? A number of other proposed patches (augmented assignment, range literals, 'import as') also change bytecode, and 'import as' might need to remove (or change) a current bytecode as well. I'll upload a version that re-adds UNPACK_LIST (as DEPRECATED_UNPACK_LIST perhaps ?) to the switch later. Or if the patch is otherwise accepted, I'd prefer not to upload it, instead just check it in -- saves me a lot of work :-) ------------------------------------------------------- Date: 2000-Aug-11 14:57 By: gvanrossum Comment: OK, I forgot all the other new bytecodes. Never mind. Check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101146&group_id=5470 From noreply@sourceforge.net Fri Aug 11 23:26:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 15:26:51 -0700 Subject: [Patches] [Patch #101141] Make 'Grammar' when necessary Message-ID: <200008112226.PAA10119@delerium.i.sourceforge.net> Patch #101141 has been updated. Project: Category: Build Status: Closed Summary: Make 'Grammar' when necessary Follow-Ups: Date: 2000-Aug-10 07:25 By: twouters Comment: Add Grammar to the subdirectories to recursively 'make', to solve Peter's problem of trying out a patch that touches Grammar and not typing 'make' in 'Grammar' by hand ;-) ------------------------------------------------------- Date: 2000-Aug-10 09:16 By: twouters Comment: oops, this is the order I meant to put the directories in. ------------------------------------------------------- Date: 2000-Aug-11 01:40 By: nowonder Comment: Although I am NOT feeling morally equivalent to Guido, I changed the status to 'Accepted'. The change is trivial and should not pose any problems. waiting-to-be-struck-by-lightning-ly y'rs Peter ------------------------------------------------------- Date: 2000-Aug-11 15:26 By: twouters Comment: Guido did approve of the idea, in private email, and the implementation is fairly trivial. I'll accept the acception, and check it in ;) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101141&group_id=5470 From noreply@sourceforge.net Sat Aug 12 02:33:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 18:33:10 -0700 Subject: [Patches] [Patch #101167] remove tabs in Tools/compiler Message-ID: <200008120133.SAA15839@delerium.i.sourceforge.net> Patch #101167 has been updated. Project: Category: demos and tools Status: Open Summary: remove tabs in Tools/compiler ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101167&group_id=5470 From noreply@sourceforge.net Sat Aug 12 02:35:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 18:35:00 -0700 Subject: [Patches] [Patch #100654] list comprehensions in Python (for 2.0) Message-ID: <200008120135.SAA00460@bush.i.sourceforge.net> Patch #100654 has been updated. Project: Category: core (C code) Status: Accepted Summary: list comprehensions in Python (for 2.0) Follow-Ups: Date: 2000-Jun-28 07:07 By: gvanrossum Comment: This one's for Tim to thaw later. ------------------------------------------------------- Date: 2000-Jul-09 15:45 By: twouters Comment: The new patch is a CVS diff, which makes it kind of hard to apply (it'll only apply with the right GNU patch, with 'POSIXLY_CORRECT' defined, and with the moon in the right phase, which it currently isn't, apparently ;) POSIXLY_CORRECT also has some other effects, like that patch refuses to create new files :P Can I ask for a normal recursive-diff so I can recreate the range-list-literal patch relative to this one ? ------------------------------------------------------- Date: 2000-Jul-24 06:15 By: montanaro Comment: This new patch is simply an update to keep up with the recent ANSIfication of the Python source... ------------------------------------------------------- Date: 2000-Jul-27 13:08 By: gvanrossum Comment: I actually like this a lot (am running with it myself!), but the patch needs to be reworked so that it requires [(x,x) for x in ...] instead of allowing [x,x for x in ...]. It also may require integration with the range literals syntax, but that should be relatively minor. ------------------------------------------------------- Date: 2000-Jul-27 13:29 By: montanaro Comment: Okay, the grammar stuff is a little bit beyond me and I don't have the time to investigate it fully at the moment. *** Perhaps someone can give me a little direction... *** ------------------------------------------------------- Date: 2000-Jul-28 00:12 By: ping Comment: I'm pretty sure i know how to do this (just replace the list-making clause of the "atom:" production with: '[' [test [list_iter | ',' testlist]] ']' then update com_list_constructor and the LSQB clause of com_atom appropriately), but i still much prefer a style that uses a separator -- if not between clauses, then at least between the expression and the conditions. My favourite: [x*2, for x in spam, if x > 3] The separator after the expression can be comma, semicolon, or omitted; the separator between conditions can be any of these as well as colon. (Greg's original patch chooses "nothing-nothing"; i choose "comma-comma".) The results of Greg Wilson's survey may also be useful. Once a decision is made, it should be easy to adjust the grammar for any of these twelve possibilities. So all we need is a Pronouncement. :) ------------------------------------------------------- Date: 2000-Aug-09 06:17 By: montanaro Comment: (I submitted an update last night, but it appears not to have "taken". Is that because I'm changing the status from "rejected" to "open".) This is a corrected patch from Ka-Ping Yee that adds the parens requirement for tuples in the leading expression, e.g.: [(x,x**2) for x in range(5)] instead of Greg Ewing's original syntax which allowed [x,x**2 for x in range(5)] ------------------------------------------------------- Date: 2000-Aug-11 18:35 By: gvanrossum Comment: Go for it! (This must be unique -- the PEP still hasn't been finished, and the code is already accepted. :-) Note: some changes will be necessary again to implement range literals! But that's now up to the range literals patch... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470 From noreply@sourceforge.net Sat Aug 12 02:35:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 18:35:29 -0700 Subject: [Patches] [Patch #101168] make Tools/compiler use new UNPACK_SEQUNCE op Message-ID: <200008120135.SAA15870@delerium.i.sourceforge.net> Patch #101168 has been updated. Project: Category: demos and tools Status: Open Summary: make Tools/compiler use new UNPACK_SEQUNCE op ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101168&group_id=5470 From noreply@sourceforge.net Sat Aug 12 04:36:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 20:36:41 -0700 Subject: [Patches] [Patch #101063] TeX-draft for docs of the new string methods Message-ID: <200008120336.UAA04073@bush.i.sourceforge.net> Patch #101063 has been updated. Project: Category: documentation Status: Closed Summary: TeX-draft for docs of the new string methods Follow-Ups: Date: 2000-Aug-11 20:36 By: fdrake Comment: Accepted with small revisions and markup consistency fixes. Doc/lib/libstdtypes.tex revision 1.29. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101063&group_id=5470 From noreply@sourceforge.net Sat Aug 12 09:37:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 01:37:02 -0700 Subject: [Patches] [Patch #101170] Prevent old extensions from crashing Message-ID: <200008120837.BAA27565@delerium.i.sourceforge.net> Patch #101170 has been updated. Project: Category: Windows Status: Open Summary: Prevent old extensions from crashing ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101170&group_id=5470 From noreply@sourceforge.net Sat Aug 12 10:37:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 02:37:51 -0700 Subject: [Patches] [Patch #100654] list comprehensions in Python (for 2.0) Message-ID: <200008120937.CAA13495@bush.i.sourceforge.net> Patch #100654 has been updated. Project: Category: core (C code) Status: Accepted Summary: list comprehensions in Python (for 2.0) Follow-Ups: Date: 2000-Jun-28 07:07 By: gvanrossum Comment: This one's for Tim to thaw later. ------------------------------------------------------- Date: 2000-Jul-09 15:45 By: twouters Comment: The new patch is a CVS diff, which makes it kind of hard to apply (it'll only apply with the right GNU patch, with 'POSIXLY_CORRECT' defined, and with the moon in the right phase, which it currently isn't, apparently ;) POSIXLY_CORRECT also has some other effects, like that patch refuses to create new files :P Can I ask for a normal recursive-diff so I can recreate the range-list-literal patch relative to this one ? ------------------------------------------------------- Date: 2000-Jul-24 06:15 By: montanaro Comment: This new patch is simply an update to keep up with the recent ANSIfication of the Python source... ------------------------------------------------------- Date: 2000-Jul-27 13:08 By: gvanrossum Comment: I actually like this a lot (am running with it myself!), but the patch needs to be reworked so that it requires [(x,x) for x in ...] instead of allowing [x,x for x in ...]. It also may require integration with the range literals syntax, but that should be relatively minor. ------------------------------------------------------- Date: 2000-Jul-27 13:29 By: montanaro Comment: Okay, the grammar stuff is a little bit beyond me and I don't have the time to investigate it fully at the moment. *** Perhaps someone can give me a little direction... *** ------------------------------------------------------- Date: 2000-Jul-28 00:12 By: ping Comment: I'm pretty sure i know how to do this (just replace the list-making clause of the "atom:" production with: '[' [test [list_iter | ',' testlist]] ']' then update com_list_constructor and the LSQB clause of com_atom appropriately), but i still much prefer a style that uses a separator -- if not between clauses, then at least between the expression and the conditions. My favourite: [x*2, for x in spam, if x > 3] The separator after the expression can be comma, semicolon, or omitted; the separator between conditions can be any of these as well as colon. (Greg's original patch chooses "nothing-nothing"; i choose "comma-comma".) The results of Greg Wilson's survey may also be useful. Once a decision is made, it should be easy to adjust the grammar for any of these twelve possibilities. So all we need is a Pronouncement. :) ------------------------------------------------------- Date: 2000-Aug-09 06:17 By: montanaro Comment: (I submitted an update last night, but it appears not to have "taken". Is that because I'm changing the status from "rejected" to "open".) This is a corrected patch from Ka-Ping Yee that adds the parens requirement for tuples in the leading expression, e.g.: [(x,x**2) for x in range(5)] instead of Greg Ewing's original syntax which allowed [x,x**2 for x in range(5)] ------------------------------------------------------- Date: 2000-Aug-11 18:35 By: gvanrossum Comment: Go for it! (This must be unique -- the PEP still hasn't been finished, and the code is already accepted. :-) Note: some changes will be necessary again to implement range literals! But that's now up to the range literals patch... ------------------------------------------------------- Date: 2000-Aug-12 02:37 By: twouters Comment: Adjusting range literals to fit is not a problem. However, is this implementation really accepted ? I find the way it generates code, well, scary. Almost appalling :) It creates a new list (as a new local variable, with a numeric name), loads the list's append method, and calls the append method for each iteration of the listcomp. Is that really the best way to do it ? IIRC, Greg proposed a new bytecode that reaches down X items on the stack, which should be a list, and append to it the X-1 items above it. This requires a new opcode, but is more efficient, and cleans up some of the mess the current patch requires. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470 From guido@beopen.com Sat Aug 12 16:45:30 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 12 Aug 2000 10:45:30 -0500 Subject: [Patches] [Patch #100654] list comprehensions in Python (for 2.0) In-Reply-To: Your message of "Sat, 12 Aug 2000 02:37:51 MST." <200008120937.CAA13495@bush.i.sourceforge.net> References: <200008120937.CAA13495@bush.i.sourceforge.net> Message-ID: <200008121545.KAA06142@cj20424-a.reston1.va.home.com> > Date: 2000-Aug-12 02:37 > By: twouters > > Comment: > Adjusting range literals to fit is not a problem. However, is this > implementation really accepted ? I find the way it generates code, > well, scary. Almost appalling :) It creates a new list (as a new > local variable, with a numeric name), loads the list's append > method, and calls the append method for each iteration of the > listcomp. Is that really the best way to do it ? > > IIRC, Greg proposed a new bytecode that reaches down X items on the > stack, which should be a list, and append to it the X-1 items above > it. This requires a new opcode, but is more efficient, and cleans up > some of the mess the current patch requires. Hm. The problem that Greg works around with a temporary name seems to be that the for loop uses two items of its own on the stack, so the list is at least three deep. Let's look at this example: [x for x in seq] I suggest the following stack layout: [L, L.append, seq, i] where L is the anonymous list we're building, and i is the internal for loop index. The FOR_LOOP opcode, when 'seq' is not exhausted, changes this to: [L, L.append, seq, i+1, seq[i]] This is then stored in the local variable x, and the stack is once again: [L, L.append, seq, i+1] Now we evaluate the expression to the left of the 'for'. This loads x in our example: [L, L.append, seq, i+1, x] Now we want to call L.append(x). I think this would work: ROT_FOUR [L, seq, i+1, x, L.append] DUP [L, seq, i+1, x, L.append, L.append] ROT_THREE [L, seq, i+1, L.append, L.append, x] CALL [L, seq, i+1, L.append] ROT_THREE [L, i+1, L.append, seq] ROT_THREE [L, L.append, seq, i+1] and we can jump back to the top of the loop. Note that I may have taken some liberties with the actual opcodes (possibly the ROT opcodes go the other way around?). I can see why Greg introduced a temporary variable name: ROT_FOUR didn't exist, and this all gets a lot more complicated when you have nested loops! I don't see how your interpretation of the opcode would work. The required stack size must be known at compile time, so the VM doesn't have to do dynamically check for stack overflow. (Long ago, it did check dynamically, because the code generator didn't keep track of how much stack it needed; doing away with the dynamic check was a major speed-up.) So you can't just generate all the list elements and then create a list out of them at once, because you don't know how big the list will be. Maybe Greg meant an opcode that appends the top of the stack to a list N deep? That would work, as long as the code generator can keep track of how many nested for loops there are. In the mean time, I think the current trick is fine. Note that the list's append method is stored as the temp name, not the list itself. This saves a getattr each time. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From thomas@xs4all.net Sat Aug 12 16:14:17 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 12 Aug 2000 17:14:17 +0200 Subject: [Patches] [Patch #100654] list comprehensions in Python (for 2.0) In-Reply-To: <200008121545.KAA06142@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sat, Aug 12, 2000 at 10:45:30AM -0500 References: <200008120937.CAA13495@bush.i.sourceforge.net> <200008121545.KAA06142@cj20424-a.reston1.va.home.com> Message-ID: <20000812171417.F14470@xs4all.nl> On Sat, Aug 12, 2000 at 10:45:30AM -0500, Guido van Rossum wrote: > Now we evaluate the expression to the left of the 'for'. This loads > x in our example: > > [L, L.append, seq, i+1, x] > > Now we want to call L.append(x). I think this would work: > > ROT_FOUR [L, seq, i+1, x, L.append] > DUP [L, seq, i+1, x, L.append, L.append] > ROT_THREE [L, seq, i+1, L.append, L.append, x] > CALL [L, seq, i+1, L.append] > ROT_THREE [L, i+1, L.append, seq] > ROT_THREE [L, L.append, seq, i+1] > > and we can jump back to the top of the loop. > > Note that I may have taken some liberties with the actual opcodes > (possibly the ROT opcodes go the other way around?). No, you got it right. ROT_THREE and the ROT_FOUR the augmented assignment patch creates, take the bottom-most object in their effective range, and place it on the top of the stack, pushing the rest down. However, your idea won't fly, because there can be more than one loop in the listcomprehension! What would the stack look like with, say, this: [(x, y*z, z*2) for x in S1 for y in S2 for z in S3 if z < x < y] Something like this: [L, L.append, S1, i1, S2, i2, S3, i3] Which would require a 'ROT_ARBITRARY' or such. That's why Greg proposed that 'reach-down-X-items-and-append-this-object-to-the-list-there' opcode. > I don't see how your interpretation of the opcode would work. The > required stack size must be known at compile time, so the VM doesn't > have to do dynamically check for stack overflow. (Long ago, it did > check dynamically, because the code generator didn't keep track of how > much stack it needed; doing away with the dynamic check was a major > speed-up.) So you can't just generate all the list elements and then > create a list out of them at once, because you don't know how big the > list will be. Yah, after some breakfast (and more importantly, caffeine) I see that I remembered it wrong ;) It was a 'reach down and append TOP()' opcode, not 'append top X-1 objects'. > In the mean time, I think the current trick is fine. Note that the > list's append method is stored as the temp name, not the list itself. > This saves a getattr each time. Alright, I wasn't raising any fundamental objections. And I made the mistake of basing my doubts on an old copy of the patch (downloaded it on one machine, examined the file with the same name on another machine. ;-S) The old patch also had 2-space indentations and stored the list rather than the append method, etc, which really made me wonder if you read the patch before accepting it. I take back my reservations :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Sat Aug 12 17:54:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 09:54:47 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008121654.JAA07921@delerium.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Open Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 05:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 18:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 02:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 16:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 07:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-27 22:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 14:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- Date: 2000-Aug-08 22:26 By: tim_one Comment: Changed status to Rejected, but left assigned to me (I'll Open it again when it's updated). As I said at the bottom of my last comment on this, you cannot assume sizeof(short)==2: please get rid of the new big-endian/little-endian trickery. The code is not portable as-is. Even on machines where sizeof(short) does equal 2, shorts in the opcode stream are not guaranteed to be naturally aligned, and trying to access them as if they were can lead to anything from a core dump to an expensive trap to the OS to fix up the unaligned read. And on the only machines where this gimmick could actually pay (a little-endian machine where sizeof(short)==2 *and* the HW doesn't penalize unnatural alignment), the compiler should be smart enough to optimize the old expression for us. ------------------------------------------------------- Date: 2000-Aug-09 04:36 By: gvanrossum Comment: I think that all Tim wants is that you undo the changes you made to the NEXTARG() macro. ------------------------------------------------------- Date: 2000-Aug-10 14:51 By: cgw Comment: Understood. I've now put the NEXTARG macro back to its original form; sorry for overlooking this on the previous pass. ------------------------------------------------------- Date: 2000-Aug-10 21:25 By: tim_one Comment: Changed to Open and assigned to Vladimir. Vlad, have any comments on this? Care to test it? I'm inclined to accept it now "by eyeball", because it does fix some bugs. ------------------------------------------------------- Date: 2000-Aug-12 09:54 By: marangoz Comment: Yes, comments: there are things I like and others I don't really like. The tactics here is to remove the 2-byte integral type limit and replace it with sizeof(int). On some systems, sizeof(int) == 8, so I don't see a reason for generating only one EXTENDED_ARG opcode if the arg exceeds 2 bytes. If the arg exceeds 4 bytes, let the code generate more 2-byte arg slices, i.e. several EXTENDED_ARG in a row. Costs nothing. Overall, we both converged on the same solution. Things I like: - the fix in node.h (short -> int) - the error check in com_backpatch Things I don't really like: - the removal of E_OVERFLOW and associated checks I'd suggest using int types in node.h (instead of unsigned int) and change the existing short checks with int checks (with INT_MAX) - the label "extended_arg" in ceval.c. (after the oparg fetch) It should be really be named "dispatch_opcode". I'd suggest integrating the com_oparg & ceval's case EXTENDED_ARG code that I've posted to python-dev and adjust the rest accordingly. http://www.python.org/pipermail/python-dev/2000-August/014604.html Overall, it looks okay. I'll test it when the things I don't really like are gone. (the Python code seems to be somewhat more complex than it should be, though...) Can we get another patch from the author? Otherwise I'll try to make some time to relay this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Sat Aug 12 18:49:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 10:49:29 -0700 Subject: [Patches] [Patch #100654] list comprehensions in Python (for 2.0) Message-ID: <200008121749.KAA26247@bush.i.sourceforge.net> Patch #100654 has been updated. Project: Category: core (C code) Status: Accepted Summary: list comprehensions in Python (for 2.0) Follow-Ups: Date: 2000-Jun-28 07:07 By: gvanrossum Comment: This one's for Tim to thaw later. ------------------------------------------------------- Date: 2000-Jul-09 15:45 By: twouters Comment: The new patch is a CVS diff, which makes it kind of hard to apply (it'll only apply with the right GNU patch, with 'POSIXLY_CORRECT' defined, and with the moon in the right phase, which it currently isn't, apparently ;) POSIXLY_CORRECT also has some other effects, like that patch refuses to create new files :P Can I ask for a normal recursive-diff so I can recreate the range-list-literal patch relative to this one ? ------------------------------------------------------- Date: 2000-Jul-24 06:15 By: montanaro Comment: This new patch is simply an update to keep up with the recent ANSIfication of the Python source... ------------------------------------------------------- Date: 2000-Jul-27 13:08 By: gvanrossum Comment: I actually like this a lot (am running with it myself!), but the patch needs to be reworked so that it requires [(x,x) for x in ...] instead of allowing [x,x for x in ...]. It also may require integration with the range literals syntax, but that should be relatively minor. ------------------------------------------------------- Date: 2000-Jul-27 13:29 By: montanaro Comment: Okay, the grammar stuff is a little bit beyond me and I don't have the time to investigate it fully at the moment. *** Perhaps someone can give me a little direction... *** ------------------------------------------------------- Date: 2000-Jul-28 00:12 By: ping Comment: I'm pretty sure i know how to do this (just replace the list-making clause of the "atom:" production with: '[' [test [list_iter | ',' testlist]] ']' then update com_list_constructor and the LSQB clause of com_atom appropriately), but i still much prefer a style that uses a separator -- if not between clauses, then at least between the expression and the conditions. My favourite: [x*2, for x in spam, if x > 3] The separator after the expression can be comma, semicolon, or omitted; the separator between conditions can be any of these as well as colon. (Greg's original patch chooses "nothing-nothing"; i choose "comma-comma".) The results of Greg Wilson's survey may also be useful. Once a decision is made, it should be easy to adjust the grammar for any of these twelve possibilities. So all we need is a Pronouncement. :) ------------------------------------------------------- Date: 2000-Aug-09 06:17 By: montanaro Comment: (I submitted an update last night, but it appears not to have "taken". Is that because I'm changing the status from "rejected" to "open".) This is a corrected patch from Ka-Ping Yee that adds the parens requirement for tuples in the leading expression, e.g.: [(x,x**2) for x in range(5)] instead of Greg Ewing's original syntax which allowed [x,x**2 for x in range(5)] ------------------------------------------------------- Date: 2000-Aug-11 18:35 By: gvanrossum Comment: Go for it! (This must be unique -- the PEP still hasn't been finished, and the code is already accepted. :-) Note: some changes will be necessary again to implement range literals! But that's now up to the range literals patch... ------------------------------------------------------- Date: 2000-Aug-12 02:37 By: twouters Comment: Adjusting range literals to fit is not a problem. However, is this implementation really accepted ? I find the way it generates code, well, scary. Almost appalling :) It creates a new list (as a new local variable, with a numeric name), loads the list's append method, and calls the append method for each iteration of the listcomp. Is that really the best way to do it ? IIRC, Greg proposed a new bytecode that reaches down X items on the stack, which should be a list, and append to it the X-1 items above it. This requires a new opcode, but is more efficient, and cleans up some of the mess the current patch requires. ------------------------------------------------------- Date: 2000-Aug-12 10:49 By: montanaro Comment: I don't think that's a problem. It's no worse than the code generated for a loop written by a user to do the same thing. If it turns out that a more efficient code generation scheme can be developed, that can wait. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470 From noreply@sourceforge.net Sat Aug 12 20:03:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 12:03:05 -0700 Subject: [Patches] [Patch #101145] co_flags fix for classes generated by Tools/compile.py Message-ID: <200008121903.MAA28534@bush.i.sourceforge.net> Patch #101145 has been updated. Project: Category: demos and tools Status: Closed Summary: co_flags fix for classes generated by Tools/compile.py Follow-Ups: Date: 2000-Aug-10 11:29 By: nascheme Comment: With this patch the compiler can repeatedly compile itself, even with Python 1.5.2. Without it classes do not get their own __dict__s and things go badly wrong. ------------------------------------------------------- Date: 2000-Aug-12 12:03 By: twouters Comment: Accepted & applied (checking in in a minute.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101145&group_id=5470 From noreply@sourceforge.net Sat Aug 12 20:07:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 12:07:24 -0700 Subject: [Patches] [Patch #101167] remove tabs in Tools/compiler Message-ID: <200008121907.MAA28674@bush.i.sourceforge.net> Patch #101167 has been updated. Project: Category: demos and tools Status: Closed Summary: remove tabs in Tools/compiler Follow-Ups: Date: 2000-Aug-12 12:07 By: twouters Comment: Accepted & applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101167&group_id=5470 From noreply@sourceforge.net Sat Aug 12 20:27:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 12:27:16 -0700 Subject: [Patches] [Patch #101168] make Tools/compiler use new UNPACK_SEQUNCE op Message-ID: <200008121927.MAA12645@delerium.i.sourceforge.net> Patch #101168 has been updated. Project: Category: demos and tools Status: Closed Summary: make Tools/compiler use new UNPACK_SEQUNCE op Follow-Ups: Date: 2000-Aug-11 18:36 By: nascheme Comment: Apply the whitespace patch before this one. ------------------------------------------------------- Date: 2000-Aug-12 12:27 By: twouters Comment: Added, plus I updated the MAGIC. Also kept the unpackTuple method working, in case anyone external to compile.py uses it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101168&group_id=5470 From noreply@sourceforge.net Sat Aug 12 21:31:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 13:31:09 -0700 Subject: [Patches] [Patch #101104] Optional object mem allocator Message-ID: <200008122031.NAA14659@delerium.i.sourceforge.net> Patch #101104 has been updated. Project: Category: core (C code) Status: Postponed Summary: Optional object mem allocator Follow-Ups: Date: 2000-Aug-06 21:05 By: marangoz Comment: A stab on obmalloc.c -- an optional object allocator. A configure "--with(out)-pymalloc" option is introduced for enabling specialized mallocs. Off by default. The code is included conditionally at the end of object.c obmalloc.c contains only the core malloc functionality. No profiling, nor debugging are there -- these would come as separate (and optional) modules: memprof.c & memdebug.c in the Modules/ directory and will exploit the hooks of the allocator. I've managed to draw a rather nice diagram in the comments at the top of obmalloc.c explaining what this stuff is all about. Look there. ------------------------------------------------------- Date: 2000-Aug-07 06:30 By: twouters Comment: Small nit: you shouldn't edit config.h.in yourself, it's autogenerated from acconfig.h and configure.in (with 'autoheader', part of 'autoconf.) You should define WITH_PYMALLOC in acconfig.h, not config.h.in, and run 'autoheader' and 'autoconf' to generate a new 'configure'. I'm in the process of testing this patch on Linux and BSDI, by the way :) ------------------------------------------------------- Date: 2000-Aug-07 09:19 By: marangoz Comment: Thanks. Fixed (acconfig.h) ------------------------------------------------------- Date: 2000-Aug-12 13:31 By: marangoz Comment: Status set to Postponed. Although promising, this hasn't enjoyed much user testing for the 2.0 time frame (partly because of the lack of an introspective Python interface which can't be completed in time according to the release schedule). Assigned to marangoz who's responsible to reopen it again in due time (except if BDFL decides otherwise). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101104&group_id=5470 From noreply@sourceforge.net Sat Aug 12 21:43:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 13:43:54 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200008122043.NAA31717@bush.i.sourceforge.net> Patch #101162 has been updated. Project: Category: None Status: Open Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Sat Aug 12 21:46:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 13:46:51 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200008122046.NAA31741@bush.i.sourceforge.net> Patch #101162 has been updated. Project: Category: Build Status: Open Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Sun Aug 13 03:41:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 19:41:22 -0700 Subject: [Patches] [Patch #101172] Fix for typo in pymem.h Message-ID: <200008130241.TAA25685@delerium.i.sourceforge.net> Patch #101172 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for typo in pymem.h ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101172&group_id=5470 From noreply@sourceforge.net Sun Aug 13 05:13:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Aug 2000 21:13:02 -0700 Subject: [Patches] [Patch #100852] Add poll() to select module Message-ID: <200008130413.VAA12555@bush.i.sourceforge.net> Patch #100852 has been updated. Project: Category: None Status: Open Summary: Add poll() to select module Follow-Ups: Date: 2000-Jul-11 04:25 By: akuchling Comment: Derived from Sam Rushing's pollmodule.c that forms part of Medusa. Once I get a second opinion about the patch, I'll check it in. ------------------------------------------------------- Date: 2000-Jul-21 06:33 By: akuchling Comment: Updated version of the patch, which adds poll() to the select module. .register() and .unregister() add/remove fds, and .poll() performs the system call. Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored. Open question: should there be a function or attribute to get the list of registered fds? Still to do: write documentation, add the test case. ------------------------------------------------------- Date: 2000-Jul-24 17:54 By: akuchling Comment: Assigned to Jeremy for review; feel free to bounce it to someone else. ------------------------------------------------------- Date: 2000-Jul-25 10:25 By: akuchling Comment: Update patch to latest version, which adds poll() to the select() module. ------------------------------------------------------- Date: 2000-Jul-25 13:30 By: jhylton Comment: Several style nits changed, mostly to do with whitespace. Substantive changes: 1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens 2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND One more Open Issue: I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions: - interface to register many fds at once - keep the list of fds in sorted order - use a dict to store fds and generate fdarry lazily - keep track of allocated length and used length for ufds, so that fewer reallocs are required Each of these suggestions has some added complexity, so I'm not sure that I like any of them. ------------------------------------------------------- Date: 2000-Jul-25 13:41 By: akuchling Comment: I wondered about the linear search, too; it means balancing efficiency versus the lines of code to write this one object? IMHO implementing both #1 and #3 would be good; allow passing an arbitrary # of fds to register (and unregister?), store them in a dict, and then lazily generate the ufd array when needed. Or is there some built-in more suited than a dict for this? Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors. ------------------------------------------------------- Date: 2000-Jul-25 14:40 By: jhylton Comment: I think a dict is the right data structure, but I don't think it should be exposed directly. If it is not exposed, then the ufd array need only be generated for poll calls after a register or unregister. If there are multiple polls without a change, the same array can be re-used. ------------------------------------------------------- Date: 2000-Aug-12 21:13 By: akuchling Comment: Latest version, which stores an underlying dict as suggested in jhylton's previous comment. p.unregister() raises KeyError if you unregister a fd that wasn't registered in the first place; seem reasonable? It does to me... The code should now be completed; the only remaining task is to write docstrings and finish the documentation patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 From noreply@sourceforge.net Sun Aug 13 09:33:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 01:33:54 -0700 Subject: [Patches] [Patch #101064] [Moshe] Fixing bug 110832 -- urlparse.urljoin Message-ID: <200008130833.BAA03354@delerium.i.sourceforge.net> Patch #101064 has been updated. Project: Category: Modules Status: Open Summary: [Moshe] Fixing bug 110832 -- urlparse.urljoin Follow-Ups: Date: 2000-Aug-03 12:06 By: twouters Comment: Moshe's patch to fix bug #110832. ------------------------------------------------------- Date: 2000-Aug-13 01:33 By: moshez Comment: Jeremy, I'm not sure what the right thing *is* -- but this patch certainly solves the bug. So, either the bug is false (so throw the bug and this patch away), or the bug is legit, in which case, please eyeball+test and check in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101064&group_id=5470 From noreply@sourceforge.net Sun Aug 13 12:59:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 04:59:56 -0700 Subject: [Patches] [Patch #101172] Fix for typo in pymem.h Message-ID: <200008131159.EAA28143@bush.i.sourceforge.net> Patch #101172 has been updated. Project: Category: core (C code) Status: Closed Summary: Fix for typo in pymem.h Follow-Ups: Date: 2000-Aug-13 04:59 By: marangoz Comment: Thanks. Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101172&group_id=5470 From noreply@sourceforge.net Sun Aug 13 17:44:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 09:44:20 -0700 Subject: [Patches] [Patch #101173] Adding gettext Message-ID: <200008131644.JAA19778@delerium.i.sourceforge.net> Patch #101173 has been updated. Project: Category: library Status: Open Summary: Adding gettext ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101173&group_id=5470 From noreply@sourceforge.net Sun Aug 13 18:45:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 10:45:31 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008131745.KAA05966@bush.i.sourceforge.net> Patch #100902 has been updated. Project: Category: None Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Sun Aug 13 18:45:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 10:45:58 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008131745.KAA05974@bush.i.sourceforge.net> Patch #100902 has been updated. Project: Category: None Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Sun Aug 13 19:49:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 11:49:53 -0700 Subject: [Patches] [Patch #101175] Fix slight bug in the Ref manual docs on listcomprehensions Message-ID: <200008131849.LAA23542@delerium.i.sourceforge.net> Patch #101175 has been updated. Project: Category: documentation Status: Open Summary: Fix slight bug in the Ref manual docs on listcomprehensions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101175&group_id=5470 From noreply@sourceforge.net Sun Aug 13 19:53:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 11:53:35 -0700 Subject: [Patches] [Patch #101175] Fix slight bug in the Ref manual docs on listcomprehensions Message-ID: <200008131853.LAA23694@delerium.i.sourceforge.net> Patch #101175 has been updated. Project: Category: documentation Status: Open Summary: Fix slight bug in the Ref manual docs on listcomprehensions Follow-Ups: Date: 2000-Aug-13 11:53 By: twouters Comment: This patch updates the reference manual documentation on list comprehensions to the fact that the first expression in a listcomprehension is a single expression, not a list (that is, if it's a tuple, it needs the parentheses.) I'm not sure in what style the reference manual should be written; should it be as close to CPythons' Grammar/Grammar file as possible, or should it forgo the elaborate tricks that are sometimes necessary to work around the LL(1) parser's limitations ? The range-literals patch to the reference manual gets a lot more 'low-level', as a result of sticking close to the CPYthon grammar file. Should I keep it that way ? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101175&group_id=5470 From noreply@sourceforge.net Sun Aug 13 20:25:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 12:25:04 -0700 Subject: [Patches] [Patch #101176] add dummy 'add2lib' target to Grammar/Makefile Message-ID: <200008131925.MAA24657@delerium.i.sourceforge.net> Patch #101176 has been updated. Project: Category: Build Status: Open Summary: add dummy 'add2lib' target to Grammar/Makefile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101176&group_id=5470 From noreply@sourceforge.net Sun Aug 13 20:28:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 12:28:06 -0700 Subject: [Patches] [Patch #101176] add dummy 'add2lib' target to Grammar/Makefile Message-ID: <200008131928.MAA24832@delerium.i.sourceforge.net> Patch #101176 has been updated. Project: Category: Build Status: Open Summary: add dummy 'add2lib' target to Grammar/Makefile Follow-Ups: Date: 2000-Aug-13 12:28 By: tmick Comment: On the UNIX build, the master makefile makes the 'add2lib' target in each subdir. This now includes Grammar, which currently has no 'add2lib' target. gmake reports: make VERSION=2.0 add2lib make[1]: Entering directory `/home/trentm/tmp/python.perliumdiff/python/dist/src/Grammar' make[1]: *** No rule to make target `add2lib'. Stop. make[1]: Leaving directory `/home/trentm/tmp/python.perliumdiff/python/dist/src/Grammar' and keeps going. Some other makes (e.g. the make on Monterey, other Unices?) just die. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101176&group_id=5470 From thomas@xs4all.net Sun Aug 13 22:12:06 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 13 Aug 2000 23:12:06 +0200 Subject: [Patches] [Patch #101176] add dummy 'add2lib' target to Grammar/Makefile In-Reply-To: <200008131928.MAA24832@delerium.i.sourceforge.net>; from noreply@sourceforge.net on Sun, Aug 13, 2000 at 12:28:06PM -0700 References: <200008131928.MAA24832@delerium.i.sourceforge.net> Message-ID: <20000813231206.N14470@xs4all.nl> On Sun, Aug 13, 2000 at 12:28:06PM -0700, noreply@sourceforge.net wrote: > Summary: add dummy 'add2lib' target to Grammar/Makefile > Comment: > On the UNIX build, the master makefile makes the 'add2lib' target in each > subdir. This now includes Grammar, which currently has no 'add2lib' > target. gmake reports: > make VERSION=2.0 add2lib > make[1]: Entering directory > `/home/trentm/tmp/python.perliumdiff/python/dist/src/Grammar' > make[1]: *** No rule to make target `add2lib'. Stop. > make[1]: Leaving directory > `/home/trentm/tmp/python.perliumdiff/python/dist/src/Grammar' > and keeps going. Some other makes (e.g. the make on Monterey, other Unices?) just die. I don't think this needs a patch on SF, if it's really just a dummy make rule. Just check it in. I would, if i wasn't experiencing 50% packetloss at the moment :P If it's more elaborate than a dummy value, well, don't ;) But I can't check it right now :P (Damned Cisco routers :P I'm typing this entire mail without seeing if i'm doing it right... Excuse my typos ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From trentm@ActiveState.com Sun Aug 13 22:18:39 2000 From: trentm@ActiveState.com (Trent Mick) Date: Sun, 13 Aug 2000 14:18:39 -0700 Subject: [Patches] [Patch #101176] add dummy 'add2lib' target to Grammar/Makefile In-Reply-To: <20000813231206.N14470@xs4all.nl>; from thomas@xs4all.net on Sun, Aug 13, 2000 at 11:12:06PM +0200 References: <200008131928.MAA24832@delerium.i.sourceforge.net> <20000813231206.N14470@xs4all.nl> Message-ID: <20000813141839.B24062@ActiveState.com> On Sun, Aug 13, 2000 at 11:12:06PM +0200, Thomas Wouters wrote: > I don't think this needs a patch on SF, if it's really just a dummy make > rule. Just check it in. I would, if i wasn't experiencing 50% packetloss at > the moment :P If it's more elaborate than a dummy value, well, don't ;) But > I can't check it right now :P For all I know it might be more appropriate to remove Grammar/ from the list of dirs on which the 'add2lib' target is called. Don't know anything about the 'add2lib' target so thought I would run it passed Guido. Trent -- Trent Mick TrentM@ActiveState.com From success@tfnisp.com Sun Aug 13 21:51:51 2000 From: success@tfnisp.com (Success Mountain) Date: Sun, 13 Aug 2000 20:51:51 Subject: [Patches] Your Boat has arrived! Message-ID: <20000814003751.C94A21CFE6@dinsdale.python.org> Thousands of people around the country have found Financial Relief by building their very own Home Based Business right out of their living rooms without spending a dime. The Company is called The Free Network and they are giving people across the country their very own businesses for FREE!! That's right for FREE!! There is no catch. No commitments. The Free Network understands that life today is not easy. They also know that many people want their own businesses but lack the resources to do so. They have solved the problem for you. All you need to do is take advantage of it. You can own your own Internet Company, Paging Company, Long Distance Company, Wireless Company or your own Virtuall Mall, ALL FOR FREE!! You are invited to review an opportunity that is changing the pace of online business...and it's FREE! How would you like to get paid every time someone visits your online mall and makes a purchase...and we'll give you your own online mall for FREE! View an online presentation now! http://dev.www.earnware.com/createweb/buzz/ To find out more information or to speak to a live person email your name and number and we will get back to you. At the Free Network, We want you to succeed! Our reputation is on the line. Visit our Website and take a look for yourself. http://www.thefreenetwork.com/summit Remember, this offer is FREE! Please accept our deepest apologies, if you received this email unsolicited, and you can be removed automatically below. *********** All REMOVE requests AUTOMATICALLY honored upon receipt. mailto:sszewczuk@tfnmail.com/?subject=REMOVE From noreply@sourceforge.net Mon Aug 14 03:17:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 19:17:01 -0700 Subject: [Patches] [Patch #101178] add items() method to listobject Message-ID: <200008140217.TAA22420@bush.i.sourceforge.net> Patch #101178 has been updated. Project: Category: None Status: Open Summary: add items() method to listobject ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101178&group_id=5470 From noreply@sourceforge.net Mon Aug 14 03:23:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 19:23:09 -0700 Subject: [Patches] [Patch #101178] add items() method to listobject Message-ID: <200008140223.TAA22572@bush.i.sourceforge.net> Patch #101178 has been updated. Project: Category: core (C code) Status: Open Summary: add items() method to listobject Follow-Ups: Date: 2000-Aug-13 19:23 By: nowonder Comment: This patch adds a .items() method to the list object. .items() returns a list with of tuples. E.g.: for index, value in ["a", "b", "c"].items(): print index, ":", value will print: 0: a 1: b 2: c I think this is an easy way to achieve looping over index AND elements in parallel. Semantically the following two expressions should be equivalent: for index, value in zip(range(len(mylist)), mylist): for index, value in mylist.items(): In opposition to patch #110138 I would call this: "Adding syntactic sugar without adding syntax (or sugar):" ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101178&group_id=5470 From noreply@sourceforge.net Mon Aug 14 03:32:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 19:32:45 -0700 Subject: [Patches] [Patch #101138] 'for i indexing a in l': exposing the for-loop counter Message-ID: <200008140232.TAA22852@bush.i.sourceforge.net> Patch #101138 has been updated. Project: Category: core (C code) Status: Open Summary: 'for i indexing a in l': exposing the for-loop counter Follow-Ups: Date: 2000-Aug-09 15:10 By: twouters Comment: This patch adds a way to get the loop counter in Python for-loops. The syntax is one Just quoted on python-dev today, which he attributes to Tim (and was probably proposed by half the thinking Python community by now ;) It's a quick and dirty hack, but it works. There might be refcounting bugs and much more efficient ways to do it, but it works ;) It also lacks a test case and documentation. ------------------------------------------------------- Date: 2000-Aug-11 00:27 By: hooft Comment: Do we need a new keyword for this functionality, or can we use zip? Maybe adding zip-magic would help, but: >>> a=['a','b','c','d'] >>> for i,el in zip(xrange(9999999),a): ... print i,el ... 0 a 1 b 2 c 3 d ------------------------------------------------------- Date: 2000-Aug-11 00:33 By: hooft Comment: Or: >>> class indexing: ... def __init__(self,a): ... self.data=a ... def __getitem__(self,i): ... return i,self.data[i] ... >>> for i,el in indexing(a): ... print i,el ... 0 a 1 b 2 c 3 d >>> ------------------------------------------------------- Date: 2000-Aug-11 00:38 By: twouters Comment: The patch exposes the already-present loop counter to python code, rather than just adding a list of ranges to loop over. That is one of the reasons to make it a syntactic change: other techniques to use the builtin loop counter would require psychic interpreters ;) The patch does *not* introduce a new keyword, by the way. the 'indexing' name is just a NAME, not a real keyword, and can be used as a variable just fine. ------------------------------------------------------- Date: 2000-Aug-13 19:32 By: nowonder Comment: I think that using the builtin loop counter would be nice. But I don't see this justifying extra syntax. Paul Prescod's suggestion of adding .items() to lists seems more natural to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101138&group_id=5470 From noreply@sourceforge.net Mon Aug 14 03:36:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 19:36:02 -0700 Subject: [Patches] [Patch #101178] add items() method to listobject Message-ID: <200008140236.TAA22988@bush.i.sourceforge.net> Patch #101178 has been updated. Project: Category: core (C code) Status: Open Summary: add items() method to listobject Follow-Ups: Date: 2000-Aug-13 19:23 By: nowonder Comment: This patch adds a .items() method to the list object. .items() returns a list with of tuples. E.g.: for index, value in ["a", "b", "c"].items(): print index, ":", value will print: 0: a 1: b 2: c I think this is an easy way to achieve looping over index AND elements in parallel. Semantically the following two expressions should be equivalent: for index, value in zip(range(len(mylist)), mylist): for index, value in mylist.items(): In opposition to patch #110138 I would call this: "Adding syntactic sugar without adding syntax (or sugar):" ------------------------------------------------------- Date: 2000-Aug-13 19:36 By: nowonder Comment: just two comments: strings (and maybe tuples) could also support .items(). There could be a function PySequence_Items in abstract.c. BTW: test case and documentation lacking. If this is considered to be a Good Idea(tm), I'll happily supply them. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101178&group_id=5470 From noreply@sourceforge.net Mon Aug 14 03:49:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 19:49:57 -0700 Subject: [Patches] [Patch #100927] Fix for broken gethostbyname("0") Message-ID: <200008140249.TAA23413@bush.i.sourceforge.net> Patch #100927 has been updated. Project: Category: Modules Status: Open Summary: Fix for broken gethostbyname("0") Follow-Ups: Date: 2000-Jul-19 01:46 By: effbot Comment: why should this work? why is "gethostbyname" broken if it doesn't support "0" and "-1"? if it's important to support these values, shouldn't they be passed to the function as integers, not as strings? etc. (sorry, I'm usually able to make some kind of sense out of patches, but this one was a bit too cryptic ;-) ------------------------------------------------------- Date: 2000-Jul-20 23:13 By: ppessi Comment: It is not important to support "-1". "0" is INADDR_ANY in dot notation - same as "0.0.0.0" or "0.0.0" or "0.0". gethostbyname() should understand dot notation as well as domain names. For some reason, Windows gethostbyname() does not support "0" (obviously I'm a lazy typer, since I have not noticed that it does not support 0.0 nor 0.0.0 nor 0.0.0.0) unlike Unix platforms. I'll supply another patch ACN. ------------------------------------------------------- Date: 2000-Aug-13 19:49 By: nowonder Comment: As linux supports "0" (as well as "0.0" and friends), this would be nice to reduce platform dependency. But "00" is just as valid (not sure what Windows does with it), so to check this I think a bit more work has to be done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100927&group_id=5470 From noreply@sourceforge.net Mon Aug 14 04:15:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 20:15:43 -0700 Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display Message-ID: <200008140315.UAA24202@bush.i.sourceforge.net> Patch #100947 has been updated. Project: Category: library Status: Open Summary: increase control and default size of pdb traceback display Follow-Ups: Date: 2000-Aug-13 20:15 By: nowonder Comment: There is a detailed description in the patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470 From noreply@sourceforge.net Mon Aug 14 06:05:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 22:05:02 -0700 Subject: [Patches] [Patch #101032] os.popen#.close() exit code under Windows enhancement Message-ID: <200008140505.WAA27896@bush.i.sourceforge.net> Patch #101032 has been updated. Project: Category: core (C code) Status: Closed Summary: os.popen#.close() exit code under Windows enhancement Follow-Ups: Date: 2000-Jul-31 16:57 By: db3l Comment: This is an enhancement to a prior patch (100941) originally supplied to add exit code processing to the win32pipe-based routines included in posixmodule.c. Based on the need for the higher order (os.popen# where # >=2) functions to close handles in different orders, and on discussion in c.l.py, this patch removes the risk of deadlock waiting for the child previously present in certain cases. It adds tracking of all file handles returned from an os.popen* call and only waits for the child process, returning the exit code, on the closure of the final file handle to that child. It also touches the w9xpopen.c file in order to properly bubble up exit codes under Windows 95/98 to permit these changes to work on those platforms as well. The patch is rooted in the dist/src directory. ------------------------------------------------------- Date: 2000-Aug-13 22:05 By: mhammond Comment: Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101032&group_id=5470 From noreply@sourceforge.net Mon Aug 14 15:50:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 07:50:18 -0700 Subject: [Patches] [Patch #100654] list comprehensions in Python (for 2.0) Message-ID: <200008141450.HAA31261@delerium.i.sourceforge.net> Patch #100654 has been updated. Project: Category: core (C code) Status: Closed Summary: list comprehensions in Python (for 2.0) Follow-Ups: Date: 2000-Jun-28 07:07 By: gvanrossum Comment: This one's for Tim to thaw later. ------------------------------------------------------- Date: 2000-Jul-09 15:45 By: twouters Comment: The new patch is a CVS diff, which makes it kind of hard to apply (it'll only apply with the right GNU patch, with 'POSIXLY_CORRECT' defined, and with the moon in the right phase, which it currently isn't, apparently ;) POSIXLY_CORRECT also has some other effects, like that patch refuses to create new files :P Can I ask for a normal recursive-diff so I can recreate the range-list-literal patch relative to this one ? ------------------------------------------------------- Date: 2000-Jul-24 06:15 By: montanaro Comment: This new patch is simply an update to keep up with the recent ANSIfication of the Python source... ------------------------------------------------------- Date: 2000-Jul-27 13:08 By: gvanrossum Comment: I actually like this a lot (am running with it myself!), but the patch needs to be reworked so that it requires [(x,x) for x in ...] instead of allowing [x,x for x in ...]. It also may require integration with the range literals syntax, but that should be relatively minor. ------------------------------------------------------- Date: 2000-Jul-27 13:29 By: montanaro Comment: Okay, the grammar stuff is a little bit beyond me and I don't have the time to investigate it fully at the moment. *** Perhaps someone can give me a little direction... *** ------------------------------------------------------- Date: 2000-Jul-28 00:12 By: ping Comment: I'm pretty sure i know how to do this (just replace the list-making clause of the "atom:" production with: '[' [test [list_iter | ',' testlist]] ']' then update com_list_constructor and the LSQB clause of com_atom appropriately), but i still much prefer a style that uses a separator -- if not between clauses, then at least between the expression and the conditions. My favourite: [x*2, for x in spam, if x > 3] The separator after the expression can be comma, semicolon, or omitted; the separator between conditions can be any of these as well as colon. (Greg's original patch chooses "nothing-nothing"; i choose "comma-comma".) The results of Greg Wilson's survey may also be useful. Once a decision is made, it should be easy to adjust the grammar for any of these twelve possibilities. So all we need is a Pronouncement. :) ------------------------------------------------------- Date: 2000-Aug-09 06:17 By: montanaro Comment: (I submitted an update last night, but it appears not to have "taken". Is that because I'm changing the status from "rejected" to "open".) This is a corrected patch from Ka-Ping Yee that adds the parens requirement for tuples in the leading expression, e.g.: [(x,x**2) for x in range(5)] instead of Greg Ewing's original syntax which allowed [x,x**2 for x in range(5)] ------------------------------------------------------- Date: 2000-Aug-11 18:35 By: gvanrossum Comment: Go for it! (This must be unique -- the PEP still hasn't been finished, and the code is already accepted. :-) Note: some changes will be necessary again to implement range literals! But that's now up to the range literals patch... ------------------------------------------------------- Date: 2000-Aug-12 02:37 By: twouters Comment: Adjusting range literals to fit is not a problem. However, is this implementation really accepted ? I find the way it generates code, well, scary. Almost appalling :) It creates a new list (as a new local variable, with a numeric name), loads the list's append method, and calls the append method for each iteration of the listcomp. Is that really the best way to do it ? IIRC, Greg proposed a new bytecode that reaches down X items on the stack, which should be a list, and append to it the X-1 items above it. This requires a new opcode, but is more efficient, and cleans up some of the mess the current patch requires. ------------------------------------------------------- Date: 2000-Aug-12 10:49 By: montanaro Comment: I don't think that's a problem. It's no worse than the code generated for a loop written by a user to do the same thing. If it turns out that a more efficient code generation scheme can be developed, that can wait. ------------------------------------------------------- Date: 2000-Aug-12 12:23 By: none Comment: The updated patch i submitted included the following changes: 1. More explanation of listcomps in the docs. 2. Modified test cases to use [(x, y) for ...]. 3. Added a test case to ensure [x, y for ...] is a SyntaxError. 4. Cleaned up grammar by adding a "listmaker" rule. 5. Temporary local name is now "__1__" instead of "1". 6. Look up "append" once, outside the loop, instead of inside. The optimization in #6, which is one of the things you were worried about, produces a noticeable speedup (up to 20% on very long lists). Skip, i updated my tree & it looks like not all the patch got checked in. Did you check in Doc/tut/tut.tex also? ------------------------------------------------------- Date: 2000-Aug-14 07:50 By: montanaro Comment: what update patch you submitted? who are you? your comment is attributed to none. if you have a new patch for list comprehensions, please make it relative to the current cvs tree and send it to me (skip@mojam.com). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470 From noreply@sourceforge.net Tue Aug 15 03:46:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 19:46:08 -0700 Subject: [Patches] [Patch #101186] IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Message-ID: <200008150246.TAA24236@delerium.i.sourceforge.net> Patch #101186 has been updated. Project: Category: core (C code) Status: Open Summary: IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101186&group_id=5470 From noreply@sourceforge.net Tue Aug 15 09:46:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 01:46:07 -0700 Subject: [Patches] [Patch #101187] Patch for ftplib to support REST Message-ID: <200008150846.BAA19838@bush.i.sourceforge.net> Patch #101187 has been updated. Project: Category: Modules Status: Open Summary: Patch for ftplib to support REST ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101187&group_id=5470 From noreply@sourceforge.net Tue Aug 15 17:18:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 09:18:31 -0700 Subject: [Patches] [Patch #101186] IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Message-ID: <200008151618.JAA03224@bush.i.sourceforge.net> Patch #101186 has been updated. Project: Category: Modules Status: Open Summary: IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Follow-Ups: Date: 2000-Aug-15 09:18 By: twouters Comment: This looks like PEP material. We actually discussed this briefly on python-dev, but there was noone there that had both the time and the knowledge to persue this. (I looked briefly at the 1.5.2 IPv6 implementation, but it raised too many questions to be added 'just like that', IMHO.) Would anyone from the team that wrote this feel like writing a PEP ? How involved are you in Python ? In absense of a volunteer to write a PEP, would there be a volunteer to explain design decisions ? (Hm, the person who submitted this patch did so anonymously. I'll forward the summary of this patch to core@kame.net) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101186&group_id=5470 From noreply@sourceforge.net Tue Aug 15 17:31:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 09:31:36 -0700 Subject: [Patches] [Patch #101186] IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Message-ID: <200008151631.JAA03623@bush.i.sourceforge.net> Patch #101186 has been updated. Project: Category: Modules Status: Open Summary: IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Follow-Ups: Date: 2000-Aug-15 09:18 By: twouters Comment: This looks like PEP material. We actually discussed this briefly on python-dev, but there was noone there that had both the time and the knowledge to persue this. (I looked briefly at the 1.5.2 IPv6 implementation, but it raised too many questions to be added 'just like that', IMHO.) Would anyone from the team that wrote this feel like writing a PEP ? How involved are you in Python ? In absense of a volunteer to write a PEP, would there be a volunteer to explain design decisions ? (Hm, the person who submitted this patch did so anonymously. I'll forward the summary of this patch to core@kame.net) ------------------------------------------------------- Date: 2000-Aug-15 09:31 By: fdrake Comment: This will not go in Python 1.6. Python 2.0 is also closed for new features, so this should be taken up with Tim & Guido for 2.0. There is no good reason not to include this feature in Python 2.1; but I can't speak for the quality of the patch until I've had time to review it. Perhaps Python developers & testers knowledgable about IPv6 should get in touch with the person this patch is assigned to. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101186&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:29:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:29:50 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008151729.KAA05815@bush.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Open Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 05:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 18:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 02:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 16:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 07:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-27 22:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 14:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- Date: 2000-Aug-08 22:26 By: tim_one Comment: Changed status to Rejected, but left assigned to me (I'll Open it again when it's updated). As I said at the bottom of my last comment on this, you cannot assume sizeof(short)==2: please get rid of the new big-endian/little-endian trickery. The code is not portable as-is. Even on machines where sizeof(short) does equal 2, shorts in the opcode stream are not guaranteed to be naturally aligned, and trying to access them as if they were can lead to anything from a core dump to an expensive trap to the OS to fix up the unaligned read. And on the only machines where this gimmick could actually pay (a little-endian machine where sizeof(short)==2 *and* the HW doesn't penalize unnatural alignment), the compiler should be smart enough to optimize the old expression for us. ------------------------------------------------------- Date: 2000-Aug-09 04:36 By: gvanrossum Comment: I think that all Tim wants is that you undo the changes you made to the NEXTARG() macro. ------------------------------------------------------- Date: 2000-Aug-10 14:51 By: cgw Comment: Understood. I've now put the NEXTARG macro back to its original form; sorry for overlooking this on the previous pass. ------------------------------------------------------- Date: 2000-Aug-10 21:25 By: tim_one Comment: Changed to Open and assigned to Vladimir. Vlad, have any comments on this? Care to test it? I'm inclined to accept it now "by eyeball", because it does fix some bugs. ------------------------------------------------------- Date: 2000-Aug-12 09:54 By: marangoz Comment: Yes, comments: there are things I like and others I don't really like. The tactics here is to remove the 2-byte integral type limit and replace it with sizeof(int). On some systems, sizeof(int) == 8, so I don't see a reason for generating only one EXTENDED_ARG opcode if the arg exceeds 2 bytes. If the arg exceeds 4 bytes, let the code generate more 2-byte arg slices, i.e. several EXTENDED_ARG in a row. Costs nothing. Overall, we both converged on the same solution. Things I like: - the fix in node.h (short -> int) - the error check in com_backpatch Things I don't really like: - the removal of E_OVERFLOW and associated checks I'd suggest using int types in node.h (instead of unsigned int) and change the existing short checks with int checks (with INT_MAX) - the label "extended_arg" in ceval.c. (after the oparg fetch) It should be really be named "dispatch_opcode". I'd suggest integrating the com_oparg & ceval's case EXTENDED_ARG code that I've posted to python-dev and adjust the rest accordingly. http://www.python.org/pipermail/python-dev/2000-August/014604.html Overall, it looks okay. I'll test it when the things I don't really like are gone. (the Python code seems to be somewhat more complex than it should be, though...) Can we get another patch from the author? Otherwise I'll try to make some time to relay this. ------------------------------------------------------- Date: 2000-Aug-15 10:29 By: tim_one Comment: Charles, do you have anything to say to Vladimir's comments? I don't see a need to have an indefinitely-extensible extended opcode gimmick today. What you already did solves real problems now, and indeed the only real problems in this area we've ever seen. I want to get that into 2.0. That doesn't preclude Vlad extending it again later. But I agree that removing the overflow checks was a bad decision. If we ever *do* bump into a case where more than what you've done is needed, Python will silently go insane. So if you can fix that much, I'll accept the patch for 2.0 immediately after. Agree too that "dispatch_opcode" is a clearer name for the label than "extended_arg". ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:31:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:31:07 -0700 Subject: [Patches] [Patch #100835] PC/config.h: support for gnu-win32 and lcc-win32 Message-ID: <200008151731.KAA05845@bush.i.sourceforge.net> Patch #100835 has been updated. Project: Category: None Status: Open Summary: PC/config.h: support for gnu-win32 and lcc-win32 Follow-Ups: Date: 2000-Jul-10 04:43 By: RLiebscher Comment: This patch makes it possible to use gnu-win32 and lcc-win32 (http://www.cs.virginia.edu/~lcc-win32/) compilers to build extension modules. It adds compiler specific sections to PC/config.h . It also extends the Borland compiler section. This has then two parts, one for Win32 and the other one for the rest. The Win32 part should be almost complete. *** This patch is not intended to make it possible to compile Python with these compilers, it is intended to be able to use these compilers to build extension modules. **** ------------------------------------------------------- Date: 2000-Jul-10 04:44 By: RLiebscher Comment: This patch makes it possible to use gnu-win32 and lcc-win32 (http://www.cs.virginia.edu/~lcc-win32/) compilers to build extension modules. It adds compiler specific sections to PC/config.h . It also extends the Borland compiler section. This has then two parts, one for Win32 and the other one for the rest. The Win32 part should be almost complete. *** This patch is not intended to make it possible to compile Python with these compilers, it is intended to be able to use these compilers to build extension modules. **** ------------------------------------------------------- Date: 2000-Jul-13 13:22 By: jhylton Comment: Assigned to Tim because he is handling Windows build issues ------------------------------------------------------- Date: 2000-Aug-10 21:08 By: tim_one Comment: Left open and assigned to Mark Hammond. Mark, you have any objections to this? I have no way to test any of it, and I doubt any of us do. If you don't object to the patch by eyeball either, please Accept it and either check it in or assign it to someone else (I don't have a working "patch" yet!). ------------------------------------------------------- Date: 2000-Aug-15 10:31 By: tim_one Comment: Tickling you as part of 2.0 nagging. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100835&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:33:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:33:40 -0700 Subject: [Patches] [Patch #100837] urllib patch to simplify POST form query Message-ID: <200008151733.KAA06018@bush.i.sourceforge.net> Patch #100837 has been updated. Project: Category: None Status: Open Summary: urllib patch to simplify POST form query Follow-Ups: Date: 2000-Jul-10 05:49 By: VizNut Comment: (SourceForce tossed my comment for the original patch, so here it is.) Current GET form query: filename, headers = urllib.urlretrieve( "%s?%s" % ( BASE_URL, urllib.urlencode( parms ) ), filename ) Desirable POST form query: filename, headers = urllib.urlretrieve( BASE_URL, filename, data=urllib.urlencode( parms ) ) Current POST form query: fp = urllib.urlopen( BASE_URL, urllib.urlencode( parms ) ) tfp = open(filename, 'wb') bs = 1024*8 block = fp.read(bs) while block: tfp.write(block) block = fp.read(bs) tfp.close() fp.close() The latter is required because there is no way to feed the data parameters for the POST query to urlretrieve. The chunked read is necessary because these forms sometimes generate datasets larger than virtual memory (as in this case). ------------------------------------------------------- Date: 2000-Jul-12 07:04 By: moshez Comment: This looks cool! I'm +1 on this. (I haven't tested this patch yet, so I'll need to. From a cursory glance at the implementation it looks quite straightforward) ------------------------------------------------------- Date: 2000-Aug-15 10:33 By: tim_one Comment: Reassigned to Fred because Jeremy's gone. Fred, know anything about this stuff? Review or assign to someone else, please. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100837&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:36:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:36:01 -0700 Subject: [Patches] [Patch #100852] Add poll() to select module Message-ID: <200008151736.KAA06049@bush.i.sourceforge.net> Patch #100852 has been updated. Project: Category: None Status: Open Summary: Add poll() to select module Follow-Ups: Date: 2000-Jul-11 04:25 By: akuchling Comment: Derived from Sam Rushing's pollmodule.c that forms part of Medusa. Once I get a second opinion about the patch, I'll check it in. ------------------------------------------------------- Date: 2000-Jul-21 06:33 By: akuchling Comment: Updated version of the patch, which adds poll() to the select module. .register() and .unregister() add/remove fds, and .poll() performs the system call. Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored. Open question: should there be a function or attribute to get the list of registered fds? Still to do: write documentation, add the test case. ------------------------------------------------------- Date: 2000-Jul-24 17:54 By: akuchling Comment: Assigned to Jeremy for review; feel free to bounce it to someone else. ------------------------------------------------------- Date: 2000-Jul-25 10:25 By: akuchling Comment: Update patch to latest version, which adds poll() to the select() module. ------------------------------------------------------- Date: 2000-Jul-25 13:30 By: jhylton Comment: Several style nits changed, mostly to do with whitespace. Substantive changes: 1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens 2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND One more Open Issue: I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions: - interface to register many fds at once - keep the list of fds in sorted order - use a dict to store fds and generate fdarry lazily - keep track of allocated length and used length for ufds, so that fewer reallocs are required Each of these suggestions has some added complexity, so I'm not sure that I like any of them. ------------------------------------------------------- Date: 2000-Jul-25 13:41 By: akuchling Comment: I wondered about the linear search, too; it means balancing efficiency versus the lines of code to write this one object? IMHO implementing both #1 and #3 would be good; allow passing an arbitrary # of fds to register (and unregister?), store them in a dict, and then lazily generate the ufd array when needed. Or is there some built-in more suited than a dict for this? Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors. ------------------------------------------------------- Date: 2000-Jul-25 14:40 By: jhylton Comment: I think a dict is the right data structure, but I don't think it should be exposed directly. If it is not exposed, then the ufd array need only be generated for poll calls after a register or unregister. If there are multiple polls without a change, the same array can be re-used. ------------------------------------------------------- Date: 2000-Aug-12 21:13 By: akuchling Comment: Latest version, which stores an underlying dict as suggested in jhylton's previous comment. p.unregister() raises KeyError if you unregister a fd that wasn't registered in the first place; seem reasonable? It does to me... The code should now be completed; the only remaining task is to write docstrings and finish the documentation patch. ------------------------------------------------------- Date: 2000-Aug-15 10:36 By: tim_one Comment: Tickling you as part of 2.0 nagging. Please leave a note saying when you intend to "write docstrings and finish the documentation". ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:37:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:37:53 -0700 Subject: [Patches] [Patch #100880] urllib.py patch Message-ID: <200008151737.KAA06086@bush.i.sourceforge.net> Patch #100880 has been updated. Project: Category: None Status: Open Summary: urllib.py patch Follow-Ups: Date: 2000-Jul-13 12:20 By: akuchling Comment: Patch from Paul Schreiber : Patch description ----------------- This addresses four issues: (1) usernames and passwords in urls with special characters are now decoded properly. i.e. http://foo%2C:bar@www.whatever.com/ (2) Basic Auth support has been added to HTTPS, like it was in HTTP. (3) Version 1.92 sent the POSTed data, but did not deal with errors (HTTP responses other than 200) properly. HTTPS now behaves the same way HTTP does. (4) made URL-checking beahve the same way with HTTPS as it does with HTTP (changed == to !=). ------------------------------------------------------- Date: 2000-Aug-15 10:37 By: tim_one Comment: Reassigned to Fred because Jeremy's gone and it's another urllib thingie that's been sitting here over a month. Please review or pass it on. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100880&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:40:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:40:26 -0700 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py Message-ID: <200008151740.KAA06227@bush.i.sourceforge.net> Patch #101151 has been updated. Project: Category: library Status: Open Summary: expose public get_fqdn function in smtplib.py Follow-Ups: Date: 2000-Aug-10 16:32 By: nowonder Comment: expose get_fqdn function rather than calling internal _get_fqdn_hostname function. Only call from helo() and ehlo() if needed. refer from documentation's mentioning of algorithm for fqdn to implementation of get_fqdn. should there be docs for quotedata() and get_fqdn() in libsmtplib.tex? ------------------------------------------------------- Date: 2000-Aug-11 00:58 By: twouters Comment: Looks okay, though perhaps the function should be named 'make_fqdn()' instead of 'get_fqdn' -- you're passing it a name to operate on, after all. That's just a personal preference. I'll let it float for a few days to let someone else knowledgable in the area of SMTP give their opinion on the whole FQDN issue, but as far as I'm concerned, this patch is accepted. Am I the moral equivalent of Guido here ? I have no clue :-) ------------------------------------------------------- Date: 2000-Aug-11 01:33 By: nowonder Comment: as I write in my mail to python-dev, I have found three other occurences of the algorithm. Maybe this should go in some more general place. Where? BTW: I like make_fqdn() better. ------------------------------------------------------- Date: 2000-Aug-15 10:40 By: tim_one Comment: We have to take some action on this for 2.0 -- Accept, Postpone or Reject. I don't know anything about SMTP. If you're not sure you've gotten enough feedback here, bring it up on Python-Dev again. Repeatedly and obnoxiously . ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101151&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:42:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:42:35 -0700 Subject: [Patches] [Patch #100899] a smaller unicode name database Message-ID: <200008151742.KAA06291@bush.i.sourceforge.net> Patch #100899 has been updated. Project: Category: None Status: Open Summary: a smaller unicode name database Follow-Ups: Date: 2000-Jul-15 15:43 By: effbot Comment: duh. it's too large for sourceforge. if you want to play with it, get it from: http://w1.132.telia.com/~u13208596/uninames-patch.txt ------------------------------------------------------- Date: 2000-Aug-03 11:59 By: lemburg Comment: How is the work on this patch coming along ? Will it be ready for 2.0 ? ------------------------------------------------------- Date: 2000-Aug-15 10:42 By: tim_one Comment: /F or MAL, what's going on with this? MAL, did you look at the patch? /F, do you feel it's done? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100899&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:46:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:46:39 -0700 Subject: [Patches] [Patch #101175] Fix slight bug in the Ref manual docs on listcomprehensions Message-ID: <200008151746.KAA06454@bush.i.sourceforge.net> Patch #101175 has been updated. Project: Category: documentation Status: Open Summary: Fix slight bug in the Ref manual docs on listcomprehensions Follow-Ups: Date: 2000-Aug-13 11:53 By: twouters Comment: This patch updates the reference manual documentation on list comprehensions to the fact that the first expression in a listcomprehension is a single expression, not a list (that is, if it's a tuple, it needs the parentheses.) I'm not sure in what style the reference manual should be written; should it be as close to CPythons' Grammar/Grammar file as possible, or should it forgo the elaborate tricks that are sometimes necessary to work around the LL(1) parser's limitations ? The range-literals patch to the reference manual gets a lot more 'low-level', as a result of sticking close to the CPYthon grammar file. Should I keep it that way ? ------------------------------------------------------- Date: 2000-Aug-15 10:46 By: tim_one Comment: Reassigned to Fred, because it's a simple doc change. Fred, accept this and check it in. Note that the grammar has a bug, though, so this will need to be changed again (and so will the implementation). That is, [x if 6] should not be a legal expression but the grammar allows it today. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101175&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:50:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:50:51 -0700 Subject: [Patches] [Patch #100927] Fix for broken gethostbyname("0") Message-ID: <200008151750.KAA06623@bush.i.sourceforge.net> Patch #100927 has been updated. Project: Category: Modules Status: Postponed Summary: Fix for broken gethostbyname("0") Follow-Ups: Date: 2000-Jul-19 01:46 By: effbot Comment: why should this work? why is "gethostbyname" broken if it doesn't support "0" and "-1"? if it's important to support these values, shouldn't they be passed to the function as integers, not as strings? etc. (sorry, I'm usually able to make some kind of sense out of patches, but this one was a bit too cryptic ;-) ------------------------------------------------------- Date: 2000-Jul-20 23:13 By: ppessi Comment: It is not important to support "-1". "0" is INADDR_ANY in dot notation - same as "0.0.0.0" or "0.0.0" or "0.0". gethostbyname() should understand dot notation as well as domain names. For some reason, Windows gethostbyname() does not support "0" (obviously I'm a lazy typer, since I have not noticed that it does not support 0.0 nor 0.0.0 nor 0.0.0.0) unlike Unix platforms. I'll supply another patch ACN. ------------------------------------------------------- Date: 2000-Aug-13 19:49 By: nowonder Comment: As linux supports "0" (as well as "0.0" and friends), this would be nice to reduce platform dependency. But "00" is just as valid (not sure what Windows does with it), so to check this I think a bit more work has to be done. ------------------------------------------------------- Date: 2000-Aug-15 10:50 By: tim_one Comment: Changed status from Open to Postponed. There's been no action on this patch despite comments. If you want it to go into 2.0, address the concerns on Python-Dev Real Quick, and if so I'll Open it again. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100927&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:52:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:52:49 -0700 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <200008151752.KAA06659@bush.i.sourceforge.net> Patch #100938 has been updated. Project: Category: None Status: Open Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2000-Jul-19 14:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 10:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:55:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:55:52 -0700 Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display Message-ID: <200008151755.KAA06808@bush.i.sourceforge.net> Patch #100947 has been updated. Project: Category: library Status: Open Summary: increase control and default size of pdb traceback display Follow-Ups: Date: 2000-Aug-13 20:15 By: nowonder Comment: There is a detailed description in the patch. ------------------------------------------------------- Date: 2000-Aug-15 10:55 By: tim_one Comment: Reassigned to Guido in Jeremy's absence, cuz I never use pdb but know Guido has at least once . Please review or pass on to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:56:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:56:07 -0700 Subject: [Patches] [Patch #101175] Fix slight bug in the Ref manual docs on listcomprehensions Message-ID: <200008151756.KAA06819@bush.i.sourceforge.net> Patch #101175 has been updated. Project: Category: documentation Status: Closed Summary: Fix slight bug in the Ref manual docs on listcomprehensions Follow-Ups: Date: 2000-Aug-13 11:53 By: twouters Comment: This patch updates the reference manual documentation on list comprehensions to the fact that the first expression in a listcomprehension is a single expression, not a list (that is, if it's a tuple, it needs the parentheses.) I'm not sure in what style the reference manual should be written; should it be as close to CPythons' Grammar/Grammar file as possible, or should it forgo the elaborate tricks that are sometimes necessary to work around the LL(1) parser's limitations ? The range-literals patch to the reference manual gets a lot more 'low-level', as a result of sticking close to the CPYthon grammar file. Should I keep it that way ? ------------------------------------------------------- Date: 2000-Aug-15 10:46 By: tim_one Comment: Reassigned to Fred, because it's a simple doc change. Fred, accept this and check it in. Note that the grammar has a bug, though, so this will need to be changed again (and so will the implementation). That is, [x if 6] should not be a legal expression but the grammar allows it today. ------------------------------------------------------- Date: 2000-Aug-15 10:56 By: fdrake Comment: Checked in as ref5.tex revision 1.33. Let's finish up the real Grammar; that needs to be done before I'll be able to update the parser module properly as well. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101175&group_id=5470 From noreply@sourceforge.net Tue Aug 15 18:56:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 10:56:08 -0700 Subject: [Patches] [Patch #101175] Fix slight bug in the Ref manual docs on listcomprehensions Message-ID: <200008151756.KAA06822@bush.i.sourceforge.net> Patch #101175 has been updated. Project: Category: documentation Status: Closed Summary: Fix slight bug in the Ref manual docs on listcomprehensions Follow-Ups: Date: 2000-Aug-13 11:53 By: twouters Comment: This patch updates the reference manual documentation on list comprehensions to the fact that the first expression in a listcomprehension is a single expression, not a list (that is, if it's a tuple, it needs the parentheses.) I'm not sure in what style the reference manual should be written; should it be as close to CPythons' Grammar/Grammar file as possible, or should it forgo the elaborate tricks that are sometimes necessary to work around the LL(1) parser's limitations ? The range-literals patch to the reference manual gets a lot more 'low-level', as a result of sticking close to the CPYthon grammar file. Should I keep it that way ? ------------------------------------------------------- Date: 2000-Aug-15 10:46 By: tim_one Comment: Reassigned to Fred, because it's a simple doc change. Fred, accept this and check it in. Note that the grammar has a bug, though, so this will need to be changed again (and so will the implementation). That is, [x if 6] should not be a legal expression but the grammar allows it today. ------------------------------------------------------- Date: 2000-Aug-15 10:56 By: fdrake Comment: Checked in as ref5.tex revision 1.33. Let's finish up the real Grammar; that needs to be done before I'll be able to update the parser module properly as well. ------------------------------------------------------- Date: 2000-Aug-15 10:56 By: fdrake Comment: Checked in as ref5.tex revision 1.33. Let's finish up the real Grammar; that needs to be done before I'll be able to update the parser module properly as well. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101175&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:00:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:00:36 -0700 Subject: [Patches] [Patch #100970] extended print statement Message-ID: <200008151800.LAA06959@bush.i.sourceforge.net> Patch #100970 has been updated. Project: Category: core (C code) Status: Open Summary: extended print statement Follow-Ups: Date: 2000-Jul-23 19:44 By: bwarsaw Comment: This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout). This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement. An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM. I'm not sure which approach is better. ------------------------------------------------------- Date: 2000-Jul-23 19:45 By: bwarsaw Comment: The following is an example of how you might use the new extended print statement. 
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
------------------------------------------------------- Date: 2000-Aug-15 11:00 By: tim_one Comment: Assigned to Guido for Pronouncement. This was already discussed on Python-Dev. Mix of opinions there. I like it fine. Barry, this needs docs and test cases Real Soon if you want it considered for 2.0. I like the PRINT_TO idea better. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:04:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:04:54 -0700 Subject: [Patches] [Patch #101178] add items() method to listobject Message-ID: <200008151804.LAA07144@bush.i.sourceforge.net> Patch #101178 has been updated. Project: Category: core (C code) Status: Open Summary: add items() method to listobject Follow-Ups: Date: 2000-Aug-13 19:23 By: nowonder Comment: This patch adds a .items() method to the list object. .items() returns a list with of tuples. E.g.: for index, value in ["a", "b", "c"].items(): print index, ":", value will print: 0: a 1: b 2: c I think this is an easy way to achieve looping over index AND elements in parallel. Semantically the following two expressions should be equivalent: for index, value in zip(range(len(mylist)), mylist): for index, value in mylist.items(): In opposition to patch #110138 I would call this: "Adding syntactic sugar without adding syntax (or sugar):" ------------------------------------------------------- Date: 2000-Aug-13 19:36 By: nowonder Comment: just two comments: strings (and maybe tuples) could also support .items(). There could be a function PySequence_Items in abstract.c. BTW: test case and documentation lacking. If this is considered to be a Good Idea(tm), I'll happily supply them. ------------------------------------------------------- Date: 2000-Aug-15 11:04 By: tim_one Comment: Assigned to Guido for Pronouncement. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101178&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:02:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:02:55 -0700 Subject: [Patches] [Patch #101176] add dummy 'add2lib' target to Grammar/Makefile Message-ID: <200008151802.LAA07021@bush.i.sourceforge.net> Patch #101176 has been updated. Project: Category: Build Status: Accepted Summary: add dummy 'add2lib' target to Grammar/Makefile Follow-Ups: Date: 2000-Aug-13 12:28 By: tmick Comment: On the UNIX build, the master makefile makes the 'add2lib' target in each subdir. This now includes Grammar, which currently has no 'add2lib' target. gmake reports: make VERSION=2.0 add2lib make[1]: Entering directory `/home/trentm/tmp/python.perliumdiff/python/dist/src/Grammar' make[1]: *** No rule to make target `add2lib'. Stop. make[1]: Leaving directory `/home/trentm/tmp/python.perliumdiff/python/dist/src/Grammar' and keeps going. Some other makes (e.g. the make on Monterey, other Unices?) just die. ------------------------------------------------------- Date: 2000-Aug-15 11:02 By: tim_one Comment: Accepted and assigned back to Trent for checkin. If it breaks something, tell people to yell at me . ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101176&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:07:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:07:21 -0700 Subject: [Patches] [Patch #100994] Allow JPython to use more tests Message-ID: <200008151807.LAA07190@bush.i.sourceforge.net> Patch #100994 has been updated. Project: Category: library Status: Accepted Summary: Allow JPython to use more tests Follow-Ups: Date: 2000-Jul-27 12:47 By: bckfnn Comment: Several test can almost but not quite be used from JPython. test_b1: JPython does no longer have a strop module. Instead the builtin "time" module is used. test_exceptions.py: In JPython the builtin exception does not have type ClassType but type TypeType. The TypeType is a subclass of ClassType which make the isinstance work for both pythons. test_pkg.py: JPython does not insert __builtins__ in the module namespace. I hope that removing __builtins__ from the output does not devaluate the test. ------------------------------------------------------- Date: 2000-Jul-27 12:52 By: gvanrossum Comment: Note that Lib/test/output/test_pkg must be changed too! Regenerate it by running "regrtest.py -g test_pkh". ------------------------------------------------------- Date: 2000-Aug-15 11:07 By: tim_one Comment: Reassigned to Barry in Jeremy's absence. Barry, note that Guido already Accepted this. If you do too, check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100994&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:09:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:09:30 -0700 Subject: [Patches] [Patch #100837] urllib patch to simplify POST form query Message-ID: <200008151809.LAA07305@bush.i.sourceforge.net> Patch #100837 has been updated. Project: Category: None Status: Open Summary: urllib patch to simplify POST form query Follow-Ups: Date: 2000-Jul-10 05:49 By: VizNut Comment: (SourceForce tossed my comment for the original patch, so here it is.) Current GET form query: filename, headers = urllib.urlretrieve( "%s?%s" % ( BASE_URL, urllib.urlencode( parms ) ), filename ) Desirable POST form query: filename, headers = urllib.urlretrieve( BASE_URL, filename, data=urllib.urlencode( parms ) ) Current POST form query: fp = urllib.urlopen( BASE_URL, urllib.urlencode( parms ) ) tfp = open(filename, 'wb') bs = 1024*8 block = fp.read(bs) while block: tfp.write(block) block = fp.read(bs) tfp.close() fp.close() The latter is required because there is no way to feed the data parameters for the POST query to urlretrieve. The chunked read is necessary because these forms sometimes generate datasets larger than virtual memory (as in this case). ------------------------------------------------------- Date: 2000-Jul-12 07:04 By: moshez Comment: This looks cool! I'm +1 on this. (I haven't tested this patch yet, so I'll need to. From a cursory glance at the implementation it looks quite straightforward) ------------------------------------------------------- Date: 2000-Aug-15 10:33 By: tim_one Comment: Reassigned to Fred because Jeremy's gone. Fred, know anything about this stuff? Review or assign to someone else, please. ------------------------------------------------------- Date: 2000-Aug-15 11:09 By: fdrake Comment: This patch requires documentation; please update to modify Doc/lib/liburllib.tex, or provide specific (unmarked) text in a comment. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100837&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:09:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:09:11 -0700 Subject: [Patches] [Patch #100851] traceback.py, with unicode exceptions Message-ID: <200008151809.LAA07300@bush.i.sourceforge.net> Patch #100851 has been updated. Project: Category: None Status: Accepted Summary: traceback.py, with unicode exceptions Follow-Ups: Date: 2000-Jul-11 03:58 By: htrd Comment: traceback.py can format an exception as a string - but what happens when an exception is raised during the string conversion? In this case it is better to discard the inner exception, to allow the original exception to be reported. The migration to unicode strings makes this quite common. Old code might report a failue with something like.... raise IWasntExpectingThisError('nobody expects %s' % x) An alternative fix is to change __str__ for exceptions to handle the exception. This would be neater, but I chose to follow the example set by PyErr_PrintEx which has a comment: /* If an error happened here, don't show it. XXX This is wrong, but too many callers rely on this behavior. */ ------------------------------------------------------- Date: 2000-Jul-27 13:25 By: gvanrossum Comment: Actually I like this, but instead of the id() of the value you should show its type, e.g. "" % type(value). ------------------------------------------------------- Date: 2000-Aug-01 09:18 By: htrd Comment: Updated patch now formats tracebacks using type(value).__name__ Traceback (most recent call last): File "", line 1, in ? ValueError: ------------------------------------------------------- Date: 2000-Aug-15 11:09 By: tim_one Comment: Guido, if you accepted this and left it assigned to you, check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100851&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:10:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:10:13 -0700 Subject: [Patches] [Patch #100874] Better error message with UnboundLocalError Message-ID: <200008151810.LAA07325@bush.i.sourceforge.net> Patch #100874 has been updated. Project: Category: None Status: Accepted Summary: Better error message with UnboundLocalError Follow-Ups: Date: 2000-Jul-12 21:56 By: tim_one Comment: Rejected and assigned back to Paul. I like the idea fine, the rejection is for style reasons and a repeated security hole. Please make the code look like the rest of ceval.c -- idiosyncracies (that aren't Guido's <0.3 wink>) are harmful in group-maintained code. Examples: > PyObject *nm=NULL; Should be a space on each side of "=". Ditto throughout the patch. BTW, is "nm" meant to be an abbreviation for "name"? If so, please spell out the two extra letters. If it's meant to be an abbreviation for New Mexico, capitalize it . > if(!nm) break; "if" isn't a function call: use a space between "if" and "(". It's also bad to slop "break" on the same line: makes it much harder to set a useful breakpoint here in a debugger. Everywhere else in the code this line would be spelled (if Guido wrote it -- and the "\t" business here is because SF comments don't preserve indentation): \tif (!nm) \t\tbreak > sprintf( buf, "Local variable %s No space between "(" and "buf" here. > PyExc_UnboundLocalError, buf ); No space between "buf" and ")" here. > char buf[500]; > ... followed by an unchecked sprintf into buf. This is a security hole: Python doesn't restrict identifiers to being no longer than 500 chars, so a hacker can easily trick this code into overwriting the buffer bounds. Easy but tedious to fix (e.g., #define the buf length, and use runtime code in conjunction with strncpy to guarantee buf's bounds are respected). ------------------------------------------------------- Date: 2000-Jul-14 14:17 By: prescod Comment: Small helper function format_exc_check_arg makes it easy to generate one string and a argument-type exceptions. It may be overkill in terms of null checking...reviewer can decide. Otherwise, error messages are added to NameErrors and UnboundLocalErrors. That means that all exceptions thrown in ceval have associated error messages. ------------------------------------------------------- Date: 2000-Jul-18 06:32 By: twouters Comment: The helper function is declared 'static', but not defined as such. Rest of the style issues seem solved ;) ------------------------------------------------------- Date: 2000-Jul-25 23:56 By: tim_one Comment: Accepted and assigned back to Paul. Paul, the new format_exc_check_arg function is defined K&R-style, but we've moved to ANSI almost everywhere else in the source. Would be nice if you fix that before checking this in. Else I'll look for it and fix it myself. Sorry for the delay in getting back to this! ------------------------------------------------------- Date: 2000-Aug-15 11:10 By: tim_one Comment: Paul, this was accepted weeks ago. Are you going to check it in? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100874&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:13:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:13:57 -0700 Subject: [Patches] [Patch #100955] ptags, eptags: regex->re, 4 char indent. Message-ID: <200008151813.LAA07502@bush.i.sourceforge.net> Patch #100955 has been updated. Project: Category: None Status: Accepted Summary: ptags, eptags: regex->re, 4 char indent. Follow-Ups: Date: 2000-Jul-22 01:35 By: hooft Comment: This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex. ------------------------------------------------------- Date: 2000-Jul-22 23:44 By: moshez Comment: I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this? ------------------------------------------------------- Date: 2000-Jul-25 13:57 By: gvanrossum Comment: SRE should be faster again, right? The parser module is a very big gun for this simple app -- look at it as an example for text processing (and documentation for TAGS files :-). I say go for it. ------------------------------------------------------- Date: 2000-Jul-26 07:12 By: moshez Comment: Somehow it passed through me, so I added ptags change too. Anyway, Jeremy, Guido is for this. ------------------------------------------------------- Date: 2000-Aug-15 11:12 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-15 11:13 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-15 11:13 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:12:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:12:07 -0700 Subject: [Patches] [Patch #100955] ptags, eptags: regex->re, 4 char indent. Message-ID: <200008151812.LAA07372@bush.i.sourceforge.net> Patch #100955 has been updated. Project: Category: None Status: Accepted Summary: ptags, eptags: regex->re, 4 char indent. Follow-Ups: Date: 2000-Jul-22 01:35 By: hooft Comment: This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex. ------------------------------------------------------- Date: 2000-Jul-22 23:44 By: moshez Comment: I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this? ------------------------------------------------------- Date: 2000-Jul-25 13:57 By: gvanrossum Comment: SRE should be faster again, right? The parser module is a very big gun for this simple app -- look at it as an example for text processing (and documentation for TAGS files :-). I say go for it. ------------------------------------------------------- Date: 2000-Jul-26 07:12 By: moshez Comment: Somehow it passed through me, so I added ptags change too. Anyway, Jeremy, Guido is for this. ------------------------------------------------------- Date: 2000-Aug-15 11:12 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:13:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:13:29 -0700 Subject: [Patches] [Patch #100955] ptags, eptags: regex->re, 4 char indent. Message-ID: <200008151813.LAA07395@bush.i.sourceforge.net> Patch #100955 has been updated. Project: Category: None Status: Accepted Summary: ptags, eptags: regex->re, 4 char indent. Follow-Ups: Date: 2000-Jul-22 01:35 By: hooft Comment: This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex. ------------------------------------------------------- Date: 2000-Jul-22 23:44 By: moshez Comment: I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this? ------------------------------------------------------- Date: 2000-Jul-25 13:57 By: gvanrossum Comment: SRE should be faster again, right? The parser module is a very big gun for this simple app -- look at it as an example for text processing (and documentation for TAGS files :-). I say go for it. ------------------------------------------------------- Date: 2000-Jul-26 07:12 By: moshez Comment: Somehow it passed through me, so I added ptags change too. Anyway, Jeremy, Guido is for this. ------------------------------------------------------- Date: 2000-Aug-15 11:12 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-15 11:13 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:15:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:15:50 -0700 Subject: [Patches] [Patch #100978] Minor updates for BeOS R5 Message-ID: <200008151815.LAA07534@bush.i.sourceforge.net> Patch #100978 has been updated. Project: Category: core (C code) Status: Accepted Summary: Minor updates for BeOS R5 Follow-Ups: Date: 2000-Aug-15 11:15 By: tim_one Comment: Reassigned to Fred in Jeremy's absence. Fred, this was already Accepted. Would please check it in and Close it? I don't have a "patch" that works! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100978&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:49:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:49:00 -0700 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py Message-ID: <200008151849.LAA26752@delerium.i.sourceforge.net> Patch #101151 has been updated. Project: Category: library Status: Accepted Summary: expose public get_fqdn function in smtplib.py Follow-Ups: Date: 2000-Aug-10 16:32 By: nowonder Comment: expose get_fqdn function rather than calling internal _get_fqdn_hostname function. Only call from helo() and ehlo() if needed. refer from documentation's mentioning of algorithm for fqdn to implementation of get_fqdn. should there be docs for quotedata() and get_fqdn() in libsmtplib.tex? ------------------------------------------------------- Date: 2000-Aug-11 00:58 By: twouters Comment: Looks okay, though perhaps the function should be named 'make_fqdn()' instead of 'get_fqdn' -- you're passing it a name to operate on, after all. That's just a personal preference. I'll let it float for a few days to let someone else knowledgable in the area of SMTP give their opinion on the whole FQDN issue, but as far as I'm concerned, this patch is accepted. Am I the moral equivalent of Guido here ? I have no clue :-) ------------------------------------------------------- Date: 2000-Aug-11 01:33 By: nowonder Comment: as I write in my mail to python-dev, I have found three other occurences of the algorithm. Maybe this should go in some more general place. Where? BTW: I like make_fqdn() better. ------------------------------------------------------- Date: 2000-Aug-15 10:40 By: tim_one Comment: We have to take some action on this for 2.0 -- Accept, Postpone or Reject. I don't know anything about SMTP. If you're not sure you've gotten enough feedback here, bring it up on Python-Dev again. Repeatedly and obnoxiously . ------------------------------------------------------- Date: 2000-Aug-15 11:48 By: twouters Comment: I'm accepting this patch, since it's the right thing to do for now. If and when socketmodule is split into a C module and a Python wrapper, we can move the make_fqdn function there, and also remove the duplicate implementations from the other modules. I still think that's a good idea, but I can't deal with it at the moment (and I'm scared of doing it, too, because I donno what it would break :) Accepted modulo the name change (get_fqdn -> make_fqdn) and I'll be checking it in, in a minute. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101151&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:49:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:49:06 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008151849.LAA08763@bush.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:50:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:50:33 -0700 Subject: [Patches] [Patch #101173] Adding gettext Message-ID: <200008151850.LAA08806@bush.i.sourceforge.net> Patch #101173 has been updated. Project: Category: library Status: Open Summary: Adding gettext Follow-Ups: Date: 2000-Aug-15 11:50 By: tim_one Comment: Assigned to Barry cuz he already put himself down in PEP200 as the gettext guy. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101173&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:54:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:54:02 -0700 Subject: [Patches] [Patch #100978] Minor updates for BeOS R5 Message-ID: <200008151854.LAA26991@delerium.i.sourceforge.net> Patch #100978 has been updated. Project: Category: core (C code) Status: Closed Summary: Minor updates for BeOS R5 Follow-Ups: Date: 2000-Aug-15 11:15 By: tim_one Comment: Reassigned to Fred in Jeremy's absence. Fred, this was already Accepted. Would please check it in and Close it? I don't have a "patch" that works! ------------------------------------------------------- Date: 2000-Aug-15 11:54 By: fdrake Comment: Checked in with a change in test.test_fork1: use TestSkipped instead of OSError to indicate that the test was explicitly skipped instead of tried & failed. Corresponding change to BeOS/README. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100978&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:53:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:53:34 -0700 Subject: [Patches] [Patch #100998] experimental support for extended slicing on lists Message-ID: <200008151853.LAA08870@bush.i.sourceforge.net> Patch #100998 has been updated. Project: Category: core (C code) Status: Open Summary: experimental support for extended slicing on lists Follow-Ups: Date: 2000-Jul-27 14:31 By: mwh Comment: this 10 minute hack adds support for "extended slicing" to lists, by which I mean things like: >>> range(100)[23:60:12] [23, 35, 47, 59] todo: find out if this is the approved approach add support for tuples write docs, testsuite (make test passes as is, but should be extended). ------------------------------------------------------- Date: 2000-Jul-27 14:39 By: mwh Comment: c'mon michael! at least get *some* of the boundary cases... ------------------------------------------------------- Date: 2000-Jul-27 23:47 By: mwh Comment: negative indices! for i in listvar[::-1]: pass now iterates over the list backwards (rather than coredumping...) ------------------------------------------------------- Date: 2000-Jul-29 03:36 By: mwh Comment: updated patch to support slice assignements, deletions (needs testing still) ------------------------------------------------------- Date: 2000-Jul-30 11:10 By: mwh Comment: bugfixes (refounting in assignment, logic in deletion) & a few tweaks. ------------------------------------------------------- Date: 2000-Jul-30 11:41 By: mwh Comment: meep! naughty Michael hadn't been running "make test" often enough. this update fixes that. ------------------------------------------------------- Date: 2000-Aug-15 11:53 By: tim_one Comment: Note that without doc and test patches too, and Real Soon, I'll have to Postpone this. Assigned to me to remind me of that. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 From noreply@sourceforge.net Tue Aug 15 19:56:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 11:56:13 -0700 Subject: [Patches] [Patch #101029] Call __getitem__ for slices when no __getslice__ Message-ID: <200008151856.LAA09008@bush.i.sourceforge.net> Patch #101029 has been updated. Project: Category: core (C code) Status: Open Summary: Call __getitem__ for slices when no __getslice__ Follow-Ups: Date: 2000-Jul-31 06:55 By: twouters Comment: Call __getitem__ if no __getslice__ is available. similar for __delslice__ and __setslice__, and for the C API: calls mp_subscript() with a slice object of (start, end, None) if there is no sq_slice(), and the same for sq_ass_slice(). Eventually the reverse should be done, too: call __getslice__ instead of __getitem__ if the object has a __getslice__, and the 3rd argument to the slice is None: That way, we can ditch the 12 silly SLICE* opcodes, and always use slice objects. This *will* result in x[::] being passed to __getslice__ (if available) instead of __getitem__, however, so it is not 100% backwards compatible. This patch is not terribly tested: I'm not feeling well, and I want to post this patch before I head off to home and dive back in bed ;) It doesn't crash, it survives 'make test', it survives manual testing, but it might leak. ------------------------------------------------------- Date: 2000-Jul-31 07:55 By: gvanrossum Comment: Looks cool to me, except that there's a lot of code duplication. Maybe you can add a static helper routine to create a slice out of two ints to abstract.c and one that creates a 1-tuple containing such a slice to classobject.c. (Trying to share code across .c files would require turning it into an official API which I think is overkill.) ------------------------------------------------------- Date: 2000-Jul-31 14:35 By: twouters Comment: New version with less code duplication. Less, not none, unfortunately, because both abstract.c and classobject.c need roughly the same function :P Making the classobject.c one return a 1-tuple is not very useful, because only one place needs a 1-tuple, the other needs a 2-tuple, and I don't fancy modifying the 1-tuple separately. Don't you wish C was more like Python ? *sigh* ------------------------------------------------------- Date: 2000-Aug-15 11:56 By: tim_one Comment: Assigned to Guido because his is the next natural voice in the conversation. Thomas, note that this needs doc and test patches too if it's not to be Postponed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101029&group_id=5470 From fdrake@beopen.com Tue Aug 15 19:58:35 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 15 Aug 2000 14:58:35 -0400 (EDT) Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py In-Reply-To: <200008151849.LAA26752@delerium.i.sourceforge.net> References: <200008151849.LAA26752@delerium.i.sourceforge.net> Message-ID: <14745.37595.507937.752085@cj42289-a.reston1.va.home.com> noreply@sourceforge.net writes: > Patch #101151 has been updated. ... > Date: 2000-Aug-15 11:48 > By: twouters > > Comment: > I'm accepting this patch, since it's the right thing to do for > now. If and when socketmodule is split into a C module and a Python > wrapper, we can move the make_fqdn function there, and also remove > the duplicate implementations from the other modules. I still think > that's a good idea, but I can't deal with it at the moment (and I'm > scared of doing it, too, because I donno what it would break :) > > Accepted modulo the name change (get_fqdn -> make_fqdn) and I'll be > checking it in, in a minute. Is there some reason we don't go ahead and change socket to _socket? As Barry rightly pointed out, that's already how it is for some (popular) platforms. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From noreply@sourceforge.net Tue Aug 15 20:01:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 12:01:44 -0700 Subject: [Patches] [Patch #101055] Cookie.py Message-ID: <200008151901.MAA09212@bush.i.sourceforge.net> Patch #101055 has been updated. Project: Category: library Status: Open Summary: Cookie.py Follow-Ups: Date: 2000-Aug-15 12:01 By: tim_one Comment: Assigned to GregS as he seems to be a Cookie Guy too. Greg, please review this or pass it on. Barry, you realize this needs doc and test patches too else it will just get Postponed? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101055&group_id=5470 From noreply@sourceforge.net Tue Aug 15 20:04:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 12:04:23 -0700 Subject: [Patches] [Patch #101064] [Moshe] Fixing bug 110832 -- urlparse.urljoin Message-ID: <200008151904.MAA09325@bush.i.sourceforge.net> Patch #101064 has been updated. Project: Category: Modules Status: Open Summary: [Moshe] Fixing bug 110832 -- urlparse.urljoin Follow-Ups: Date: 2000-Aug-03 12:06 By: twouters Comment: Moshe's patch to fix bug #110832. ------------------------------------------------------- Date: 2000-Aug-13 01:33 By: moshez Comment: Jeremy, I'm not sure what the right thing *is* -- but this patch certainly solves the bug. So, either the bug is false (so throw the bug and this patch away), or the bug is legit, in which case, please eyeball+test and check in. ------------------------------------------------------- Date: 2000-Aug-15 12:04 By: tim_one Comment: Reassigned to Fred in Jeremy's absence. Fred, I'm being unfair! Sorry about that. I've just been reassigning everything with "url" in the name from Jeremy to you. If you can think of someone better, please be my guest. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101064&group_id=5470 From noreply@sourceforge.net Tue Aug 15 20:05:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 12:05:48 -0700 Subject: [Patches] [Patch #101085] calendar.py extensions Message-ID: <200008151905.MAA09364@bush.i.sourceforge.net> Patch #101085 has been updated. Project: Category: Modules Status: Open Summary: calendar.py extensions Follow-Ups: Date: 2000-Aug-05 18:54 By: goodger Comment: (1) Allows any weekday to start a week, not just Monday as hardcoded. (2) Added functions which return week, month and year calendars as strings (e.g. prmonth() prints, month() returns string), so we aren't forced to play with stdout when we don't want to print. Had to modify some (manditory, therefore non-keyword) parameters in prweek(), prmonth() & prcal()'s signatures. (3) Removed "caching interface to _monthcalendar" as unnecessary complexity. ------------------------------------------------------- Date: 2000-Aug-15 12:05 By: tim_one Comment: Assigned to Skip because he's a Calendar kind of fellow. Please review or pass on to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101085&group_id=5470 From noreply@sourceforge.net Tue Aug 15 20:08:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 12:08:14 -0700 Subject: [Patches] [Patch #101086] libcalendar.tex extensions (untested; don't have TeX) Message-ID: <200008151908.MAA09403@bush.i.sourceforge.net> Patch #101086 has been updated. Project: Category: documentation Status: Open Summary: libcalendar.tex extensions (untested; don't have TeX) Follow-Ups: Date: 2000-Aug-05 18:57 By: goodger Comment: I don't have TeX, and am not fluent, so I hacked the doc code. I haven't tested it and can't guarantee it is without error. I hope it doesn't cause you any trouble. Sorry! ------------------------------------------------------- Date: 2000-Aug-15 12:08 By: tim_one Comment: Assigned to Skip because it appears to be a companion to the calendar.py patch. Skip, if you like the latter patch, I guess this patch should get assigned to Fred next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101086&group_id=5470 From thomas@xs4all.net Tue Aug 15 20:21:53 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 15 Aug 2000 21:21:53 +0200 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py In-Reply-To: <14745.37595.507937.752085@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Aug 15, 2000 at 02:58:35PM -0400 References: <200008151849.LAA26752@delerium.i.sourceforge.net> <14745.37595.507937.752085@cj42289-a.reston1.va.home.com> Message-ID: <20000815212153.C1147@xs4all.nl> On Tue, Aug 15, 2000 at 02:58:35PM -0400, Fred L. Drake, Jr. wrote: > noreply@sourceforge.net writes: > > Patch #101151 has been updated. > ... > > Date: 2000-Aug-15 11:48 > > By: twouters > > > > Comment: > > I'm accepting this patch, since it's the right thing to do for > > now. If and when socketmodule is split into a C module and a Python > > wrapper, we can move the make_fqdn function there, and also remove > > the duplicate implementations from the other modules. I still think > > that's a good idea, but I can't deal with it at the moment (and I'm > > scared of doing it, too, because I donno what it would break :) > > > > Accepted modulo the name change (get_fqdn -> make_fqdn) and I'll be > > checking it in, in a minute. > > Is there some reason we don't go ahead and change socket to _socket? > As Barry rightly pointed out, that's already how it is for some > (popular) platforms. Well, I didn't do it myself (or upload it as a patch, rather) for a very simple reason: I don't know how to do it without breaking stuff :) where would socket.py go, that it would be available to all systems that currently have socketmodule.so (or builtin socketmodule) without interfering with systems that alrady have a socket.py in their own directory. Too much work for me to figure out -> I didn't do it, and won't, until someone tells me to :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Tue Aug 15 20:30:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 12:30:51 -0700 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py Message-ID: <200008151930.MAA10313@bush.i.sourceforge.net> Patch #101151 has been updated. Project: Category: library Status: Closed Summary: expose public get_fqdn function in smtplib.py Follow-Ups: Date: 2000-Aug-10 16:32 By: nowonder Comment: expose get_fqdn function rather than calling internal _get_fqdn_hostname function. Only call from helo() and ehlo() if needed. refer from documentation's mentioning of algorithm for fqdn to implementation of get_fqdn. should there be docs for quotedata() and get_fqdn() in libsmtplib.tex? ------------------------------------------------------- Date: 2000-Aug-11 00:58 By: twouters Comment: Looks okay, though perhaps the function should be named 'make_fqdn()' instead of 'get_fqdn' -- you're passing it a name to operate on, after all. That's just a personal preference. I'll let it float for a few days to let someone else knowledgable in the area of SMTP give their opinion on the whole FQDN issue, but as far as I'm concerned, this patch is accepted. Am I the moral equivalent of Guido here ? I have no clue :-) ------------------------------------------------------- Date: 2000-Aug-11 01:33 By: nowonder Comment: as I write in my mail to python-dev, I have found three other occurences of the algorithm. Maybe this should go in some more general place. Where? BTW: I like make_fqdn() better. ------------------------------------------------------- Date: 2000-Aug-15 10:40 By: tim_one Comment: We have to take some action on this for 2.0 -- Accept, Postpone or Reject. I don't know anything about SMTP. If you're not sure you've gotten enough feedback here, bring it up on Python-Dev again. Repeatedly and obnoxiously . ------------------------------------------------------- Date: 2000-Aug-15 11:48 By: twouters Comment: I'm accepting this patch, since it's the right thing to do for now. If and when socketmodule is split into a C module and a Python wrapper, we can move the make_fqdn function there, and also remove the duplicate implementations from the other modules. I still think that's a good idea, but I can't deal with it at the moment (and I'm scared of doing it, too, because I donno what it would break :) Accepted modulo the name change (get_fqdn -> make_fqdn) and I'll be checking it in, in a minute. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101151&group_id=5470 From nowonder@nowonder.de Tue Aug 15 22:51:14 2000 From: nowonder@nowonder.de (Peter Schneider-Kamp) Date: Tue, 15 Aug 2000 21:51:14 +0000 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py References: <200008151849.LAA26752@delerium.i.sourceforge.net> <14745.37595.507937.752085@cj42289-a.reston1.va.home.com> <20000815212153.C1147@xs4all.nl> Message-ID: <3999BB52.D929E777@nowonder.de> Thomas Wouters wrote: > > On Tue, Aug 15, 2000 at 02:58:35PM -0400, Fred L. Drake, Jr. wrote: > > > Is there some reason we don't go ahead and change socket to _socket? > > As Barry rightly pointed out, that's already how it is for some > > (popular) platforms. > > Well, I didn't do it myself (or upload it as a patch, rather) for a very > simple reason: I don't know how to do it without breaking stuff :) where > would socket.py go, that it would be available to all systems that currently > have socketmodule.so (or builtin socketmodule) without interfering with > systems that alrady have a socket.py in their own directory. Too much work > for me to figure out -> I didn't do it, and won't, until someone tells me to > :-) The same applies for me. If somebody tells me how to do it, I am more than willing to do it. BTW: I'd like to be on patches@python.org - is that possible? Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one@email.msn.com Tue Aug 15 21:09:23 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 15 Aug 2000 16:09:23 -0400 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py In-Reply-To: <3999BB52.D929E777@nowonder.de> Message-ID: [Peter Schneider-Kamp] > BTW: I'd like to be on patches@python.org - is that possible? Sign yourself up, at: http://www.python.org/mailman/listinfo/patches/ From noreply@sourceforge.net Tue Aug 15 21:11:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 13:11:42 -0700 Subject: [Patches] [Patch #101178] add items() method to listobject Message-ID: <200008152011.NAA11923@bush.i.sourceforge.net> Patch #101178 has been updated. Project: Category: core (C code) Status: Open Summary: add items() method to listobject Follow-Ups: Date: 2000-Aug-13 19:23 By: nowonder Comment: This patch adds a .items() method to the list object. .items() returns a list with of tuples. E.g.: for index, value in ["a", "b", "c"].items(): print index, ":", value will print: 0: a 1: b 2: c I think this is an easy way to achieve looping over index AND elements in parallel. Semantically the following two expressions should be equivalent: for index, value in zip(range(len(mylist)), mylist): for index, value in mylist.items(): In opposition to patch #110138 I would call this: "Adding syntactic sugar without adding syntax (or sugar):" ------------------------------------------------------- Date: 2000-Aug-13 19:36 By: nowonder Comment: just two comments: strings (and maybe tuples) could also support .items(). There could be a function PySequence_Items in abstract.c. BTW: test case and documentation lacking. If this is considered to be a Good Idea(tm), I'll happily supply them. ------------------------------------------------------- Date: 2000-Aug-15 11:04 By: tim_one Comment: Assigned to Guido for Pronouncement. ------------------------------------------------------- Date: 2000-Aug-15 13:11 By: nowonder Comment: Note: tim (I believe) said that items() would mean there would have to be key() and value(), too. I disagree. index() and value(), maybe. But key() does not make any sense for a list. I see the issue with execution speed and memory overhead though, so as I am not really opposed to 'for index indexing value in sequence' I would be okay with that. In any case it would be nice to have some way to express this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101178&group_id=5470 From thomas@xs4all.net Tue Aug 15 21:17:22 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 15 Aug 2000 22:17:22 +0200 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py In-Reply-To: <3999BB52.D929E777@nowonder.de>; from nowonder@nowonder.de on Tue, Aug 15, 2000 at 09:51:14PM +0000 References: <200008151849.LAA26752@delerium.i.sourceforge.net> <14745.37595.507937.752085@cj42289-a.reston1.va.home.com> <20000815212153.C1147@xs4all.nl> <3999BB52.D929E777@nowonder.de> Message-ID: <20000815221722.D1147@xs4all.nl> On Tue, Aug 15, 2000 at 09:51:14PM +0000, Peter Schneider-Kamp wrote: > BTW: I'd like to be on patches@python.org - is that possible? It's a Mailman list, so just go to (typing from memory now, typo emptor) http://www.python.org/mailman/listinfo/patches and click on subscribe. Eventually, someone with admin access there will either accept or reject you. I don't see why they would reject you, since you're too far from Reston to join the weekly patches-parties anyway ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Tue Aug 15 21:25:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 13:25:07 -0700 Subject: [Patches] [Patch #101055] Cookie.py Message-ID: <200008152025.NAA30637@delerium.i.sourceforge.net> Patch #101055 has been updated. Project: Category: library Status: Open Summary: Cookie.py Follow-Ups: Date: 2000-Aug-15 12:01 By: tim_one Comment: Assigned to GregS as he seems to be a Cookie Guy too. Greg, please review this or pass it on. Barry, you realize this needs doc and test patches too else it will just get Postponed? ------------------------------------------------------- Date: 2000-Aug-15 13:25 By: bwarsaw Comment: Yes, but we're still waiting on a non-LGPL encumbered version of the file. Last I heard, Andrew had gotten in touch with O'Malley who said he had a BSD covered version, but hadn't given a link yet. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101055&group_id=5470 From akuchlin@mems-exchange.org Tue Aug 15 21:39:34 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 15 Aug 2000 16:39:34 -0400 Subject: [Patches] [Patch #101055] Cookie.py In-Reply-To: <200008152025.NAA30637@delerium.i.sourceforge.net>; from noreply@sourceforge.net on Tue, Aug 15, 2000 at 01:25:07PM -0700 References: <200008152025.NAA30637@delerium.i.sourceforge.net> Message-ID: <20000815163934.A17101@kronos.cnri.reston.va.us> On Tue, Aug 15, 2000 at 01:25:07PM -0700, noreply@sourceforge.net wrote: >Yes, but we're still waiting on a non-LGPL encumbered version of the >file. Last I heard, Andrew had gotten in touch with O'Malley who said >he had a BSD covered version, but hadn't given a link yet. I'm still waiting to hear back (just sent my third e-mail about it)... --amk From noreply@sourceforge.net Tue Aug 15 22:08:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 14:08:39 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008152108.OAA32320@delerium.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Tue Aug 15 22:26:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 14:26:03 -0700 Subject: [Patches] [Patch #101055] Cookie.py Message-ID: <200008152126.OAA00488@delerium.i.sourceforge.net> Patch #101055 has been updated. Project: Category: library Status: Open Summary: Cookie.py Follow-Ups: Date: 2000-Aug-15 12:01 By: tim_one Comment: Assigned to GregS as he seems to be a Cookie Guy too. Greg, please review this or pass it on. Barry, you realize this needs doc and test patches too else it will just get Postponed? ------------------------------------------------------- Date: 2000-Aug-15 13:25 By: bwarsaw Comment: Yes, but we're still waiting on a non-LGPL encumbered version of the file. Last I heard, Andrew had gotten in touch with O'Malley who said he had a BSD covered version, but hadn't given a link yet. ------------------------------------------------------- Date: 2000-Aug-15 14:26 By: tim_one Comment: OK, I assigned it to Andrew. If this isn't resolved in a few days, one of you please change the status to Postponed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101055&group_id=5470 From tim_one@email.msn.com Tue Aug 15 22:25:12 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 15 Aug 2000 17:25:12 -0400 Subject: [Patches] [Patch #101055] Cookie.py In-Reply-To: <200008152025.NAA30637@delerium.i.sourceforge.net> Message-ID: > Date: 2000-Aug-15 13:25 > By: bwarsaw > > Comment: > Yes, but we're still waiting on a non-LGPL encumbered version of > the file. Last I heard, Andrew had gotten in touch with O'Malley > who said he had a BSD covered version, but hadn't given a link yet. > ------------------------------------------------------- OK, I'll assign it to Andrew. If this isn't resolved in a few days, one of you please change the status to Postponed. From noreply@sourceforge.net Tue Aug 15 22:32:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 14:32:10 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008152132.OAA00755@delerium.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From Moshe Zadka Tue Aug 15 22:37:12 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 16 Aug 2000 00:37:12 +0300 (IDT) Subject: [Patches] [Patch #101055] Cookie.py In-Reply-To: <20000815163934.A17101@kronos.cnri.reston.va.us> Message-ID: On Tue, 15 Aug 2000, Andrew Kuchling wrote: > On Tue, Aug 15, 2000 at 01:25:07PM -0700, noreply@sourceforge.net wrote: > >Yes, but we're still waiting on a non-LGPL encumbered version of the > >file. Last I heard, Andrew had gotten in touch with O'Malley who said > >he had a BSD covered version, but hadn't given a link yet. > > I'm still waiting to hear back (just sent my third e-mail about it)... OK, what's wrong with using the WebWare version? It's fairly recent, and old-Python-licence licensed. I've started working on docos, but I'm afraid I won't have any serious time to spend on it until Sep. 1... (If Tim later responds, we'll change the version in the core and patch the documentation -- no problem) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From noreply@sourceforge.net Tue Aug 15 22:38:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 14:38:17 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008152138.OAA00956@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 13:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 14:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Tue Aug 15 23:06:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:06:40 -0700 Subject: [Patches] [Patch #101121] cosmetic cleanup of cgi.py, using Guido's style conventions Message-ID: <200008152206.PAA02038@delerium.i.sourceforge.net> Patch #101121 has been updated. Project: Category: library Status: Open Summary: cosmetic cleanup of cgi.py, using Guido's style conventions Follow-Ups: Date: 2000-Aug-08 13:37 By: ping Comment: This is an immediate follow-on to #101120 (i just wanted to keep the semantic and non-semantic changes separate). ------------------------------------------------------- Date: 2000-Aug-15 15:06 By: tim_one Comment: I'm not sure what you mean by "follow-on". If this patch is *independent* of 101120, just Accept it yourself and check it in -- there's no need to go thru a review process for mechanical cleanup. Assigning to you on that basis. Ah, and you *can* check it in, in about 6 hours: you've been added to the Python project as a Developer. That means I get to assign patches to you for review, too From noreply@sourceforge.net Tue Aug 15 23:08:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:08:16 -0700 Subject: [Patches] [Patch #101129] add indices() and irange() to built-ins Message-ID: <200008152208.PAA02068@delerium.i.sourceforge.net> Patch #101129 has been updated. Project: Category: core (C code) Status: Open Summary: add indices() and irange() to built-ins Follow-Ups: Date: 2000-Aug-09 03:00 By: ping Comment: There ya go. I have followed the style of the builtin_range() function, and docstrings are included. ------------------------------------------------------- Date: 2000-Aug-15 15:08 By: tim_one Comment: Assigned to Guido for Pronouncement. The debate's been debated, close it out one way or the other. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101129&group_id=5470 From noreply@sourceforge.net Tue Aug 15 23:12:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:12:58 -0700 Subject: [Patches] [Patch #101135] 'import x as y' and 'from x import y as z' Message-ID: <200008152212.PAA02248@delerium.i.sourceforge.net> Patch #101135 has been updated. Project: Category: core (C code) Status: Open Summary: 'import x as y' and 'from x import y as z' Follow-Ups: Date: 2000-Aug-09 13:23 By: twouters Comment: This patch adds the oft-proposed 'import as' syntax, to both 'import module' and 'from module import ...', but without making 'as' a reserved word (by using the technique Tim Peters proposed on python-dev.) 'import spam as egg' is a very simple patch to compile.c, which doesn't need changes to the VM, but 'from spam import dog as meat' needs a new bytecode, which this patch calls 'FROM_IMPORT_AS'. The bytecode loads an object from a module onto the stack, so a STORE_NAME can store it later. This can't be done by the normal FROM_IMPORT opcode, because it needs to take the special case of '*' into account. Also, because it uses 'STORE_NAME', it's now possible to mix 'import' and 'global', like so: global X from foo import X as X The patch still generates the old code for from foo import X (without 'as') mostly to save on bytecode size, and for the 'compatibility' with mixing 'global' and 'from .. import'... I'm not sure what's the best thing to do. The patch doesn't include a test suite or documentation, yet. ------------------------------------------------------- Date: 2000-Aug-11 15:04 By: twouters Comment: I now think the best thing to do is to split the 'IMPORT_FROM' opcode into two opcodes: 'IMPORT_ALL', which is used for 'from module import *', and 'IMPORT_FROM' (or another name, if that's desired) which loads a single name. IMPORT_ALL would store the retrieved objects into the local namespace directly, like IMPORT_FROM currently does; it doesn't use the stack other than to retrieve the module it loads the symbols from. IMPORT_FROM would act more like 'IMPORT_NAME', in that the object retrieved from the module is not stored directly in the local namespace, but instead pushed on the stack (that's what the IMPORT_FROM_AS bytecode in the current patch does) -- that means that for all normal 'from' imports, a STORE is generated, and a 'global' works on them just like with normal variable assignment. In the current patch, this is only true for 'from module import x as y' statements, not for the normal form. Assigned to Guido, since it's ultimately his decision (everyone else already voted ;-) ------------------------------------------------------- Date: 2000-Aug-15 15:12 By: tim_one Comment: Reminding Guido this is still on his plate. Thomas, I agree with you that splitting IMPORT_FROM is a good idea -- the "*" and "name" cases are indeed very different. Since Guido hasn't gotten to this yet, how about changing the patch before he notices? The votes you got before were based on the visible semantics, not the implementation, so no need to vote again. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470 From noreply@sourceforge.net Tue Aug 15 23:15:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:15:23 -0700 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <200008152215.PAA02305@delerium.i.sourceforge.net> Patch #101137 has been updated. Project: Category: Modules Status: Open Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway . ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Tue Aug 15 23:19:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:19:39 -0700 Subject: [Patches] [Patch #101138] 'for i indexing a in l': exposing the for-loop counter Message-ID: <200008152219.PAA02475@delerium.i.sourceforge.net> Patch #101138 has been updated. Project: Category: core (C code) Status: Open Summary: 'for i indexing a in l': exposing the for-loop counter Follow-Ups: Date: 2000-Aug-09 15:10 By: twouters Comment: This patch adds a way to get the loop counter in Python for-loops. The syntax is one Just quoted on python-dev today, which he attributes to Tim (and was probably proposed by half the thinking Python community by now ;) It's a quick and dirty hack, but it works. There might be refcounting bugs and much more efficient ways to do it, but it works ;) It also lacks a test case and documentation. ------------------------------------------------------- Date: 2000-Aug-11 00:27 By: hooft Comment: Do we need a new keyword for this functionality, or can we use zip? Maybe adding zip-magic would help, but: >>> a=['a','b','c','d'] >>> for i,el in zip(xrange(9999999),a): ... print i,el ... 0 a 1 b 2 c 3 d ------------------------------------------------------- Date: 2000-Aug-11 00:33 By: hooft Comment: Or: >>> class indexing: ... def __init__(self,a): ... self.data=a ... def __getitem__(self,i): ... return i,self.data[i] ... >>> for i,el in indexing(a): ... print i,el ... 0 a 1 b 2 c 3 d >>> ------------------------------------------------------- Date: 2000-Aug-11 00:38 By: twouters Comment: The patch exposes the already-present loop counter to python code, rather than just adding a list of ranges to loop over. That is one of the reasons to make it a syntactic change: other techniques to use the builtin loop counter would require psychic interpreters ;) The patch does *not* introduce a new keyword, by the way. the 'indexing' name is just a NAME, not a real keyword, and can be used as a variable just fine. ------------------------------------------------------- Date: 2000-Aug-13 19:32 By: nowonder Comment: I think that using the builtin loop counter would be nice. But I don't see this justifying extra syntax. Paul Prescod's suggestion of adding .items() to lists seems more natural to me. ------------------------------------------------------- Date: 2000-Aug-15 15:19 By: tim_one Comment: Assigned to Guido for Pronouncement, as this is the last chance he'll ever have to end the blood feud with his brother . ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101138&group_id=5470 From noreply@sourceforge.net Tue Aug 15 23:23:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:23:54 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200008152223.PAA02647@delerium.i.sourceforge.net> Patch #101162 has been updated. Project: Category: Build Status: Open Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. ------------------------------------------------------- Date: 2000-Aug-15 15:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Tue Aug 15 23:25:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:25:13 -0700 Subject: [Patches] [Patch #101135] 'import x as y' and 'from x import y as z' Message-ID: <200008152225.PAA02671@delerium.i.sourceforge.net> Patch #101135 has been updated. Project: Category: core (C code) Status: Open Summary: 'import x as y' and 'from x import y as z' Follow-Ups: Date: 2000-Aug-09 13:23 By: twouters Comment: This patch adds the oft-proposed 'import as' syntax, to both 'import module' and 'from module import ...', but without making 'as' a reserved word (by using the technique Tim Peters proposed on python-dev.) 'import spam as egg' is a very simple patch to compile.c, which doesn't need changes to the VM, but 'from spam import dog as meat' needs a new bytecode, which this patch calls 'FROM_IMPORT_AS'. The bytecode loads an object from a module onto the stack, so a STORE_NAME can store it later. This can't be done by the normal FROM_IMPORT opcode, because it needs to take the special case of '*' into account. Also, because it uses 'STORE_NAME', it's now possible to mix 'import' and 'global', like so: global X from foo import X as X The patch still generates the old code for from foo import X (without 'as') mostly to save on bytecode size, and for the 'compatibility' with mixing 'global' and 'from .. import'... I'm not sure what's the best thing to do. The patch doesn't include a test suite or documentation, yet. ------------------------------------------------------- Date: 2000-Aug-11 15:04 By: twouters Comment: I now think the best thing to do is to split the 'IMPORT_FROM' opcode into two opcodes: 'IMPORT_ALL', which is used for 'from module import *', and 'IMPORT_FROM' (or another name, if that's desired) which loads a single name. IMPORT_ALL would store the retrieved objects into the local namespace directly, like IMPORT_FROM currently does; it doesn't use the stack other than to retrieve the module it loads the symbols from. IMPORT_FROM would act more like 'IMPORT_NAME', in that the object retrieved from the module is not stored directly in the local namespace, but instead pushed on the stack (that's what the IMPORT_FROM_AS bytecode in the current patch does) -- that means that for all normal 'from' imports, a STORE is generated, and a 'global' works on them just like with normal variable assignment. In the current patch, this is only true for 'from module import x as y' statements, not for the normal form. Assigned to Guido, since it's ultimately his decision (everyone else already voted ;-) ------------------------------------------------------- Date: 2000-Aug-15 15:12 By: tim_one Comment: Reminding Guido this is still on his plate. Thomas, I agree with you that splitting IMPORT_FROM is a good idea -- the "*" and "name" cases are indeed very different. Since Guido hasn't gotten to this yet, how about changing the patch before he notices? The votes you got before were based on the visible semantics, not the implementation, so no need to vote again. ------------------------------------------------------- Date: 2000-Aug-15 15:25 By: twouters Comment: Actually, I finished an updated patch that did that about two hours ago, but Blackadder intervened, and I forgot to upload it afterwards :P This patch does not contain doc changes or test cases yet, but the changes to the core are finished, as far as I'm concerned. I'll try to finish the docs and tests tomorrow. (I have to say this is the first patch where the doc changes look more attractive than the test case. I need to start a syntax-highlighting editor just to be able to *read* test_pkg, let alone extend it ;) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470 From noreply@sourceforge.net Tue Aug 15 23:26:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:26:48 -0700 Subject: [Patches] [Patch #101170] Prevent old extensions from crashing Message-ID: <200008152226.PAA02794@delerium.i.sourceforge.net> Patch #101170 has been updated. Project: Category: Windows Status: Open Summary: Prevent old extensions from crashing Follow-Ups: Date: 2000-Aug-12 01:55 By: chega Comment: This patch will prevent old (1.5/1.6) extensions from crashing under Python 2.0 (Also changed pathbuf[260] to pathbuf[MAX_PATH]) ------------------------------------------------------- Date: 2000-Aug-15 15:26 By: tim_one Comment: Assigned to MarkH. Please review or pass on to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101170&group_id=5470 From noreply@sourceforge.net Tue Aug 15 23:31:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:31:00 -0700 Subject: [Patches] [Patch #101186] IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Message-ID: <200008152231.PAA02879@delerium.i.sourceforge.net> Patch #101186 has been updated. Project: Category: Modules Status: Postponed Summary: IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Follow-Ups: Date: 2000-Aug-15 09:18 By: twouters Comment: This looks like PEP material. We actually discussed this briefly on python-dev, but there was noone there that had both the time and the knowledge to persue this. (I looked briefly at the 1.5.2 IPv6 implementation, but it raised too many questions to be added 'just like that', IMHO.) Would anyone from the team that wrote this feel like writing a PEP ? How involved are you in Python ? In absense of a volunteer to write a PEP, would there be a volunteer to explain design decisions ? (Hm, the person who submitted this patch did so anonymously. I'll forward the summary of this patch to core@kame.net) ------------------------------------------------------- Date: 2000-Aug-15 09:31 By: fdrake Comment: This will not go in Python 1.6. Python 2.0 is also closed for new features, so this should be taken up with Tim & Guido for 2.0. There is no good reason not to include this feature in Python 2.1; but I can't speak for the quality of the patch until I've had time to review it. Perhaps Python developers & testers knowledgable about IPv6 should get in touch with the person this patch is assigned to. ------------------------------------------------------- Date: 2000-Aug-15 15:30 By: tim_one Comment: Changed status to Postponed because it came in after 2.0 feature freeze. If you make a huge stink on Python-Dev and get a lot of support, cool, I'll re-Open it. Else it's for 2.1 at the earliest. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101186&group_id=5470 From noreply@sourceforge.net Tue Aug 15 23:34:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:34:15 -0700 Subject: [Patches] [Patch #101187] Patch for ftplib to support REST Message-ID: <200008152234.PAA03039@delerium.i.sourceforge.net> Patch #101187 has been updated. Project: Category: Modules Status: Open Summary: Patch for ftplib to support REST Follow-Ups: Date: 2000-Aug-15 15:34 By: tim_one Comment: Assigned to Barry for an opinion. This came in after feature freeze, but it's arguably more of a bugfix than a new feature. If you're capable of making that decision with more confidence than me, please Postpone it or assign it to a competent (not me) reviewer for 2.0. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101187&group_id=5470 From gstein@lyra.org Tue Aug 15 23:39:36 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 15 Aug 2000 15:39:36 -0700 Subject: [Patches] [Patch #101055] Cookie.py In-Reply-To: ; from tim_one@email.msn.com on Tue, Aug 15, 2000 at 05:25:12PM -0400 References: <200008152025.NAA30637@delerium.i.sourceforge.net> Message-ID: <20000815153936.M19525@lyra.org> On Tue, Aug 15, 2000 at 05:25:12PM -0400, Tim Peters wrote: > > Date: 2000-Aug-15 13:25 > > By: bwarsaw > > > > Comment: > > Yes, but we're still waiting on a non-LGPL encumbered version of > > the file. Last I heard, Andrew had gotten in touch with O'Malley > > who said he had a BSD covered version, but hadn't given a link yet. > > ------------------------------------------------------- > > OK, I'll assign it to Andrew. If this isn't resolved in a few days, one of > you please change the status to Postponed. Not a problem. Cheers, -g -- Greg Stein, http://www.lyra.org/ From noreply@sourceforge.net Tue Aug 15 23:43:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 15:43:11 -0700 Subject: [Patches] [Patch #100970] extended print statement Message-ID: <200008152243.PAA03359@delerium.i.sourceforge.net> Patch #100970 has been updated. Project: Category: core (C code) Status: Open Summary: extended print statement Follow-Ups: Date: 2000-Jul-23 19:44 By: bwarsaw Comment: This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout). This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement. An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM. I'm not sure which approach is better. ------------------------------------------------------- Date: 2000-Jul-23 19:45 By: bwarsaw Comment: The following is an example of how you might use the new extended print statement. 
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
------------------------------------------------------- Date: 2000-Aug-15 11:00 By: tim_one Comment: Assigned to Guido for Pronouncement. This was already discussed on Python-Dev. Mix of opinions there. I like it fine. Barry, this needs docs and test cases Real Soon if you want it considered for 2.0. I like the PRINT_TO idea better. ------------------------------------------------------- Date: 2000-Aug-15 15:43 By: bwarsaw Comment: Revised patch which uses the PRINT_ITEM_TO approach favored by Tim. This patch also includes doc and test suite updates. Please see PEP 214 for a discussion of the issues. This feature should be postponed until Python 2.1 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470 From noreply@sourceforge.net Wed Aug 16 00:00:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 16:00:43 -0700 Subject: [Patches] [Patch #101029] Call __getitem__ for slices when no __getslice__ Message-ID: <200008152300.QAA03971@delerium.i.sourceforge.net> Patch #101029 has been updated. Project: Category: core (C code) Status: Open Summary: Call __getitem__ for slices when no __getslice__ Follow-Ups: Date: 2000-Jul-31 06:55 By: twouters Comment: Call __getitem__ if no __getslice__ is available. similar for __delslice__ and __setslice__, and for the C API: calls mp_subscript() with a slice object of (start, end, None) if there is no sq_slice(), and the same for sq_ass_slice(). Eventually the reverse should be done, too: call __getslice__ instead of __getitem__ if the object has a __getslice__, and the 3rd argument to the slice is None: That way, we can ditch the 12 silly SLICE* opcodes, and always use slice objects. This *will* result in x[::] being passed to __getslice__ (if available) instead of __getitem__, however, so it is not 100% backwards compatible. This patch is not terribly tested: I'm not feeling well, and I want to post this patch before I head off to home and dive back in bed ;) It doesn't crash, it survives 'make test', it survives manual testing, but it might leak. ------------------------------------------------------- Date: 2000-Jul-31 07:55 By: gvanrossum Comment: Looks cool to me, except that there's a lot of code duplication. Maybe you can add a static helper routine to create a slice out of two ints to abstract.c and one that creates a 1-tuple containing such a slice to classobject.c. (Trying to share code across .c files would require turning it into an official API which I think is overkill.) ------------------------------------------------------- Date: 2000-Jul-31 14:35 By: twouters Comment: New version with less code duplication. Less, not none, unfortunately, because both abstract.c and classobject.c need roughly the same function :P Making the classobject.c one return a 1-tuple is not very useful, because only one place needs a 1-tuple, the other needs a 2-tuple, and I don't fancy modifying the 1-tuple separately. Don't you wish C was more like Python ? *sigh* ------------------------------------------------------- Date: 2000-Aug-15 11:56 By: tim_one Comment: Assigned to Guido because his is the next natural voice in the conversation. Thomas, note that this needs doc and test patches too if it's not to be Postponed. ------------------------------------------------------- Date: 2000-Aug-15 16:00 By: twouters Comment: Just to show y'all that I *can* write documentation and test cases, I've included both in this patch. In fact, those parts take up a lot more space than the actual code change, now ;) Mostly because the test case also tests all other Python class __hooks__. I couldn't find the testcase for them, so I wrote one. The doc changes definately need an editor, if only to add some cross references to slice objects and such. Also, depending on the BDFL, some stronger language might be in order, to scare people away from __getslice__ and brothers. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101029&group_id=5470 From noreply@sourceforge.net Wed Aug 16 00:05:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 16:05:24 -0700 Subject: [Patches] [Patch #100970] extended print statement Message-ID: <200008152305.QAA04132@delerium.i.sourceforge.net> Patch #100970 has been updated. Project: Category: core (C code) Status: Open Summary: extended print statement Follow-Ups: Date: 2000-Jul-23 19:44 By: bwarsaw Comment: This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout). This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement. An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM. I'm not sure which approach is better. ------------------------------------------------------- Date: 2000-Jul-23 19:45 By: bwarsaw Comment: The following is an example of how you might use the new extended print statement. 
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
------------------------------------------------------- Date: 2000-Aug-15 11:00 By: tim_one Comment: Assigned to Guido for Pronouncement. This was already discussed on Python-Dev. Mix of opinions there. I like it fine. Barry, this needs docs and test cases Real Soon if you want it considered for 2.0. I like the PRINT_TO idea better. ------------------------------------------------------- Date: 2000-Aug-15 15:43 By: bwarsaw Comment: Revised patch which uses the PRINT_ITEM_TO approach favored by Tim. This patch also includes doc and test suite updates. Please see PEP 214 for a discussion of the issues. This feature should be postponed until Python 2.1 ------------------------------------------------------- Date: 2000-Aug-15 16:05 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470 From noreply@sourceforge.net Wed Aug 16 00:05:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 16:05:54 -0700 Subject: [Patches] [Patch #100835] PC/config.h: support for gnu-win32 and lcc-win32 Message-ID: <200008152305.QAA04143@delerium.i.sourceforge.net> Patch #100835 has been updated. Project: Category: Windows Status: Closed Summary: PC/config.h: support for gnu-win32 and lcc-win32 Follow-Ups: Date: 2000-Jul-10 04:43 By: RLiebscher Comment: This patch makes it possible to use gnu-win32 and lcc-win32 (http://www.cs.virginia.edu/~lcc-win32/) compilers to build extension modules. It adds compiler specific sections to PC/config.h . It also extends the Borland compiler section. This has then two parts, one for Win32 and the other one for the rest. The Win32 part should be almost complete. *** This patch is not intended to make it possible to compile Python with these compilers, it is intended to be able to use these compilers to build extension modules. **** ------------------------------------------------------- Date: 2000-Jul-10 04:44 By: RLiebscher Comment: This patch makes it possible to use gnu-win32 and lcc-win32 (http://www.cs.virginia.edu/~lcc-win32/) compilers to build extension modules. It adds compiler specific sections to PC/config.h . It also extends the Borland compiler section. This has then two parts, one for Win32 and the other one for the rest. The Win32 part should be almost complete. *** This patch is not intended to make it possible to compile Python with these compilers, it is intended to be able to use these compilers to build extension modules. **** ------------------------------------------------------- Date: 2000-Jul-13 13:22 By: jhylton Comment: Assigned to Tim because he is handling Windows build issues ------------------------------------------------------- Date: 2000-Aug-10 21:08 By: tim_one Comment: Left open and assigned to Mark Hammond. Mark, you have any objections to this? I have no way to test any of it, and I doubt any of us do. If you don't object to the patch by eyeball either, please Accept it and either check it in or assign it to someone else (I don't have a working "patch" yet!). ------------------------------------------------------- Date: 2000-Aug-15 10:31 By: tim_one Comment: Tickling you as part of 2.0 nagging. ------------------------------------------------------- Date: 2000-Aug-15 16:05 By: mhammond Comment: Checked in as Rev 1.45 of PC/config.h ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100835&group_id=5470 From fdrake@beopen.com Wed Aug 16 00:05:21 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 15 Aug 2000 19:05:21 -0400 (EDT) Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py In-Reply-To: <20000815221722.D1147@xs4all.nl> References: <200008151849.LAA26752@delerium.i.sourceforge.net> <14745.37595.507937.752085@cj42289-a.reston1.va.home.com> <20000815212153.C1147@xs4all.nl> <3999BB52.D929E777@nowonder.de> <20000815221722.D1147@xs4all.nl> Message-ID: <14745.52401.679786.12500@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > either accept or reject you. I don't see why they would reject you, since > you're too far from Reston to join the weekly patches-parties anyway ;) Hey, I want to go to those! Tell me where & when! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From noreply@sourceforge.net Wed Aug 16 00:16:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 16:16:11 -0700 Subject: [Patches] [Patch #100970] extended print statement Message-ID: <200008152316.QAA18633@bush.i.sourceforge.net> Patch #100970 has been updated. Project: Category: core (C code) Status: Open Summary: extended print statement Follow-Ups: Date: 2000-Jul-23 19:44 By: bwarsaw Comment: This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout). This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement. An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM. I'm not sure which approach is better. ------------------------------------------------------- Date: 2000-Jul-23 19:45 By: bwarsaw Comment: The following is an example of how you might use the new extended print statement. 
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
------------------------------------------------------- Date: 2000-Aug-15 11:00 By: tim_one Comment: Assigned to Guido for Pronouncement. This was already discussed on Python-Dev. Mix of opinions there. I like it fine. Barry, this needs docs and test cases Real Soon if you want it considered for 2.0. I like the PRINT_TO idea better. ------------------------------------------------------- Date: 2000-Aug-15 15:43 By: bwarsaw Comment: Revised patch which uses the PRINT_ITEM_TO approach favored by Tim. This patch also includes doc and test suite updates. Please see PEP 214 for a discussion of the issues. This feature should be postponed until Python 2.1 ------------------------------------------------------- Date: 2000-Aug-15 16:05 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-15 16:16 By: bwarsaw Comment: Okay, I just thought that with the open issue (see PEP 214) it might not be ready for prime time. Let's wait for the BDFL pronounce before postponing. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470 From noreply@sourceforge.net Wed Aug 16 00:26:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 16:26:49 -0700 Subject: [Patches] [Patch #101170] Prevent old extensions from crashing Message-ID: <200008152326.QAA04912@delerium.i.sourceforge.net> Patch #101170 has been updated. Project: Category: Windows Status: Postponed Summary: Prevent old extensions from crashing Follow-Ups: Date: 2000-Aug-12 01:55 By: chega Comment: This patch will prevent old (1.5/1.6) extensions from crashing under Python 2.0 (Also changed pathbuf[260] to pathbuf[MAX_PATH]) ------------------------------------------------------- Date: 2000-Aug-15 15:26 By: tim_one Comment: Assigned to MarkH. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-15 16:26 By: mhammond Comment: I'm not sure this is worth adding. Note that we already have code to prevent a crash in place - however, rather than raising an exception it simply calls Py_FatalError. This patch is potentially better, except that: * It will require regressing the patch made to modsupport.c (Rev 2.50) to prevent the same problem; that code will prevent this code kicking in! * It hard-codes the Python DLL names. This makes long term maintenance a PITA, and yet another file that needs to be updated when a version bumps. Are there other alternatives? * Once the module has been loaded, it may be too late to save the process anyway. I realize that the module init hasnt been called yet, but the module has been loaded, and may be doing things in its DllMain() that will destabilize the process. The big killer is simply that this code will never be triggered, as the check in modsupport.c will kick in first. Setting to postponed until we can get a better handle on this. A big advantage is that this style of change is not dependent on _old_ versions having the patch, only one actually running. Hence we can revive this patch at any time, and have it start working immediately. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101170&group_id=5470 From noreply@sourceforge.net Wed Aug 16 00:33:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 16:33:15 -0700 Subject: [Patches] [Patch #100970] extended print statement Message-ID: <200008152333.QAA05091@delerium.i.sourceforge.net> Patch #100970 has been updated. Project: Category: core (C code) Status: Open Summary: extended print statement Follow-Ups: Date: 2000-Jul-23 19:44 By: bwarsaw Comment: This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout). This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement. An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM. I'm not sure which approach is better. ------------------------------------------------------- Date: 2000-Jul-23 19:45 By: bwarsaw Comment: The following is an example of how you might use the new extended print statement. 
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
------------------------------------------------------- Date: 2000-Aug-15 11:00 By: tim_one Comment: Assigned to Guido for Pronouncement. This was already discussed on Python-Dev. Mix of opinions there. I like it fine. Barry, this needs docs and test cases Real Soon if you want it considered for 2.0. I like the PRINT_TO idea better. ------------------------------------------------------- Date: 2000-Aug-15 15:43 By: bwarsaw Comment: Revised patch which uses the PRINT_ITEM_TO approach favored by Tim. This patch also includes doc and test suite updates. Please see PEP 214 for a discussion of the issues. This feature should be postponed until Python 2.1 ------------------------------------------------------- Date: 2000-Aug-15 16:05 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-15 16:16 By: bwarsaw Comment: Okay, I just thought that with the open issue (see PEP 214) it might not be ready for prime time. Let's wait for the BDFL pronounce before postponing. ------------------------------------------------------- Date: 2000-Aug-15 16:33 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470 From noreply@sourceforge.net Wed Aug 16 00:40:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 16:40:53 -0700 Subject: [Patches] [Patch #100759] range-lists: [1:10] (relative to list comprehensions patch) Message-ID: <200008152340.QAA05395@delerium.i.sourceforge.net> Patch #100759 has been updated. Project: Category: None Status: Deleted Summary: range-lists: [1:10] (relative to list comprehensions patch) Follow-Ups: Date: 2000-Jul-07 16:09 By: twouters Comment: This patch (which is relative to the list comprehension patch, because it isn't likely to go in before listcomp, and they clash at a couple of places) adds built-in range-creation, exactly like the range() builtin, but without the ability to override the behaviour by masking the builtin with a global or local range() ;) [10:100:2] is exactly the same as range(10, 100, 2). Assignment to range-literals is not possible, nor is 'chaining' them inside a single list. They do work well with list comprehension: [ x * 2 for x in [1:100] if x % 3] Also, the patch contains some code duplication (about the entire build_range function, plus get_len_of_range()) I'm not sure how to properly solve that: is it okay for compile.c to rely on something from bltinmodule.c ? If not, should I move the common functionality into listobject.c ? ------------------------------------------------------- Date: 2000-Jul-07 16:12 By: twouters Comment: Oh, and before anyone gets the wrong impression, this idea was not mine; Guido suggested I try and implement it. ------------------------------------------------------- Date: 2000-Aug-15 16:40 By: tim_one Comment: Changed status from Out-of-date to Deleted, as this patch was essentially resubmitted as 100902. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100759&group_id=5470 From noreply@sourceforge.net Wed Aug 16 00:49:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 16:49:31 -0700 Subject: [Patches] [Patch #101170] Prevent old extensions from crashing Message-ID: <200008152349.QAA05633@delerium.i.sourceforge.net> Patch #101170 has been updated. Project: Category: Windows Status: Postponed Summary: Prevent old extensions from crashing Follow-Ups: Date: 2000-Aug-12 01:55 By: chega Comment: This patch will prevent old (1.5/1.6) extensions from crashing under Python 2.0 (Also changed pathbuf[260] to pathbuf[MAX_PATH]) ------------------------------------------------------- Date: 2000-Aug-15 15:26 By: tim_one Comment: Assigned to MarkH. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-15 16:26 By: mhammond Comment: I'm not sure this is worth adding. Note that we already have code to prevent a crash in place - however, rather than raising an exception it simply calls Py_FatalError. This patch is potentially better, except that: * It will require regressing the patch made to modsupport.c (Rev 2.50) to prevent the same problem; that code will prevent this code kicking in! * It hard-codes the Python DLL names. This makes long term maintenance a PITA, and yet another file that needs to be updated when a version bumps. Are there other alternatives? * Once the module has been loaded, it may be too late to save the process anyway. I realize that the module init hasnt been called yet, but the module has been loaded, and may be doing things in its DllMain() that will destabilize the process. The big killer is simply that this code will never be triggered, as the check in modsupport.c will kick in first. Setting to postponed until we can get a better handle on this. A big advantage is that this style of change is not dependent on _old_ versions having the patch, only one actually running. Hence we can revive this patch at any time, and have it start working immediately. ------------------------------------------------------- Date: 2000-Aug-15 16:49 By: tim_one Comment: I agree with Postponing it. Thanks for the quick response! Feel like reviewing 7 controversial getopt patches now ? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101170&group_id=5470 From noreply@sourceforge.net Wed Aug 16 01:05:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 17:05:19 -0700 Subject: [Patches] [Patch #100895] safe version of PyErr_Format Message-ID: <200008160005.RAA06253@delerium.i.sourceforge.net> Patch #100895 has been updated. Project: Category: core (C code) Status: Open Summary: safe version of PyErr_Format Follow-Ups: Date: 2000-Jul-17 14:56 By: effbot Comment: minor tweaks (mostly comments), based on input from moshe. ------------------------------------------------------- Date: 2000-Jul-17 23:23 By: moshez Comment: I'm +1 on that! It will plug one more security hole in Python, and seems a "good enough" replacement for an unsure snprintf() ------------------------------------------------------- Date: 2000-Aug-08 10:19 By: effbot Comment: regenerated, since moshez reported that it didn't apply cleanly to the current CVS tree. reassigned, since it's been sitting here for ages. ------------------------------------------------------- Date: 2000-Aug-10 21:04 By: tim_one Comment: Rejected and back to /F. Major: no docs! Format strings processed by this have different semantics than anyone could guess (e.g., flags are ignored, width is ignored, some format codes are copied verbatim). Reverse-engineering the code each time there's a question is just too painful. You're basically inventing a new sublanguage here, so document what the heck it is & means. Mechanical: There's a "step 1" but no "step 2" . We shouldn't be #ifdef'ing on prototypes anymore. Guido did not yield to the push for 4-space indents in C code, so this should use hard tabs. ------------------------------------------------------- Date: 2000-Aug-15 17:05 By: tim_one Comment: Changed status from Rejeced to Open so we only have to look in one place for the status of putative 2.0 patches. But the patch is still *effectively* rejected pending response to the objections. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From noreply@sourceforge.net Wed Aug 16 01:57:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 17:57:10 -0700 Subject: [Patches] [Patch #100852] Add poll() to select module Message-ID: <200008160057.RAA08057@delerium.i.sourceforge.net> Patch #100852 has been updated. Project: Category: None Status: Open Summary: Add poll() to select module Follow-Ups: Date: 2000-Jul-11 04:25 By: akuchling Comment: Derived from Sam Rushing's pollmodule.c that forms part of Medusa. Once I get a second opinion about the patch, I'll check it in. ------------------------------------------------------- Date: 2000-Jul-21 06:33 By: akuchling Comment: Updated version of the patch, which adds poll() to the select module. .register() and .unregister() add/remove fds, and .poll() performs the system call. Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored. Open question: should there be a function or attribute to get the list of registered fds? Still to do: write documentation, add the test case. ------------------------------------------------------- Date: 2000-Jul-24 17:54 By: akuchling Comment: Assigned to Jeremy for review; feel free to bounce it to someone else. ------------------------------------------------------- Date: 2000-Jul-25 10:25 By: akuchling Comment: Update patch to latest version, which adds poll() to the select() module. ------------------------------------------------------- Date: 2000-Jul-25 13:30 By: jhylton Comment: Several style nits changed, mostly to do with whitespace. Substantive changes: 1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens 2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND One more Open Issue: I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions: - interface to register many fds at once - keep the list of fds in sorted order - use a dict to store fds and generate fdarry lazily - keep track of allocated length and used length for ufds, so that fewer reallocs are required Each of these suggestions has some added complexity, so I'm not sure that I like any of them. ------------------------------------------------------- Date: 2000-Jul-25 13:41 By: akuchling Comment: I wondered about the linear search, too; it means balancing efficiency versus the lines of code to write this one object? IMHO implementing both #1 and #3 would be good; allow passing an arbitrary # of fds to register (and unregister?), store them in a dict, and then lazily generate the ufd array when needed. Or is there some built-in more suited than a dict for this? Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors. ------------------------------------------------------- Date: 2000-Jul-25 14:40 By: jhylton Comment: I think a dict is the right data structure, but I don't think it should be exposed directly. If it is not exposed, then the ufd array need only be generated for poll calls after a register or unregister. If there are multiple polls without a change, the same array can be re-used. ------------------------------------------------------- Date: 2000-Aug-12 21:13 By: akuchling Comment: Latest version, which stores an underlying dict as suggested in jhylton's previous comment. p.unregister() raises KeyError if you unregister a fd that wasn't registered in the first place; seem reasonable? It does to me... The code should now be completed; the only remaining task is to write docstrings and finish the documentation patch. ------------------------------------------------------- Date: 2000-Aug-15 10:36 By: tim_one Comment: Tickling you as part of 2.0 nagging. Please leave a note saying when you intend to "write docstrings and finish the documentation". ------------------------------------------------------- Date: 2000-Aug-15 17:57 By: akuchling Comment: Revised version -- documentation & docstrings completed, and there's a test script (not part of patch). Ready to check in once someone gives the patch a quick once-over and sanity check. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 From noreply@sourceforge.net Wed Aug 16 03:38:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 19:38:15 -0700 Subject: [Patches] [Patch #100852] Add poll() to select module Message-ID: <200008160238.TAA11586@delerium.i.sourceforge.net> Patch #100852 has been updated. Project: Category: None Status: Open Summary: Add poll() to select module Follow-Ups: Date: 2000-Jul-11 04:25 By: akuchling Comment: Derived from Sam Rushing's pollmodule.c that forms part of Medusa. Once I get a second opinion about the patch, I'll check it in. ------------------------------------------------------- Date: 2000-Jul-21 06:33 By: akuchling Comment: Updated version of the patch, which adds poll() to the select module. .register() and .unregister() add/remove fds, and .poll() performs the system call. Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored. Open question: should there be a function or attribute to get the list of registered fds? Still to do: write documentation, add the test case. ------------------------------------------------------- Date: 2000-Jul-24 17:54 By: akuchling Comment: Assigned to Jeremy for review; feel free to bounce it to someone else. ------------------------------------------------------- Date: 2000-Jul-25 10:25 By: akuchling Comment: Update patch to latest version, which adds poll() to the select() module. ------------------------------------------------------- Date: 2000-Jul-25 13:30 By: jhylton Comment: Several style nits changed, mostly to do with whitespace. Substantive changes: 1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens 2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND One more Open Issue: I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions: - interface to register many fds at once - keep the list of fds in sorted order - use a dict to store fds and generate fdarry lazily - keep track of allocated length and used length for ufds, so that fewer reallocs are required Each of these suggestions has some added complexity, so I'm not sure that I like any of them. ------------------------------------------------------- Date: 2000-Jul-25 13:41 By: akuchling Comment: I wondered about the linear search, too; it means balancing efficiency versus the lines of code to write this one object? IMHO implementing both #1 and #3 would be good; allow passing an arbitrary # of fds to register (and unregister?), store them in a dict, and then lazily generate the ufd array when needed. Or is there some built-in more suited than a dict for this? Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors. ------------------------------------------------------- Date: 2000-Jul-25 14:40 By: jhylton Comment: I think a dict is the right data structure, but I don't think it should be exposed directly. If it is not exposed, then the ufd array need only be generated for poll calls after a register or unregister. If there are multiple polls without a change, the same array can be re-used. ------------------------------------------------------- Date: 2000-Aug-12 21:13 By: akuchling Comment: Latest version, which stores an underlying dict as suggested in jhylton's previous comment. p.unregister() raises KeyError if you unregister a fd that wasn't registered in the first place; seem reasonable? It does to me... The code should now be completed; the only remaining task is to write docstrings and finish the documentation patch. ------------------------------------------------------- Date: 2000-Aug-15 10:36 By: tim_one Comment: Tickling you as part of 2.0 nagging. Please leave a note saying when you intend to "write docstrings and finish the documentation". ------------------------------------------------------- Date: 2000-Aug-15 17:57 By: akuchling Comment: Revised version -- documentation & docstrings completed, and there's a test script (not part of patch). Ready to check in once someone gives the patch a quick once-over and sanity check. ------------------------------------------------------- Date: 2000-Aug-15 19:38 By: tim_one Comment: Assigned to Barry for a quick once-over and sanity check, as he's looking at the socket code and "select" also begins with an "s", while the "p" in "poll" doesn't show up in "Cravin' Dogs" at all! A natural fit. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 From noreply@sourceforge.net Wed Aug 16 03:49:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 19:49:56 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008160249.TAA11953@delerium.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Accepted Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 05:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 18:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 02:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 16:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 07:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-27 22:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 14:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- Date: 2000-Aug-08 22:26 By: tim_one Comment: Changed status to Rejected, but left assigned to me (I'll Open it again when it's updated). As I said at the bottom of my last comment on this, you cannot assume sizeof(short)==2: please get rid of the new big-endian/little-endian trickery. The code is not portable as-is. Even on machines where sizeof(short) does equal 2, shorts in the opcode stream are not guaranteed to be naturally aligned, and trying to access them as if they were can lead to anything from a core dump to an expensive trap to the OS to fix up the unaligned read. And on the only machines where this gimmick could actually pay (a little-endian machine where sizeof(short)==2 *and* the HW doesn't penalize unnatural alignment), the compiler should be smart enough to optimize the old expression for us. ------------------------------------------------------- Date: 2000-Aug-09 04:36 By: gvanrossum Comment: I think that all Tim wants is that you undo the changes you made to the NEXTARG() macro. ------------------------------------------------------- Date: 2000-Aug-10 14:51 By: cgw Comment: Understood. I've now put the NEXTARG macro back to its original form; sorry for overlooking this on the previous pass. ------------------------------------------------------- Date: 2000-Aug-10 21:25 By: tim_one Comment: Changed to Open and assigned to Vladimir. Vlad, have any comments on this? Care to test it? I'm inclined to accept it now "by eyeball", because it does fix some bugs. ------------------------------------------------------- Date: 2000-Aug-12 09:54 By: marangoz Comment: Yes, comments: there are things I like and others I don't really like. The tactics here is to remove the 2-byte integral type limit and replace it with sizeof(int). On some systems, sizeof(int) == 8, so I don't see a reason for generating only one EXTENDED_ARG opcode if the arg exceeds 2 bytes. If the arg exceeds 4 bytes, let the code generate more 2-byte arg slices, i.e. several EXTENDED_ARG in a row. Costs nothing. Overall, we both converged on the same solution. Things I like: - the fix in node.h (short -> int) - the error check in com_backpatch Things I don't really like: - the removal of E_OVERFLOW and associated checks I'd suggest using int types in node.h (instead of unsigned int) and change the existing short checks with int checks (with INT_MAX) - the label "extended_arg" in ceval.c. (after the oparg fetch) It should be really be named "dispatch_opcode". I'd suggest integrating the com_oparg & ceval's case EXTENDED_ARG code that I've posted to python-dev and adjust the rest accordingly. http://www.python.org/pipermail/python-dev/2000-August/014604.html Overall, it looks okay. I'll test it when the things I don't really like are gone. (the Python code seems to be somewhat more complex than it should be, though...) Can we get another patch from the author? Otherwise I'll try to make some time to relay this. ------------------------------------------------------- Date: 2000-Aug-15 10:29 By: tim_one Comment: Charles, do you have anything to say to Vladimir's comments? I don't see a need to have an indefinitely-extensible extended opcode gimmick today. What you already did solves real problems now, and indeed the only real problems in this area we've ever seen. I want to get that into 2.0. That doesn't preclude Vlad extending it again later. But I agree that removing the overflow checks was a bad decision. If we ever *do* bump into a case where more than what you've done is needed, Python will silently go insane. So if you can fix that much, I'll accept the patch for 2.0 immediately after. Agree too that "dispatch_opcode" is a clearer name for the label than "extended_arg". ------------------------------------------------------- Date: 2000-Aug-15 13:45 By: cgw Comment: You know, I've been fooling around with this silly little patch for quite a while. And about 3 months ago I had developed a version where you could stack up the EXTENDED_ARG opcodes, and also where I had dealt with the "offset too big" problem in com_backpatch by inserting some EXTENDED_ARGS and then relocating the subsequent code, by walking through and fixing up offsets. It worked, but it was rather hairy and slow and I convinced myself that such a patch would simply *never*get accepted. So I simplified it down as much as possible to solve the actual problem that we were having here at FNAL. I didn't really decide to take out the overflow checks, it's just that my patch pre-dated their addition. I'm uploading a new version which restores the overflow checks and renames the label as per your wishes. ------------------------------------------------------- Date: 2000-Aug-15 19:49 By: tim_one Comment: Accepted and assigned to Fred Drake for checkin. Sorry again, Fred! I'll get a patch that works one of these days (the Cygwin stuff works fine, but I can't afford the download time!). And, Charles, thank you for patience and good humor during this long ordeal. It's appreciated! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Wed Aug 16 07:36:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 23:36:02 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008160636.XAA18957@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 13:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 14:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-15 23:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Wed Aug 16 07:41:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 23:41:17 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008160641.XAA19143@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 13:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 14:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-15 23:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-15 23:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Wed Aug 16 07:42:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 23:42:30 -0700 Subject: [Patches] [Patch #101121] cosmetic cleanup of cgi.py, using Guido's style conventions Message-ID: <200008160642.XAA19230@delerium.i.sourceforge.net> Patch #101121 has been updated. Project: Category: library Status: Open Summary: cosmetic cleanup of cgi.py, using Guido's style conventions Follow-Ups: Date: 2000-Aug-08 13:37 By: ping Comment: This is an immediate follow-on to #101120 (i just wanted to keep the semantic and non-semantic changes separate). ------------------------------------------------------- Date: 2000-Aug-15 15:06 By: tim_one Comment: I'm not sure what you mean by "follow-on". If this patch is *independent* of 101120, just Accept it yourself and check it in -- there's no need to go thru a review process for mechanical cleanup. Assigning to you on that basis. Ah, and you *can* check it in, in about 6 hours: you've been added to the Python project as a Developer. That means I get to assign patches to you for review, too From noreply@sourceforge.net Wed Aug 16 08:28:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 00:28:24 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008160728.AAA20821@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 13:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 14:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-15 23:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-15 23:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 00:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Wed Aug 16 08:34:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 00:34:41 -0700 Subject: [Patches] [Patch #101121] cosmetic cleanup of cgi.py, using Guido's style conventions Message-ID: <200008160734.AAA21038@delerium.i.sourceforge.net> Patch #101121 has been updated. Project: Category: library Status: Open Summary: cosmetic cleanup of cgi.py, using Guido's style conventions Follow-Ups: Date: 2000-Aug-08 13:37 By: ping Comment: This is an immediate follow-on to #101120 (i just wanted to keep the semantic and non-semantic changes separate). ------------------------------------------------------- Date: 2000-Aug-15 15:06 By: tim_one Comment: I'm not sure what you mean by "follow-on". If this patch is *independent* of 101120, just Accept it yourself and check it in -- there's no need to go thru a review process for mechanical cleanup. Assigning to you on that basis. Ah, and you *can* check it in, in about 6 hours: you've been added to the Python project as a Developer. That means I get to assign patches to you for review, too From noreply@sourceforge.net Wed Aug 16 08:40:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 00:40:57 -0700 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <200008160740.AAA21220@delerium.i.sourceforge.net> Patch #100938 has been updated. Project: Category: None Status: Open Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2000-Jul-19 14:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 10:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-16 00:40 By: moshez Comment: I suggest we postpone it. It isn't really complete (only works on real distributions ), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From noreply@sourceforge.net Wed Aug 16 10:16:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 02:16:53 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008160916.CAA05509@bush.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 13:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 14:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-15 23:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-15 23:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 00:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 02:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Wed Aug 16 10:35:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 02:35:56 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008160935.CAA24745@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Accepted Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 13:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 14:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-15 23:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-15 23:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 00:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 02:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 02:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Wed Aug 16 13:53:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 05:53:11 -0700 Subject: [Patches] [Patch #101196] IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 Message-ID: <200008161253.FAA31453@delerium.i.sourceforge.net> Patch #101196 has been updated. Project: Category: core (C code) Status: Open Summary: IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101196&group_id=5470 From noreply@sourceforge.net Wed Aug 16 14:07:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 06:07:48 -0700 Subject: [Patches] [Patch #101196] IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 Message-ID: <200008161307.GAA13733@bush.i.sourceforge.net> Patch #101196 has been updated. Project: Category: core (C code) Status: Open Summary: IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 Follow-Ups: Date: 2000-Aug-16 05:59 By: itojun Comment: this is revised version of patch #101186 (now with my SourceForge accout... i'm not familiar with the system here, so forgive my possible mistake). 1.6b1 patch applied mostly clean to 2.0. It is confirmed that: - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5 - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine) - 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME forgot to attach the following into the diff - so i attach it (README.v6) here as comment. I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1, all hit a bad timing - bad luck. contact: core@kame.net, or itojun@kame.net --- IPv6-ready python 1.6 KAME Project $KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $ This patchkit enables python 1.6 to perform AF_INET6 socket operations. The only affected module is Modules/socketmodule.c. Modules/socketmodule.c In most cases, IPv6 address can be placed where IPv4 address fits. sockaddr sockaddr tuple is formatted as follows: IPv4: (host, port) IPv6: socket class methods always generate (host, port, flowinfo, scopeid). socket class methods will accept 2, 3, or 4 tuple (for backward compatibility). Compatibility warning: Some of the scripts assume that the sockaddr structure is 2 tuple, like: host, port = sock.getpeername() this will fail if you are connected to IPv6 node. socket.getaddrinfo(host, port [, family, socktype, proto, flags]) host: String or None port: String, Int or None family, socktype, proto, flags: Int, can be omitted Perform getaddrinfo(3). Returns List of the following 5 tuple: (family, socktype, proto, canonname, sockaddr) family: Int socktype: Int proto: Int canonname: String sockaddr: sockaddr (see above) See Lib/httplib.py for typical usage on the client side. socket.getnameinfo(sockaddr, flags) sockaddr: sockaddr flags: Int Perform getnameinfo(3). Returns the following 2 tuple: host: String, numeric or hostname depending on flgags port: String, numeric or portname depending on flgags socket.gethostbyname2(host, af) host: String af: Int Performs gethostbyname2(3). Returns numeric address representation for "host". socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in) addr: String Performs gethostbyaddr(3). Returns string address representation for "addr". The function can take IPv6 numeric address as well. This behavior is not problematical, because - if you pass numeric "addr" parameter, we can always identify address family for it - return value is string address reprsentation, where IPv6 and IPv4 are not distinguishable. socket.bind(sa), socket.connect(sa) and others. (No behavior change, but be careful) See above for sockaddr format change. With Python "addr" portion of sockaddr (first element) can be string hostname. When the string hostname resolved to numeric address, it will obey address family of the socket (which was specified when socket.socket() was called). If you give some string that does not give matching address family, you will get some error. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # this is okay, if 'localhost' resolves to both IPv4/v6 s.connect('localhost', 80) # this is not okay, of course s.connect('::1', 80) # this is not okay, as v6only.kame.net will not resolve to IPv4 s.connect('v6only.kame.net', 80) Lib/httplib.py IPv6 ready. "host" in HTTP(host) will accept the following 3 forms: [host]:port host:port there must be only single colon host This is to allow IPv6 numeric URL (http://[host]:port/) in documents. IMHO "host:port" parsing should be implemented in urllib.py, not here. Lib/ftplib.py IPv6 ready. This uses EPSV/EPRT on IPv6 ftp. See RFC2428 for protocol details. Lib/SocketServer.py IPv6 ready. Wildcard bind on TCPServer, i.e. TCPServer(('', port)), will bind to wildcard socket on TCPServer.address_family. TCPServer.addresss_family is set to AF_INET by default, so ('', port) will usually bind AF_INET. Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py IPv6 ready. Not much to say about protocol details - they just use TCP over IPv6. configure Configure has extra option, --enable-ipv6 and --disable-ipv6. The option controls IPv6 support feature. dynamic link issues in Modules/socketmodule.c Modules/socketmodule.c can be dynamically loaded only in the following situations: - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in libc, and libc is dynamic link library. - OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and You are configuring this package with --disable-ipv6. In this case, you'll be using missing/get{addr,name}info.c and they will refer to gethostby{name,addr}. gethostnameby{name,addr} can usually be found in dynamic-linking libc. In other situations, such as the following, please link Modules/socketmodule.c into python itself. - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but they are in statically linked library like libinet6.a. (KAME falls into this category) python usually links Modules/socketmodule.c into python itself (due to its popularity) so there should be no problem. restrictions - The patched tree will not use gethostbyname_r and other thread-ready libraries. Instead, it will use getaddrinfo() and getnameinfo() throughout the operation. todo - Patch bunch of library files in Lib/*.py. compatibility issues with existing scripts If you disable IPv6 support (./configure --disable-ipv6), the patched code is mostly compatible with original Python (except files in "Lib" directory modified for dual stack support). User script may choke if: - IPv4/v6 dualstack libc is supplied, python is compiled for dual stack, and script assumes some of IPv4-only behavior (especially sockaddr) - IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only, and script assumes some of IPv4-only behavior. In this case, Python socket class itself does not support IPv6, however, name resolution functions can return IPv6 names since they use IPv6-ready libc functions! I do not recommend this configuration. - script assumes certain IPv4-only version behavior in Lib/*.py. compilation If you use IPv6 features, it is assumed that you have working getaddrinfo() and getnameinfo() library functions. We have noticed that some of IPv6 stack is shipped with broken getaddrinfo(). In such cases, use missing/get{addr,name}info.c instead (but then, you need to have working getipnodeby{name,addr}). If you compile this on IPv4-only machine without get{addr,name}info, missing/get{addr,name}info.c will be used. They are from KAME IPv6 distribution and is #ifdef'ed for IPv4 only support. They are fairly complete implementation and you don't need to bother with bind 8.2 (bind 8.2 get{addr,name}info() has bugs). When compiling this kit on IPv6 node, you may need to specify some additional library paths or cpp defs. (like -linet6 or -DINET6) --enable-ipv6 will give you some warning, if the IPv6 stack is unknown to the "configure" script. Currently, the following IPv6 stacks are officially supported (i.e. we've checked that the package works well): - KAME IPv6 stack, http://www.kame.net/ References RFC2553, for getaddrinfo(3) and getnameinfo(3). Author contacts http://www.kame.net/ mailto:core@kame.net ------------------------------------------------------- Date: 2000-Aug-16 06:07 By: moshez Comment: Assigned to Tim, since he's in charge of postponing new features. I'm to timid to postpone it myself. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101196&group_id=5470 From noreply@sourceforge.net Wed Aug 16 15:00:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 07:00:23 -0700 Subject: [Patches] [Patch #101196] IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 Message-ID: <200008161400.HAA15652@bush.i.sourceforge.net> Patch #101196 has been updated. Project: Category: core (C code) Status: Postponed Summary: IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 Follow-Ups: Date: 2000-Aug-16 05:59 By: itojun Comment: this is revised version of patch #101186 (now with my SourceForge accout... i'm not familiar with the system here, so forgive my possible mistake). 1.6b1 patch applied mostly clean to 2.0. It is confirmed that: - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5 - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine) - 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME forgot to attach the following into the diff - so i attach it (README.v6) here as comment. I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1, all hit a bad timing - bad luck. contact: core@kame.net, or itojun@kame.net --- IPv6-ready python 1.6 KAME Project $KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $ This patchkit enables python 1.6 to perform AF_INET6 socket operations. The only affected module is Modules/socketmodule.c. Modules/socketmodule.c In most cases, IPv6 address can be placed where IPv4 address fits. sockaddr sockaddr tuple is formatted as follows: IPv4: (host, port) IPv6: socket class methods always generate (host, port, flowinfo, scopeid). socket class methods will accept 2, 3, or 4 tuple (for backward compatibility). Compatibility warning: Some of the scripts assume that the sockaddr structure is 2 tuple, like: host, port = sock.getpeername() this will fail if you are connected to IPv6 node. socket.getaddrinfo(host, port [, family, socktype, proto, flags]) host: String or None port: String, Int or None family, socktype, proto, flags: Int, can be omitted Perform getaddrinfo(3). Returns List of the following 5 tuple: (family, socktype, proto, canonname, sockaddr) family: Int socktype: Int proto: Int canonname: String sockaddr: sockaddr (see above) See Lib/httplib.py for typical usage on the client side. socket.getnameinfo(sockaddr, flags) sockaddr: sockaddr flags: Int Perform getnameinfo(3). Returns the following 2 tuple: host: String, numeric or hostname depending on flgags port: String, numeric or portname depending on flgags socket.gethostbyname2(host, af) host: String af: Int Performs gethostbyname2(3). Returns numeric address representation for "host". socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in) addr: String Performs gethostbyaddr(3). Returns string address representation for "addr". The function can take IPv6 numeric address as well. This behavior is not problematical, because - if you pass numeric "addr" parameter, we can always identify address family for it - return value is string address reprsentation, where IPv6 and IPv4 are not distinguishable. socket.bind(sa), socket.connect(sa) and others. (No behavior change, but be careful) See above for sockaddr format change. With Python "addr" portion of sockaddr (first element) can be string hostname. When the string hostname resolved to numeric address, it will obey address family of the socket (which was specified when socket.socket() was called). If you give some string that does not give matching address family, you will get some error. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # this is okay, if 'localhost' resolves to both IPv4/v6 s.connect('localhost', 80) # this is not okay, of course s.connect('::1', 80) # this is not okay, as v6only.kame.net will not resolve to IPv4 s.connect('v6only.kame.net', 80) Lib/httplib.py IPv6 ready. "host" in HTTP(host) will accept the following 3 forms: [host]:port host:port there must be only single colon host This is to allow IPv6 numeric URL (http://[host]:port/) in documents. IMHO "host:port" parsing should be implemented in urllib.py, not here. Lib/ftplib.py IPv6 ready. This uses EPSV/EPRT on IPv6 ftp. See RFC2428 for protocol details. Lib/SocketServer.py IPv6 ready. Wildcard bind on TCPServer, i.e. TCPServer(('', port)), will bind to wildcard socket on TCPServer.address_family. TCPServer.addresss_family is set to AF_INET by default, so ('', port) will usually bind AF_INET. Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py IPv6 ready. Not much to say about protocol details - they just use TCP over IPv6. configure Configure has extra option, --enable-ipv6 and --disable-ipv6. The option controls IPv6 support feature. dynamic link issues in Modules/socketmodule.c Modules/socketmodule.c can be dynamically loaded only in the following situations: - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in libc, and libc is dynamic link library. - OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and You are configuring this package with --disable-ipv6. In this case, you'll be using missing/get{addr,name}info.c and they will refer to gethostby{name,addr}. gethostnameby{name,addr} can usually be found in dynamic-linking libc. In other situations, such as the following, please link Modules/socketmodule.c into python itself. - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but they are in statically linked library like libinet6.a. (KAME falls into this category) python usually links Modules/socketmodule.c into python itself (due to its popularity) so there should be no problem. restrictions - The patched tree will not use gethostbyname_r and other thread-ready libraries. Instead, it will use getaddrinfo() and getnameinfo() throughout the operation. todo - Patch bunch of library files in Lib/*.py. compatibility issues with existing scripts If you disable IPv6 support (./configure --disable-ipv6), the patched code is mostly compatible with original Python (except files in "Lib" directory modified for dual stack support). User script may choke if: - IPv4/v6 dualstack libc is supplied, python is compiled for dual stack, and script assumes some of IPv4-only behavior (especially sockaddr) - IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only, and script assumes some of IPv4-only behavior. In this case, Python socket class itself does not support IPv6, however, name resolution functions can return IPv6 names since they use IPv6-ready libc functions! I do not recommend this configuration. - script assumes certain IPv4-only version behavior in Lib/*.py. compilation If you use IPv6 features, it is assumed that you have working getaddrinfo() and getnameinfo() library functions. We have noticed that some of IPv6 stack is shipped with broken getaddrinfo(). In such cases, use missing/get{addr,name}info.c instead (but then, you need to have working getipnodeby{name,addr}). If you compile this on IPv4-only machine without get{addr,name}info, missing/get{addr,name}info.c will be used. They are from KAME IPv6 distribution and is #ifdef'ed for IPv4 only support. They are fairly complete implementation and you don't need to bother with bind 8.2 (bind 8.2 get{addr,name}info() has bugs). When compiling this kit on IPv6 node, you may need to specify some additional library paths or cpp defs. (like -linet6 or -DINET6) --enable-ipv6 will give you some warning, if the IPv6 stack is unknown to the "configure" script. Currently, the following IPv6 stacks are officially supported (i.e. we've checked that the package works well): - KAME IPv6 stack, http://www.kame.net/ References RFC2553, for getaddrinfo(3) and getnameinfo(3). Author contacts http://www.kame.net/ mailto:core@kame.net ------------------------------------------------------- Date: 2000-Aug-16 06:07 By: moshez Comment: Assigned to Tim, since he's in charge of postponing new features. I'm to timid to postpone it myself. ------------------------------------------------------- Date: 2000-Aug-16 07:00 By: fdrake Comment: Postponed until Python 2.1 -- there's not enough time to review this and get it sufficiently tested on enough IPv6-connected platforms in time for 2.0, and we're already in feature freeze. This should go into the tree very quickly once Python 2.0 has been released. Assigned to myself to open it back up after Python 2.0. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101196&group_id=5470 From noreply@sourceforge.net Wed Aug 16 15:56:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 07:56:55 -0700 Subject: [Patches] [Patch #100970] extended print statement Message-ID: <200008161456.HAA03615@delerium.i.sourceforge.net> Patch #100970 has been updated. Project: Category: core (C code) Status: Open Summary: extended print statement Follow-Ups: Date: 2000-Jul-23 19:44 By: bwarsaw Comment: This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout). This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement. An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM. I'm not sure which approach is better. ------------------------------------------------------- Date: 2000-Jul-23 19:45 By: bwarsaw Comment: The following is an example of how you might use the new extended print statement. 
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
------------------------------------------------------- Date: 2000-Aug-15 11:00 By: tim_one Comment: Assigned to Guido for Pronouncement. This was already discussed on Python-Dev. Mix of opinions there. I like it fine. Barry, this needs docs and test cases Real Soon if you want it considered for 2.0. I like the PRINT_TO idea better. ------------------------------------------------------- Date: 2000-Aug-15 15:43 By: bwarsaw Comment: Revised patch which uses the PRINT_ITEM_TO approach favored by Tim. This patch also includes doc and test suite updates. Please see PEP 214 for a discussion of the issues. This feature should be postponed until Python 2.1 ------------------------------------------------------- Date: 2000-Aug-15 16:05 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-15 16:16 By: bwarsaw Comment: Okay, I just thought that with the open issue (see PEP 214) it might not be ready for prime time. Let's wait for the BDFL pronounce before postponing. ------------------------------------------------------- Date: 2000-Aug-15 16:33 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-16 07:56 By: bwarsaw Comment: After channeling and encouragement from Tim, this patch represents the current definition of the feature as described in PEP 214. It is now ready for BDFL pronouncement for Python 2.0. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470 From noreply@sourceforge.net Wed Aug 16 17:13:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 09:13:03 -0700 Subject: [Patches] [Patch #101197] use socket.getfqdn where appropriate Message-ID: <200008161613.JAA06490@delerium.i.sourceforge.net> Patch #101197 has been updated. Project: Category: None Status: Open Summary: use socket.getfqdn where appropriate ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101197&group_id=5470 From noreply@sourceforge.net Wed Aug 16 17:14:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 09:14:24 -0700 Subject: [Patches] [Patch #101197] use socket.getfqdn where appropriate Message-ID: <200008161614.JAA06529@delerium.i.sourceforge.net> Patch #101197 has been updated. Project: Category: library Status: Open Summary: use socket.getfqdn where appropriate Follow-Ups: Date: 2000-Aug-16 09:14 By: nowonder Comment: update for library to use socket.getfqdn ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101197&group_id=5470 From noreply@sourceforge.net Wed Aug 16 17:22:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 09:22:01 -0700 Subject: [Patches] [Patch #101197] use socket.getfqdn where appropriate Message-ID: <200008161622.JAA06846@delerium.i.sourceforge.net> Patch #101197 has been updated. Project: Category: library Status: Open Summary: use socket.getfqdn where appropriate Follow-Ups: Date: 2000-Aug-16 09:14 By: nowonder Comment: update for library to use socket.getfqdn ------------------------------------------------------- Date: 2000-Aug-16 09:22 By: nowonder Comment: ideas: * could socket.getfqdn() accept '0.0.0.0' for the local host? * import x as y would be VERY nice ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101197&group_id=5470 From guido@beopen.com Wed Aug 16 17:38:41 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 16 Aug 2000 12:38:41 -0400 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py References: <200008151849.LAA26752@delerium.i.sourceforge.net> <14745.37595.507937.752085@cj42289-a.reston1.va.home.com> Message-ID: <00a701c007a1$cfa06ba0$6401000a@beopen.com> > Is there some reason we don't go ahead and change socket to _socket? > As Barry rightly pointed out, that's already how it is for some > (popular) platforms. Let's not do this for 2.0. --Guido From nowonder@nowonder.de Wed Aug 16 20:03:51 2000 From: nowonder@nowonder.de (Peter Schneider-Kamp) Date: Wed, 16 Aug 2000 19:03:51 +0000 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py References: <200008151849.LAA26752@delerium.i.sourceforge.net> <14745.37595.507937.752085@cj42289-a.reston1.va.home.com> <00a701c007a1$cfa06ba0$6401000a@beopen.com> Message-ID: <399AE597.9C093569@nowonder.de> Guido van Rossum wrote: > > > Is there some reason we don't go ahead and change socket to _socket? > > As Barry rightly pointed out, that's already how it is for some > > (popular) platforms. > > Let's not do this for 2.0. Why? it's-already-checked-in---but-that's-not-an-argument-,-of-course-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From guido@beopen.com Wed Aug 16 18:19:34 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 16 Aug 2000 13:19:34 -0400 Subject: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py Message-ID: <014e01c007a6$38252d60$6401000a@beopen.com> OK, never mind. It's already checked in, so forget my "-0" vote. We'll see how it works out in practice. --Guido ----- Original Message ----- From: "Guido van Rossum" To: "Fred L. Drake, Jr." Cc: ; ; Sent: Wednesday, August 16, 2000 12:38 PM Subject: Re: [Patches] [Patch #101151] expose public get_fqdn function in smtplib.py > > Is there some reason we don't go ahead and change socket to _socket? > > As Barry rightly pointed out, that's already how it is for some > > (popular) platforms. > > Let's not do this for 2.0. > > --Guido > > > From noreply@sourceforge.net Wed Aug 16 20:02:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 12:02:36 -0700 Subject: [Patches] [Patch #101176] add dummy 'add2lib' target to Grammar/Makefile Message-ID: <200008161902.MAA12828@delerium.i.sourceforge.net> Patch #101176 has been updated. Project: Category: Build Status: Closed Summary: add dummy 'add2lib' target to Grammar/Makefile Follow-Ups: Date: 2000-Aug-13 12:28 By: tmick Comment: On the UNIX build, the master makefile makes the 'add2lib' target in each subdir. This now includes Grammar, which currently has no 'add2lib' target. gmake reports: make VERSION=2.0 add2lib make[1]: Entering directory `/home/trentm/tmp/python.perliumdiff/python/dist/src/Grammar' make[1]: *** No rule to make target `add2lib'. Stop. make[1]: Leaving directory `/home/trentm/tmp/python.perliumdiff/python/dist/src/Grammar' and keeps going. Some other makes (e.g. the make on Monterey, other Unices?) just die. ------------------------------------------------------- Date: 2000-Aug-15 11:02 By: tim_one Comment: Accepted and assigned back to Trent for checkin. If it breaks something, tell people to yell at me . ------------------------------------------------------- Date: 2000-Aug-16 12:02 By: tmick Comment: checked in and closed ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101176&group_id=5470 From noreply@sourceforge.net Wed Aug 16 20:05:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 12:05:06 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200008161905.MAA12997@delerium.i.sourceforge.net> Patch #101162 has been updated. Project: Category: Build Status: Open Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. ------------------------------------------------------- Date: 2000-Aug-15 15:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- Date: 2000-Aug-16 12:05 By: tmick Comment: re: delaying to 2.1: doesn't bother me much Should it now be "postponed", Tim? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Wed Aug 16 21:06:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 13:06:53 -0700 Subject: [Patches] [Patch #101197] use socket.getfqdn where appropriate Message-ID: <200008162006.NAA29363@bush.i.sourceforge.net> Patch #101197 has been updated. Project: Category: library Status: Accepted Summary: use socket.getfqdn where appropriate Follow-Ups: Date: 2000-Aug-16 09:14 By: nowonder Comment: update for library to use socket.getfqdn ------------------------------------------------------- Date: 2000-Aug-16 09:22 By: nowonder Comment: ideas: * could socket.getfqdn() accept '0.0.0.0' for the local host? * import x as y would be VERY nice ------------------------------------------------------- Date: 2000-Aug-16 13:06 By: fdrake Comment: Go ahead and check it in. Yes, 0.0.0.0 could be accepted as for the local host. Just check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101197&group_id=5470 From noreply@sourceforge.net Wed Aug 16 21:30:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 13:30:55 -0700 Subject: [Patches] [Patch #101197] use socket.getfqdn where appropriate Message-ID: <200008162030.NAA30199@bush.i.sourceforge.net> Patch #101197 has been updated. Project: Category: library Status: Closed Summary: use socket.getfqdn where appropriate Follow-Ups: Date: 2000-Aug-16 09:14 By: nowonder Comment: update for library to use socket.getfqdn ------------------------------------------------------- Date: 2000-Aug-16 09:22 By: nowonder Comment: ideas: * could socket.getfqdn() accept '0.0.0.0' for the local host? * import x as y would be VERY nice ------------------------------------------------------- Date: 2000-Aug-16 13:06 By: fdrake Comment: Go ahead and check it in. Yes, 0.0.0.0 could be accepted as for the local host. Just check it in. ------------------------------------------------------- Date: 2000-Aug-16 13:30 By: nowonder Comment: checked it in with addition of '0.0.0.0' ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101197&group_id=5470 From noreply@sourceforge.net Thu Aug 17 13:17:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 05:17:00 -0700 Subject: [Patches] [Patch #101207] BeOS: installing of linker script Message-ID: <200008171217.FAA15958@delerium.i.sourceforge.net> Patch #101207 has been updated. Project: Category: None Status: Open Summary: BeOS: installing of linker script ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101207&group_id=5470 From noreply@sourceforge.net Thu Aug 17 14:44:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 06:44:13 -0700 Subject: [Patches] [Patch #101208] Add parens to zipfile.py to fix file time seconds bug Message-ID: <200008171344.GAA18891@delerium.i.sourceforge.net> Patch #101208 has been updated. Project: Category: Modules Status: Open Summary: Add parens to zipfile.py to fix file time seconds bug ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101208&group_id=5470 From noreply@sourceforge.net Thu Aug 17 20:02:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 12:02:15 -0700 Subject: [Patches] [Patch #101178] add items() method to listobject Message-ID: <200008171902.MAA11887@bush.i.sourceforge.net> Patch #101178 has been updated. Project: Category: core (C code) Status: Rejected Summary: add items() method to listobject Follow-Ups: Date: 2000-Aug-14 02:23 By: nowonder Comment: This patch adds a .items() method to the list object. .items() returns a list with of tuples. E.g.: for index, value in ["a", "b", "c"].items(): print index, ":", value will print: 0: a 1: b 2: c I think this is an easy way to achieve looping over index AND elements in parallel. Semantically the following two expressions should be equivalent: for index, value in zip(range(len(mylist)), mylist): for index, value in mylist.items(): In opposition to patch #110138 I would call this: "Adding syntactic sugar without adding syntax (or sugar):" ------------------------------------------------------- Date: 2000-Aug-14 02:36 By: nowonder Comment: just two comments: strings (and maybe tuples) could also support .items(). There could be a function PySequence_Items in abstract.c. BTW: test case and documentation lacking. If this is considered to be a Good Idea(tm), I'll happily supply them. ------------------------------------------------------- Date: 2000-Aug-15 18:04 By: tim_one Comment: Assigned to Guido for Pronouncement. ------------------------------------------------------- Date: 2000-Aug-15 20:11 By: nowonder Comment: Note: tim (I believe) said that items() would mean there would have to be key() and value(), too. I disagree. index() and value(), maybe. But key() does not make any sense for a list. I see the issue with execution speed and memory overhead though, so as I am not really opposed to 'for index indexing value in sequence' I would be okay with that. In any case it would be nice to have some way to express this. ------------------------------------------------------- Date: 2000-Aug-17 19:02 By: gvanrossum Comment: I don't like this idea at all. There is not enough similarity between dicts and lists to do this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101178&group_id=5470 From noreply@sourceforge.net Thu Aug 17 20:10:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 12:10:18 -0700 Subject: [Patches] [Patch #101138] 'for i indexing a in l': exposing the for-loop counter Message-ID: <200008171910.MAA12229@bush.i.sourceforge.net> Patch #101138 has been updated. Project: Category: core (C code) Status: Rejected Summary: 'for i indexing a in l': exposing the for-loop counter Follow-Ups: Date: 2000-Aug-09 22:10 By: twouters Comment: This patch adds a way to get the loop counter in Python for-loops. The syntax is one Just quoted on python-dev today, which he attributes to Tim (and was probably proposed by half the thinking Python community by now ;) It's a quick and dirty hack, but it works. There might be refcounting bugs and much more efficient ways to do it, but it works ;) It also lacks a test case and documentation. ------------------------------------------------------- Date: 2000-Aug-11 07:27 By: hooft Comment: Do we need a new keyword for this functionality, or can we use zip? Maybe adding zip-magic would help, but: >>> a=['a','b','c','d'] >>> for i,el in zip(xrange(9999999),a): ... print i,el ... 0 a 1 b 2 c 3 d ------------------------------------------------------- Date: 2000-Aug-11 07:33 By: hooft Comment: Or: >>> class indexing: ... def __init__(self,a): ... self.data=a ... def __getitem__(self,i): ... return i,self.data[i] ... >>> for i,el in indexing(a): ... print i,el ... 0 a 1 b 2 c 3 d >>> ------------------------------------------------------- Date: 2000-Aug-11 07:38 By: twouters Comment: The patch exposes the already-present loop counter to python code, rather than just adding a list of ranges to loop over. That is one of the reasons to make it a syntactic change: other techniques to use the builtin loop counter would require psychic interpreters ;) The patch does *not* introduce a new keyword, by the way. the 'indexing' name is just a NAME, not a real keyword, and can be used as a variable just fine. ------------------------------------------------------- Date: 2000-Aug-14 02:32 By: nowonder Comment: I think that using the builtin loop counter would be nice. But I don't see this justifying extra syntax. Paul Prescod's suggestion of adding .items() to lists seems more natural to me. ------------------------------------------------------- Date: 2000-Aug-15 22:19 By: tim_one Comment: Assigned to Guido for Pronouncement, as this is the last chance he'll ever have to end the blood feud with his brother . ------------------------------------------------------- Date: 2000-Aug-17 19:10 By: gvanrossum Comment: Don't like it. Have to admit, in 'for i indexing a in l' I have no intuition about what i and a are! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101138&group_id=5470 From noreply@sourceforge.net Thu Aug 17 20:13:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 12:13:52 -0700 Subject: [Patches] [Patch #101135] 'import x as y' and 'from x import y as z' Message-ID: <200008171913.MAA12393@bush.i.sourceforge.net> Patch #101135 has been updated. Project: Category: core (C code) Status: Accepted Summary: 'import x as y' and 'from x import y as z' Follow-Ups: Date: 2000-Aug-09 20:23 By: twouters Comment: This patch adds the oft-proposed 'import as' syntax, to both 'import module' and 'from module import ...', but without making 'as' a reserved word (by using the technique Tim Peters proposed on python-dev.) 'import spam as egg' is a very simple patch to compile.c, which doesn't need changes to the VM, but 'from spam import dog as meat' needs a new bytecode, which this patch calls 'FROM_IMPORT_AS'. The bytecode loads an object from a module onto the stack, so a STORE_NAME can store it later. This can't be done by the normal FROM_IMPORT opcode, because it needs to take the special case of '*' into account. Also, because it uses 'STORE_NAME', it's now possible to mix 'import' and 'global', like so: global X from foo import X as X The patch still generates the old code for from foo import X (without 'as') mostly to save on bytecode size, and for the 'compatibility' with mixing 'global' and 'from .. import'... I'm not sure what's the best thing to do. The patch doesn't include a test suite or documentation, yet. ------------------------------------------------------- Date: 2000-Aug-11 22:04 By: twouters Comment: I now think the best thing to do is to split the 'IMPORT_FROM' opcode into two opcodes: 'IMPORT_ALL', which is used for 'from module import *', and 'IMPORT_FROM' (or another name, if that's desired) which loads a single name. IMPORT_ALL would store the retrieved objects into the local namespace directly, like IMPORT_FROM currently does; it doesn't use the stack other than to retrieve the module it loads the symbols from. IMPORT_FROM would act more like 'IMPORT_NAME', in that the object retrieved from the module is not stored directly in the local namespace, but instead pushed on the stack (that's what the IMPORT_FROM_AS bytecode in the current patch does) -- that means that for all normal 'from' imports, a STORE is generated, and a 'global' works on them just like with normal variable assignment. In the current patch, this is only true for 'from module import x as y' statements, not for the normal form. Assigned to Guido, since it's ultimately his decision (everyone else already voted ;-) ------------------------------------------------------- Date: 2000-Aug-15 22:12 By: tim_one Comment: Reminding Guido this is still on his plate. Thomas, I agree with you that splitting IMPORT_FROM is a good idea -- the "*" and "name" cases are indeed very different. Since Guido hasn't gotten to this yet, how about changing the patch before he notices? The votes you got before were based on the visible semantics, not the implementation, so no need to vote again. ------------------------------------------------------- Date: 2000-Aug-15 22:25 By: twouters Comment: Actually, I finished an updated patch that did that about two hours ago, but Blackadder intervened, and I forgot to upload it afterwards :P This patch does not contain doc changes or test cases yet, but the changes to the core are finished, as far as I'm concerned. I'll try to finish the docs and tests tomorrow. (I have to say this is the first patch where the doc changes look more attractive than the test case. I need to start a syntax-highlighting editor just to be able to *read* test_pkg, let alone extend it ;) ------------------------------------------------------- Date: 2000-Aug-17 19:13 By: gvanrossum Comment: Go for it. This is a scary precedent (a new keyword without keyword status) but I think the basic proposal is good. I haven't reviewed the quality of the patch, but I presume it's been checked by others (and it can always be fixed later). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470 From noreply@sourceforge.net Thu Aug 17 20:18:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 12:18:15 -0700 Subject: [Patches] [Patch #101029] Call __getitem__ for slices when no __getslice__ Message-ID: <200008171918.MAA12556@bush.i.sourceforge.net> Patch #101029 has been updated. Project: Category: core (C code) Status: Accepted Summary: Call __getitem__ for slices when no __getslice__ Follow-Ups: Date: 2000-Jul-31 13:55 By: twouters Comment: Call __getitem__ if no __getslice__ is available. similar for __delslice__ and __setslice__, and for the C API: calls mp_subscript() with a slice object of (start, end, None) if there is no sq_slice(), and the same for sq_ass_slice(). Eventually the reverse should be done, too: call __getslice__ instead of __getitem__ if the object has a __getslice__, and the 3rd argument to the slice is None: That way, we can ditch the 12 silly SLICE* opcodes, and always use slice objects. This *will* result in x[::] being passed to __getslice__ (if available) instead of __getitem__, however, so it is not 100% backwards compatible. This patch is not terribly tested: I'm not feeling well, and I want to post this patch before I head off to home and dive back in bed ;) It doesn't crash, it survives 'make test', it survives manual testing, but it might leak. ------------------------------------------------------- Date: 2000-Jul-31 14:55 By: gvanrossum Comment: Looks cool to me, except that there's a lot of code duplication. Maybe you can add a static helper routine to create a slice out of two ints to abstract.c and one that creates a 1-tuple containing such a slice to classobject.c. (Trying to share code across .c files would require turning it into an official API which I think is overkill.) ------------------------------------------------------- Date: 2000-Jul-31 21:35 By: twouters Comment: New version with less code duplication. Less, not none, unfortunately, because both abstract.c and classobject.c need roughly the same function :P Making the classobject.c one return a 1-tuple is not very useful, because only one place needs a 1-tuple, the other needs a 2-tuple, and I don't fancy modifying the 1-tuple separately. Don't you wish C was more like Python ? *sigh* ------------------------------------------------------- Date: 2000-Aug-15 18:56 By: tim_one Comment: Assigned to Guido because his is the next natural voice in the conversation. Thomas, note that this needs doc and test patches too if it's not to be Postponed. ------------------------------------------------------- Date: 2000-Aug-15 23:00 By: twouters Comment: Just to show y'all that I *can* write documentation and test cases, I've included both in this patch. In fact, those parts take up a lot more space than the actual code change, now ;) Mostly because the test case also tests all other Python class __hooks__. I couldn't find the testcase for them, so I wrote one. The doc changes definately need an editor, if only to add some cross references to slice objects and such. Also, depending on the BDFL, some stronger language might be in order, to scare people away from __getslice__ and brothers. ------------------------------------------------------- Date: 2000-Aug-17 19:18 By: gvanrossum Comment: I believe I came up with this myself, and I still like the idea. Was there any debate about this? (I'm hopelessly behind on python-dev mail.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101029&group_id=5470 From noreply@sourceforge.net Thu Aug 17 20:16:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 12:16:46 -0700 Subject: [Patches] [Patch #101129] add indices() and irange() to built-ins Message-ID: <200008171916.MAA12440@bush.i.sourceforge.net> Patch #101129 has been updated. Project: Category: core (C code) Status: Rejected Summary: add indices() and irange() to built-ins Follow-Ups: Date: 2000-Aug-09 10:00 By: ping Comment: There ya go. I have followed the style of the builtin_range() function, and docstrings are included. ------------------------------------------------------- Date: 2000-Aug-15 22:08 By: tim_one Comment: Assigned to Guido for Pronouncement. The debate's been debated, close it out one way or the other. ------------------------------------------------------- Date: 2000-Aug-17 19:16 By: gvanrossum Comment: I haven't seen the debate! But I'm asked to pronounce anyway, and I just don't like this. Learn to write code that doesn't need the list index! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101129&group_id=5470 From noreply@sourceforge.net Thu Aug 17 20:31:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 12:31:04 -0700 Subject: [Patches] [Patch #100970] extended print statement Message-ID: <200008171931.MAA31438@delerium.i.sourceforge.net> Patch #100970 has been updated. Project: Category: core (C code) Status: Postponed Summary: extended print statement Follow-Ups: Date: 2000-Jul-24 02:44 By: bwarsaw Comment: This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout). This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement. An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM. I'm not sure which approach is better. ------------------------------------------------------- Date: 2000-Jul-24 02:45 By: bwarsaw Comment: The following is an example of how you might use the new extended print statement. 
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
------------------------------------------------------- Date: 2000-Aug-15 18:00 By: tim_one Comment: Assigned to Guido for Pronouncement. This was already discussed on Python-Dev. Mix of opinions there. I like it fine. Barry, this needs docs and test cases Real Soon if you want it considered for 2.0. I like the PRINT_TO idea better. ------------------------------------------------------- Date: 2000-Aug-15 22:43 By: bwarsaw Comment: Revised patch which uses the PRINT_ITEM_TO approach favored by Tim. This patch also includes doc and test suite updates. Please see PEP 214 for a discussion of the issues. This feature should be postponed until Python 2.1 ------------------------------------------------------- Date: 2000-Aug-15 23:05 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-15 23:16 By: bwarsaw Comment: Okay, I just thought that with the open issue (see PEP 214) it might not be ready for prime time. Let's wait for the BDFL pronounce before postponing. ------------------------------------------------------- Date: 2000-Aug-15 23:33 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-16 14:56 By: bwarsaw Comment: After channeling and encouragement from Tim, this patch represents the current definition of the feature as described in PEP 214. It is now ready for BDFL pronouncement for Python 2.0. ------------------------------------------------------- Date: 2000-Aug-17 19:31 By: gvanrossum Comment: I'm still not convinced. Let's save this for reopening in 2.1. I'm worried about language bloat... Assigned to Tim just so that he can reopen the debate when he sees fit. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470 From noreply@sourceforge.net Thu Aug 17 20:36:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 12:36:01 -0700 Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display Message-ID: <200008171936.MAA31610@delerium.i.sourceforge.net> Patch #100947 has been updated. Project: Category: library Status: Open Summary: increase control and default size of pdb traceback display Follow-Ups: Date: 2000-Aug-14 03:15 By: nowonder Comment: There is a detailed description in the patch. ------------------------------------------------------- Date: 2000-Aug-15 17:55 By: tim_one Comment: Reassigned to Guido in Jeremy's absence, cuz I never use pdb but know Guido has at least once . Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 19:36 By: gvanrossum Comment: I like the idea fine, but the command name "scaletb" sucks. Once a better name is coined Ken should get checkin permissions if he doesn't already have them, so he can check it in. (Isn't it ironic that Ken, who enjoys naming debates so much, came up with a sucky name? :-) Possibly a better name could include "control" (or an abbreviation) instead of "scale"? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470 From noreply@sourceforge.net Thu Aug 17 20:41:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 12:41:28 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008171941.MAA31808@delerium.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Open Summary: list comprehensions: require initial for clause ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Thu Aug 17 20:55:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 12:55:33 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008171955.MAA32389@delerium.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Open Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 15:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Thu Aug 17 21:10:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 13:10:53 -0700 Subject: [Patches] [Patch #101029] Call __getitem__ for slices when no __getslice__ Message-ID: <200008172010.NAA00508@delerium.i.sourceforge.net> Patch #101029 has been updated. Project: Category: core (C code) Status: Accepted Summary: Call __getitem__ for slices when no __getslice__ Follow-Ups: Date: 2000-Jul-31 15:55 By: twouters Comment: Call __getitem__ if no __getslice__ is available. similar for __delslice__ and __setslice__, and for the C API: calls mp_subscript() with a slice object of (start, end, None) if there is no sq_slice(), and the same for sq_ass_slice(). Eventually the reverse should be done, too: call __getslice__ instead of __getitem__ if the object has a __getslice__, and the 3rd argument to the slice is None: That way, we can ditch the 12 silly SLICE* opcodes, and always use slice objects. This *will* result in x[::] being passed to __getslice__ (if available) instead of __getitem__, however, so it is not 100% backwards compatible. This patch is not terribly tested: I'm not feeling well, and I want to post this patch before I head off to home and dive back in bed ;) It doesn't crash, it survives 'make test', it survives manual testing, but it might leak. ------------------------------------------------------- Date: 2000-Jul-31 16:55 By: gvanrossum Comment: Looks cool to me, except that there's a lot of code duplication. Maybe you can add a static helper routine to create a slice out of two ints to abstract.c and one that creates a 1-tuple containing such a slice to classobject.c. (Trying to share code across .c files would require turning it into an official API which I think is overkill.) ------------------------------------------------------- Date: 2000-Jul-31 23:35 By: twouters Comment: New version with less code duplication. Less, not none, unfortunately, because both abstract.c and classobject.c need roughly the same function :P Making the classobject.c one return a 1-tuple is not very useful, because only one place needs a 1-tuple, the other needs a 2-tuple, and I don't fancy modifying the 1-tuple separately. Don't you wish C was more like Python ? *sigh* ------------------------------------------------------- Date: 2000-Aug-15 20:56 By: tim_one Comment: Assigned to Guido because his is the next natural voice in the conversation. Thomas, note that this needs doc and test patches too if it's not to be Postponed. ------------------------------------------------------- Date: 2000-Aug-16 01:00 By: twouters Comment: Just to show y'all that I *can* write documentation and test cases, I've included both in this patch. In fact, those parts take up a lot more space than the actual code change, now ;) Mostly because the test case also tests all other Python class __hooks__. I couldn't find the testcase for them, so I wrote one. The doc changes definately need an editor, if only to add some cross references to slice objects and such. Also, depending on the BDFL, some stronger language might be in order, to scare people away from __getslice__ and brothers. ------------------------------------------------------- Date: 2000-Aug-17 21:18 By: gvanrossum Comment: I believe I came up with this myself, and I still like the idea. Was there any debate about this? (I'm hopelessly behind on python-dev mail.) ------------------------------------------------------- Date: 2000-Aug-17 22:10 By: twouters Comment: Yes, there was a debate, mostly between you, me, Michael Hudson and the occasional post by others. The thread is an old one, nothing has been said about this recently. The thread started as '[Python-Dev] PEP 203 Augmented Assignment', but quickly split into three separate discussions: one about why we have __getslice__ at all, one about reordering opcodes, and another about extended slicing on builtin types, which prompted Michael to submit a patch that adds extended slicing to builtin lists. In general, you seemed to think the current split between extended slices and basic slices should be solved by using slice objects for basic slices too. You briefly argued for a backwards-compatible way of passing simple-extended slice objects to __getslice__, but that was a think-o, I think :) The start of the thread can be found here: http://www.python.org/pipermail/python-dev/2000-July/014071.html A handful of the messages ended up in August, too, but mostly not on this particular issue. I'll review this patch for the last time tonight, and then check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101029&group_id=5470 From noreply@sourceforge.net Thu Aug 17 21:16:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 13:16:50 -0700 Subject: [Patches] [Patch #101085] calendar.py extensions Message-ID: <200008172016.NAA00716@delerium.i.sourceforge.net> Patch #101085 has been updated. Project: Category: Modules Status: Open Summary: calendar.py extensions Follow-Ups: Date: 2000-Aug-05 21:54 By: goodger Comment: (1) Allows any weekday to start a week, not just Monday as hardcoded. (2) Added functions which return week, month and year calendars as strings (e.g. prmonth() prints, month() returns string), so we aren't forced to play with stdout when we don't want to print. Had to modify some (manditory, therefore non-keyword) parameters in prweek(), prmonth() & prcal()'s signatures. (3) Removed "caching interface to _monthcalendar" as unnecessary complexity. ------------------------------------------------------- Date: 2000-Aug-15 15:05 By: tim_one Comment: Assigned to Skip because he's a Calendar kind of fellow. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 16:16 By: montanaro Comment: Looks reasonable with the following recommendations and questions: * the w (width) and l (length) keyword args to month and prmonth should probably be called something else (columnwidth and rowheight perhaps?). Should calendar/prcal have columnwidth, rowheight and gutterwidth optional arguments? * I think the month() function should include a trailing newline and that prmonth should call sys.stdout.write. Same for the calendar/prcal pair. * Should firstweekday accept string arguments as well so people don't have to map from days of the week to integers? What does this imply for locales? Can English just be assumed? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101085&group_id=5470 From noreply@sourceforge.net Thu Aug 17 21:19:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 13:19:11 -0700 Subject: [Patches] [Patch #101086] libcalendar.tex extensions (untested; don't have TeX) Message-ID: <200008172019.NAA00780@delerium.i.sourceforge.net> Patch #101086 has been updated. Project: Category: documentation Status: Open Summary: libcalendar.tex extensions (untested; don't have TeX) Follow-Ups: Date: 2000-Aug-05 21:57 By: goodger Comment: I don't have TeX, and am not fluent, so I hacked the doc code. I haven't tested it and can't guarantee it is without error. I hope it doesn't cause you any trouble. Sorry! ------------------------------------------------------- Date: 2000-Aug-15 15:08 By: tim_one Comment: Assigned to Skip because it appears to be a companion to the calendar.py patch. Skip, if you like the latter patch, I guess this patch should get assigned to Fred next. ------------------------------------------------------- Date: 2000-Aug-17 16:19 By: montanaro Comment: Documentation of function signatures should match definition (e.g., w & l vs width & length) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101086&group_id=5470 From noreply@sourceforge.net Thu Aug 17 21:21:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 13:21:23 -0700 Subject: [Patches] [Patch #101085] calendar.py extensions Message-ID: <200008172021.NAA00923@delerium.i.sourceforge.net> Patch #101085 has been updated. Project: Category: Modules Status: Open Summary: calendar.py extensions Follow-Ups: Date: 2000-Aug-05 21:54 By: goodger Comment: (1) Allows any weekday to start a week, not just Monday as hardcoded. (2) Added functions which return week, month and year calendars as strings (e.g. prmonth() prints, month() returns string), so we aren't forced to play with stdout when we don't want to print. Had to modify some (manditory, therefore non-keyword) parameters in prweek(), prmonth() & prcal()'s signatures. (3) Removed "caching interface to _monthcalendar" as unnecessary complexity. ------------------------------------------------------- Date: 2000-Aug-15 15:05 By: tim_one Comment: Assigned to Skip because he's a Calendar kind of fellow. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 16:16 By: montanaro Comment: Looks reasonable with the following recommendations and questions: * the w (width) and l (length) keyword args to month and prmonth should probably be called something else (columnwidth and rowheight perhaps?). Should calendar/prcal have columnwidth, rowheight and gutterwidth optional arguments? * I think the month() function should include a trailing newline and that prmonth should call sys.stdout.write. Same for the calendar/prcal pair. * Should firstweekday accept string arguments as well so people don't have to map from days of the week to integers? What does this imply for locales? Can English just be assumed? ------------------------------------------------------- Date: 2000-Aug-17 16:21 By: montanaro Comment: Just occurred to me... Perhaps firstweekday() should reset to the default for the module (Monday) instead of the US convention (Sunday first). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101085&group_id=5470 From noreply@sourceforge.net Thu Aug 17 22:59:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 14:59:53 -0700 Subject: [Patches] [Patch #101212] Document new opcodes Message-ID: <200008172159.OAA04381@delerium.i.sourceforge.net> Patch #101212 has been updated. Project: Category: documentation Status: Open Summary: Document new opcodes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101212&group_id=5470 From noreply@sourceforge.net Thu Aug 17 23:20:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 15:20:50 -0700 Subject: [Patches] [Patch #101212] Document new opcodes Message-ID: <200008172220.PAA19044@bush.i.sourceforge.net> Patch #101212 has been updated. Project: Category: documentation Status: Closed Summary: Document new opcodes Follow-Ups: Date: 2000-Aug-17 18:20 By: fdrake Comment: Checked in without changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101212&group_id=5470 From noreply@sourceforge.net Thu Aug 17 23:24:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 15:24:50 -0700 Subject: [Patches] [Patch #101207] BeOS: installing of linker script Message-ID: <200008172224.PAA19222@bush.i.sourceforge.net> Patch #101207 has been updated. Project: Category: Build Status: Open Summary: BeOS: installing of linker script Follow-Ups: Date: 2000-Aug-17 08:23 By: RLiebscher Comment: distutils uses the linker command found in config/Makefile. If BeOS uses a seperate linker script then this needs also to be installed. This patch changes Makefile.in to copy the BeOS directory in the python directory. Another solution would be to install the scripts right in the config directory as it is done for AIX. ------------------------------------------------------- Date: 2000-Aug-17 18:24 By: fdrake Comment: Please change this to work the same way as for AIX. The Distutils code may need to be adjusted to be able to locate the linkmodule script; please contribute a patch for that as well or post a bug report for distutils, so that Greg Ward can fix it. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101207&group_id=5470 From noreply@sourceforge.net Thu Aug 17 23:43:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 15:43:08 -0700 Subject: [Patches] [Patch #101029] Call __getitem__ for slices when no __getslice__ Message-ID: <200008172243.PAA05963@delerium.i.sourceforge.net> Patch #101029 has been updated. Project: Category: core (C code) Status: Closed Summary: Call __getitem__ for slices when no __getslice__ Follow-Ups: Date: 2000-Jul-31 15:55 By: twouters Comment: Call __getitem__ if no __getslice__ is available. similar for __delslice__ and __setslice__, and for the C API: calls mp_subscript() with a slice object of (start, end, None) if there is no sq_slice(), and the same for sq_ass_slice(). Eventually the reverse should be done, too: call __getslice__ instead of __getitem__ if the object has a __getslice__, and the 3rd argument to the slice is None: That way, we can ditch the 12 silly SLICE* opcodes, and always use slice objects. This *will* result in x[::] being passed to __getslice__ (if available) instead of __getitem__, however, so it is not 100% backwards compatible. This patch is not terribly tested: I'm not feeling well, and I want to post this patch before I head off to home and dive back in bed ;) It doesn't crash, it survives 'make test', it survives manual testing, but it might leak. ------------------------------------------------------- Date: 2000-Jul-31 16:55 By: gvanrossum Comment: Looks cool to me, except that there's a lot of code duplication. Maybe you can add a static helper routine to create a slice out of two ints to abstract.c and one that creates a 1-tuple containing such a slice to classobject.c. (Trying to share code across .c files would require turning it into an official API which I think is overkill.) ------------------------------------------------------- Date: 2000-Jul-31 23:35 By: twouters Comment: New version with less code duplication. Less, not none, unfortunately, because both abstract.c and classobject.c need roughly the same function :P Making the classobject.c one return a 1-tuple is not very useful, because only one place needs a 1-tuple, the other needs a 2-tuple, and I don't fancy modifying the 1-tuple separately. Don't you wish C was more like Python ? *sigh* ------------------------------------------------------- Date: 2000-Aug-15 20:56 By: tim_one Comment: Assigned to Guido because his is the next natural voice in the conversation. Thomas, note that this needs doc and test patches too if it's not to be Postponed. ------------------------------------------------------- Date: 2000-Aug-16 01:00 By: twouters Comment: Just to show y'all that I *can* write documentation and test cases, I've included both in this patch. In fact, those parts take up a lot more space than the actual code change, now ;) Mostly because the test case also tests all other Python class __hooks__. I couldn't find the testcase for them, so I wrote one. The doc changes definately need an editor, if only to add some cross references to slice objects and such. Also, depending on the BDFL, some stronger language might be in order, to scare people away from __getslice__ and brothers. ------------------------------------------------------- Date: 2000-Aug-17 21:18 By: gvanrossum Comment: I believe I came up with this myself, and I still like the idea. Was there any debate about this? (I'm hopelessly behind on python-dev mail.) ------------------------------------------------------- Date: 2000-Aug-17 22:10 By: twouters Comment: Yes, there was a debate, mostly between you, me, Michael Hudson and the occasional post by others. The thread is an old one, nothing has been said about this recently. The thread started as '[Python-Dev] PEP 203 Augmented Assignment', but quickly split into three separate discussions: one about why we have __getslice__ at all, one about reordering opcodes, and another about extended slicing on builtin types, which prompted Michael to submit a patch that adds extended slicing to builtin lists. In general, you seemed to think the current split between extended slices and basic slices should be solved by using slice objects for basic slices too. You briefly argued for a backwards-compatible way of passing simple-extended slice objects to __getslice__, but that was a think-o, I think :) The start of the thread can be found here: http://www.python.org/pipermail/python-dev/2000-July/014071.html A handful of the messages ended up in August, too, but mostly not on this particular issue. I'll review this patch for the last time tonight, and then check it in. ------------------------------------------------------- Date: 2000-Aug-18 00:43 By: twouters Comment: Applied. Note that this is just the 'first step' in the process of deprecating __*slice__: the next step could be taken in 2.2 or so, in that Python always generates a slice object, and 'unpacks' it if there *is* a corresponding __*slice__ method. That means dropping 12 opcodes ! :-) Whether that step should be taken, though, should depend on the overall reaction to using getitem + sliceobjects. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101029&group_id=5470 From noreply@sourceforge.net Thu Aug 17 23:53:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 15:53:23 -0700 Subject: [Patches] [Patch #101135] 'import x as y' and 'from x import y as z' Message-ID: <200008172253.PAA06307@delerium.i.sourceforge.net> Patch #101135 has been updated. Project: Category: core (C code) Status: Closed Summary: 'import x as y' and 'from x import y as z' Follow-Ups: Date: 2000-Aug-09 22:23 By: twouters Comment: This patch adds the oft-proposed 'import as' syntax, to both 'import module' and 'from module import ...', but without making 'as' a reserved word (by using the technique Tim Peters proposed on python-dev.) 'import spam as egg' is a very simple patch to compile.c, which doesn't need changes to the VM, but 'from spam import dog as meat' needs a new bytecode, which this patch calls 'FROM_IMPORT_AS'. The bytecode loads an object from a module onto the stack, so a STORE_NAME can store it later. This can't be done by the normal FROM_IMPORT opcode, because it needs to take the special case of '*' into account. Also, because it uses 'STORE_NAME', it's now possible to mix 'import' and 'global', like so: global X from foo import X as X The patch still generates the old code for from foo import X (without 'as') mostly to save on bytecode size, and for the 'compatibility' with mixing 'global' and 'from .. import'... I'm not sure what's the best thing to do. The patch doesn't include a test suite or documentation, yet. ------------------------------------------------------- Date: 2000-Aug-12 00:04 By: twouters Comment: I now think the best thing to do is to split the 'IMPORT_FROM' opcode into two opcodes: 'IMPORT_ALL', which is used for 'from module import *', and 'IMPORT_FROM' (or another name, if that's desired) which loads a single name. IMPORT_ALL would store the retrieved objects into the local namespace directly, like IMPORT_FROM currently does; it doesn't use the stack other than to retrieve the module it loads the symbols from. IMPORT_FROM would act more like 'IMPORT_NAME', in that the object retrieved from the module is not stored directly in the local namespace, but instead pushed on the stack (that's what the IMPORT_FROM_AS bytecode in the current patch does) -- that means that for all normal 'from' imports, a STORE is generated, and a 'global' works on them just like with normal variable assignment. In the current patch, this is only true for 'from module import x as y' statements, not for the normal form. Assigned to Guido, since it's ultimately his decision (everyone else already voted ;-) ------------------------------------------------------- Date: 2000-Aug-16 00:12 By: tim_one Comment: Reminding Guido this is still on his plate. Thomas, I agree with you that splitting IMPORT_FROM is a good idea -- the "*" and "name" cases are indeed very different. Since Guido hasn't gotten to this yet, how about changing the patch before he notices? The votes you got before were based on the visible semantics, not the implementation, so no need to vote again. ------------------------------------------------------- Date: 2000-Aug-16 00:25 By: twouters Comment: Actually, I finished an updated patch that did that about two hours ago, but Blackadder intervened, and I forgot to upload it afterwards :P This patch does not contain doc changes or test cases yet, but the changes to the core are finished, as far as I'm concerned. I'll try to finish the docs and tests tomorrow. (I have to say this is the first patch where the doc changes look more attractive than the test case. I need to start a syntax-highlighting editor just to be able to *read* test_pkg, let alone extend it ;) ------------------------------------------------------- Date: 2000-Aug-17 21:13 By: gvanrossum Comment: Go for it. This is a scary precedent (a new keyword without keyword status) but I think the basic proposal is good. I haven't reviewed the quality of the patch, but I presume it's been checked by others (and it can always be fixed later). ------------------------------------------------------- Date: 2000-Aug-18 00:53 By: twouters Comment: Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470 From noreply@sourceforge.net Fri Aug 18 04:21:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 20:21:54 -0700 Subject: [Patches] [Patch #101214] Improve exception message for PyErr_BadInternalCall() Message-ID: <200008180321.UAA28821@bush.i.sourceforge.net> Patch #101214 has been updated. Project: Category: core (C code) Status: Open Summary: Improve exception message for PyErr_BadInternalCall() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101214&group_id=5470 From noreply@sourceforge.net Fri Aug 18 04:25:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 20:25:05 -0700 Subject: [Patches] [Patch #101214] Improve exception message for PyErr_BadInternalCall() Message-ID: <200008180325.UAA28950@bush.i.sourceforge.net> Patch #101214 has been updated. Project: Category: core (C code) Status: Open Summary: Improve exception message for PyErr_BadInternalCall() Follow-Ups: Date: 2000-Aug-17 23:25 By: fdrake Comment: This patch uses a macro wrapper to provide the filename and line number of the call to PyErr_BadInternalCall(). This should be reasonable since the __FILE__ and __LINE__ macros are ANSI C (I think). There are 77 call sites for PyErr_BadInternalCall(), and this would make it a lot easier to get an initial foothold on errors generated through this function. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101214&group_id=5470 From noreply@sourceforge.net Fri Aug 18 06:21:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 22:21:12 -0700 Subject: [Patches] [Patch #101215] extend 'import x as y' syntax to 'import x as y.z' Message-ID: <200008180521.WAA19055@delerium.i.sourceforge.net> Patch #101215 has been updated. Project: Category: core (C code) Status: Open Summary: extend 'import x as y' syntax to 'import x as y.z' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101215&group_id=5470 From noreply@sourceforge.net Fri Aug 18 06:25:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Aug 2000 22:25:38 -0700 Subject: [Patches] [Patch #101215] extend 'import x as y' syntax to 'import x as y.z' Message-ID: <200008180525.WAA19198@delerium.i.sourceforge.net> Patch #101215 has been updated. Project: Category: core (C code) Status: Open Summary: extend 'import x as y' syntax to 'import x as y.z' Follow-Ups: Date: 2000-Aug-18 05:25 By: nowonder Comment: I've played a bit around with the new 'import x as y' syntax and found it would be useful to be able to assign to module/class members, too. Example from BaseHTTPServer: import SOCKS; socket = SOCKS; del SOCKS from socket import getfqdn; socket.getfqdn = getfqdn; del getfqdn could become: import SOCKS as socket # nothing new here from socket import getfqdn as socket.getfqdn # NEW! Assigned to Thomas for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101215&group_id=5470 From noreply@sourceforge.net Fri Aug 18 12:08:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 04:08:41 -0700 Subject: [Patches] [Patch #101215] extend 'import x as y' syntax to 'import x as y.z' Message-ID: <200008181108.EAA11145@bush.i.sourceforge.net> Patch #101215 has been updated. Project: Category: core (C code) Status: Open Summary: extend 'import x as y' syntax to 'import x as y.z' Follow-Ups: Date: 2000-Aug-18 05:25 By: nowonder Comment: I've played a bit around with the new 'import x as y' syntax and found it would be useful to be able to assign to module/class members, too. Example from BaseHTTPServer: import SOCKS; socket = SOCKS; del SOCKS from socket import getfqdn; socket.getfqdn = getfqdn; del getfqdn could become: import SOCKS as socket # nothing new here from socket import getfqdn as socket.getfqdn # NEW! Assigned to Thomas for review. ------------------------------------------------------- Date: 2000-Aug-18 11:08 By: marangoz Comment: Before going too far with this, here's a strong -1 without even reviewing the patch. Playing with namespaces other than the current one is a bad idea. +1 on import x as y. As long as you introduce a new binding in the current namespace, being able to alter the original name for that binding is nice. -1 on import x as y.z, though, because you want to introduce a binding in a namespace which you don't own (y's namespace). For that matter, y must exist in the current namespace and allow bindings, which is not granted at all. Overall, this sucks . Example: >>> y = 1 >>> import sys as y.sys Please reject this before I see another patch update, or I'll reject it on the first update that'll hit my mailbox . ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101215&group_id=5470 From noreply@sourceforge.net Fri Aug 18 12:15:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 04:15:28 -0700 Subject: [Patches] [Patch #101214] Improve exception message for PyErr_BadInternalCall() Message-ID: <200008181115.EAA30838@delerium.i.sourceforge.net> Patch #101214 has been updated. Project: Category: core (C code) Status: Open Summary: Improve exception message for PyErr_BadInternalCall() Follow-Ups: Date: 2000-Aug-18 03:25 By: fdrake Comment: This patch uses a macro wrapper to provide the filename and line number of the call to PyErr_BadInternalCall(). This should be reasonable since the __FILE__ and __LINE__ macros are ANSI C (I think). There are 77 call sites for PyErr_BadInternalCall(), and this would make it a lot easier to get an initial foothold on errors generated through this function. ------------------------------------------------------- Date: 2000-Aug-18 11:15 By: marangoz Comment: OTOH, bad internal calls shouldn't happen, but I like this. You want to make my life easier as a developer, not as a user. +0, modulo the fact that you removed the original function from the API. External modules may fail. Let's keep the original function and its signature in the code. (this requires some preprocessor trickery). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101214&group_id=5470 From noreply@sourceforge.net Fri Aug 18 12:28:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 04:28:44 -0700 Subject: [Patches] [Patch #101215] extend 'import x as y' syntax to 'import x as y.z' Message-ID: <200008181128.EAA31301@delerium.i.sourceforge.net> Patch #101215 has been updated. Project: Category: core (C code) Status: Open Summary: extend 'import x as y' syntax to 'import x as y.z' Follow-Ups: Date: 2000-Aug-18 07:25 By: nowonder Comment: I've played a bit around with the new 'import x as y' syntax and found it would be useful to be able to assign to module/class members, too. Example from BaseHTTPServer: import SOCKS; socket = SOCKS; del SOCKS from socket import getfqdn; socket.getfqdn = getfqdn; del getfqdn could become: import SOCKS as socket # nothing new here from socket import getfqdn as socket.getfqdn # NEW! Assigned to Thomas for review. ------------------------------------------------------- Date: 2000-Aug-18 13:08 By: marangoz Comment: Before going too far with this, here's a strong -1 without even reviewing the patch. Playing with namespaces other than the current one is a bad idea. +1 on import x as y. As long as you introduce a new binding in the current namespace, being able to alter the original name for that binding is nice. -1 on import x as y.z, though, because you want to introduce a binding in a namespace which you don't own (y's namespace). For that matter, y must exist in the current namespace and allow bindings, which is not granted at all. Overall, this sucks . Example: >>> y = 1 >>> import sys as y.sys Please reject this before I see another patch update, or I'll reject it on the first update that'll hit my mailbox . ------------------------------------------------------- Date: 2000-Aug-18 13:28 By: twouters Comment: Hmm... I like the idea a bit, but it'm -1 on the approach: Special casing 'name.name' is *not* the way to go. Instead, what we can do is to allow all normal assignment expressions in the 'as ' so that you can do import shelve from myTools.cPickleFast import Pickler as shelve.Pickler as well as x = [] from sys import stdin as x[0], stdout as x[1], stderr as x[2] and class X: pass x = X() from sys import stdin as x.in, stdout as x.out, stderr as x.err and even from sys import sys.version_info as (major, minor, patchlevel, releaselevel, releaseserial) (though you'd need the parentheses to disambiguate) This is all possible by changing the Grammar slightly, and calling 'com_assign(c, )' rather than 'com_addbyte(c, STORE_NAME, )', I think. Just for laughs, I'll see if it's possible ;) It would certainly be consistent ! and it would behave exactly like import sys x = [sys.stdin, sys.stdout, sys.stderr] [insert other examples] except that sys won't be added to the local namespace. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101215&group_id=5470 From noreply@sourceforge.net Fri Aug 18 15:42:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 07:42:54 -0700 Subject: [Patches] [Patch #101214] Improve exception message for PyErr_BadInternalCall() Message-ID: <200008181442.HAA05719@delerium.i.sourceforge.net> Patch #101214 has been updated. Project: Category: core (C code) Status: Open Summary: Improve exception message for PyErr_BadInternalCall() Follow-Ups: Date: 2000-Aug-17 23:25 By: fdrake Comment: This patch uses a macro wrapper to provide the filename and line number of the call to PyErr_BadInternalCall(). This should be reasonable since the __FILE__ and __LINE__ macros are ANSI C (I think). There are 77 call sites for PyErr_BadInternalCall(), and this would make it a lot easier to get an initial foothold on errors generated through this function. ------------------------------------------------------- Date: 2000-Aug-18 07:15 By: marangoz Comment: OTOH, bad internal calls shouldn't happen, but I like this. You want to make my life easier as a developer, not as a user. +0, modulo the fact that you removed the original function from the API. External modules may fail. Let's keep the original function and its signature in the code. (this requires some preprocessor trickery). ------------------------------------------------------- Date: 2000-Aug-18 10:42 By: fdrake Comment: Add PyErr_BadInternalCall() entry point back for legacy compiled code, but continue to mask it for new code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101214&group_id=5470 From noreply@sourceforge.net Fri Aug 18 19:28:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 11:28:58 -0700 Subject: [Patches] [Patch #101208] Add parens to zipfile.py to fix file time seconds bug Message-ID: <200008181828.LAA27276@bush.i.sourceforge.net> Patch #101208 has been updated. Project: Category: Modules Status: Open Summary: Add parens to zipfile.py to fix file time seconds bug Follow-Ups: Date: 2000-Aug-18 14:28 By: tim_one Comment: Assigned to Andrew. Please take a look? The patch looks almost certainly right-on to me, but I seem to recall that you may (or may not ) have deeper specific knowledge about zip files. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101208&group_id=5470 From noreply@sourceforge.net Fri Aug 18 20:42:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 12:42:46 -0700 Subject: [Patches] [Patch #101208] Add parens to zipfile.py to fix file time seconds bug Message-ID: <200008181942.MAA30030@bush.i.sourceforge.net> Patch #101208 has been updated. Project: Category: Modules Status: Open Summary: Add parens to zipfile.py to fix file time seconds bug Follow-Ups: Date: 2000-Aug-18 14:28 By: tim_one Comment: Assigned to Andrew. Please take a look? The patch looks almost certainly right-on to me, but I seem to recall that you may (or may not ) have deeper specific knowledge about zip files. ------------------------------------------------------- Date: 2000-Aug-18 15:42 By: tim_one Comment: Assigned to Andrew. Please take a look? The patch looks almost certainly right-on to me, but I seem to recall that you may (or may not ) have deeper specific knowledge about zip files. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101208&group_id=5470 From noreply@sourceforge.net Fri Aug 18 20:51:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 12:51:01 -0700 Subject: [Patches] [Patch #101055] Cookie.py Message-ID: <200008181951.MAA30358@bush.i.sourceforge.net> Patch #101055 has been updated. Project: Category: library Status: Open Summary: Cookie.py Follow-Ups: Date: 2000-Aug-15 19:01 By: tim_one Comment: Assigned to GregS as he seems to be a Cookie Guy too. Greg, please review this or pass it on. Barry, you realize this needs doc and test patches too else it will just get Postponed? ------------------------------------------------------- Date: 2000-Aug-15 20:25 By: bwarsaw Comment: Yes, but we're still waiting on a non-LGPL encumbered version of the file. Last I heard, Andrew had gotten in touch with O'Malley who said he had a BSD covered version, but hadn't given a link yet. ------------------------------------------------------- Date: 2000-Aug-15 21:26 By: tim_one Comment: OK, I assigned it to Andrew. If this isn't resolved in a few days, one of you please change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-18 19:51 By: akuchling Comment: I have a copy of Tim O'Malley's ,v file (in order to preserve the version history). I can either ask the SF admins to drop it into the right place in the CVS repository, but will that screw up the Python 1.6 tagging in some way? (I would expect not, but who knows?) The second option would be for me to retrace Cookie.py's development -- add revision 1.1, check in revision 1.2 with the right log message, check in revision 1.3, &c. Obviously I'd prefer to not do this. So, can I go write to the SF admins and send them the ,v file? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101055&group_id=5470 From noreply@sourceforge.net Fri Aug 18 20:59:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 12:59:11 -0700 Subject: [Patches] [Patch #101208] Add parens to zipfile.py to fix file time seconds bug Message-ID: <200008181959.MAA30583@bush.i.sourceforge.net> Patch #101208 has been updated. Project: Category: Modules Status: Closed Summary: Add parens to zipfile.py to fix file time seconds bug Follow-Ups: Date: 2000-Aug-18 18:28 By: tim_one Comment: Assigned to Andrew. Please take a look? The patch looks almost certainly right-on to me, but I seem to recall that you may (or may not ) have deeper specific knowledge about zip files. ------------------------------------------------------- Date: 2000-Aug-18 19:42 By: tim_one Comment: Assigned to Andrew. Please take a look? The patch looks almost certainly right-on to me, but I seem to recall that you may (or may not ) have deeper specific knowledge about zip files. ------------------------------------------------------- Date: 2000-Aug-18 19:59 By: akuchling Comment: The fix was already checked in by fdrake on 2000/06/13. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101208&group_id=5470 From fdrake@beopen.com Fri Aug 18 21:06:20 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 18 Aug 2000 16:06:20 -0400 (EDT) Subject: [Patches] [Patch #101055] Cookie.py In-Reply-To: <200008181951.MAA30358@bush.i.sourceforge.net> References: <200008181951.MAA30358@bush.i.sourceforge.net> Message-ID: <14749.38716.228254.649957@cj42289-a.reston1.va.home.com> noreply@sourceforge.net writes: > I have a copy of Tim O'Malley's ,v file (in order to preserve the > version history). I can either ask the SF admins to drop it into > the right place in the CVS repository, but will that screw up the > Python 1.6 tagging in some way? (I would expect not, but who > knows?) That would have no effect on any of the Python tagging. It's probably worthwhile making sure there are no tags in the ,v file, but that can be done after it gets dropped in place. Now, Greg Stein will tell us that dropping this into place is the wrong thing to do. What it *will* screw up is people asking for the state of Python at a specific date before the file was actually added; they'll get this file even for when it wasn't in the Python CVS tree. I can live with that, but we should make a policy decision for the Python tree regarding this sort of thing. > The second option would be for me to retrace Cookie.py's > development -- add revision 1.1, check in revision 1.2 with the > right log message, check in revision 1.3, &c. Obviously I'd prefer > to not do this. Don't -- it's not worth it. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin@mems-exchange.org Fri Aug 18 21:48:37 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 18 Aug 2000 16:48:37 -0400 Subject: [Patches] [Patch #101055] Cookie.py In-Reply-To: <14749.38716.228254.649957@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Aug 18, 2000 at 04:06:20PM -0400 References: <200008181951.MAA30358@bush.i.sourceforge.net> <14749.38716.228254.649957@cj42289-a.reston1.va.home.com> Message-ID: <20000818164837.A8423@kronos.cnri.reston.va.us> [Overquoting for the sake of python-dev readers] On Fri, Aug 18, 2000 at 04:06:20PM -0400, Fred L. Drake, Jr. wrote: >amk writes: > > I have a copy of Tim O'Malley's Cookie.py,v file (in order to preserve the > > version history). I can either ask the SF admins to drop it into > > the right place in the CVS repository, but will that screw up the > > Python 1.6 tagging in some way? (I would expect not, but who > > knows?) > > That would have no effect on any of the Python tagging. It's >probably worthwhile making sure there are no tags in the ,v file, but >that can be done after it gets dropped in place. > Now, Greg Stein will tell us that dropping this into place is the >wrong thing to do. What it *will* screw up is people asking for the >state of Python at a specific date before the file was actually added; >they'll get this file even for when it wasn't in the Python CVS tree. >I can live with that, but we should make a policy decision for the >Python tree regarding this sort of thing. Excellent point. GvR's probably the only person whose ruling matters on this point; I'll try to remember it and bring it up whenever he gets back (next week, right?). > Don't -- it's not worth it. I hate throwing away information that stands even a tiny chance of being useful; good thing the price of disk storage keeps dropping, eh? The version history might contain details that will be useful in future debugging or code comprehension, so I dislike losing it forever. (My minimalist side is saying that the enhanced Web tools should be a separately downloadable package. But you probably guessed that already...) --amk From bwarsaw@beopen.com Fri Aug 18 22:17:14 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 18 Aug 2000 17:17:14 -0400 (EDT) Subject: [Python-Dev] Re: [Patches] [Patch #101055] Cookie.py References: <200008181951.MAA30358@bush.i.sourceforge.net> <14749.38716.228254.649957@cj42289-a.reston1.va.home.com> <20000818164837.A8423@kronos.cnri.reston.va.us> Message-ID: <14749.42970.845587.90980@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> I hate throwing away information that stands even a tiny AK> chance of being useful; good thing the price of disk storage AK> keeps dropping, eh? The version history might contain details AK> that will be useful in future debugging or code comprehension, AK> so I dislike losing it forever. I agree. Let's try to keep the revision history for Cookie.py. -Barry From noreply@sourceforge.net Sat Aug 19 05:11:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 21:11:54 -0700 Subject: [Patches] [Patch #101104] Optional object mem allocator Message-ID: <200008190411.VAA01309@delerium.i.sourceforge.net> Patch #101104 has been updated. Project: Category: core (C code) Status: Postponed Summary: Optional object mem allocator Follow-Ups: Date: 2000-Aug-07 04:05 By: marangoz Comment: A stab on obmalloc.c -- an optional object allocator. A configure "--with(out)-pymalloc" option is introduced for enabling specialized mallocs. Off by default. The code is included conditionally at the end of object.c obmalloc.c contains only the core malloc functionality. No profiling, nor debugging are there -- these would come as separate (and optional) modules: memprof.c & memdebug.c in the Modules/ directory and will exploit the hooks of the allocator. I've managed to draw a rather nice diagram in the comments at the top of obmalloc.c explaining what this stuff is all about. Look there. ------------------------------------------------------- Date: 2000-Aug-07 13:30 By: twouters Comment: Small nit: you shouldn't edit config.h.in yourself, it's autogenerated from acconfig.h and configure.in (with 'autoheader', part of 'autoconf.) You should define WITH_PYMALLOC in acconfig.h, not config.h.in, and run 'autoheader' and 'autoconf' to generate a new 'configure'. I'm in the process of testing this patch on Linux and BSDI, by the way :) ------------------------------------------------------- Date: 2000-Aug-07 16:19 By: marangoz Comment: Thanks. Fixed (acconfig.h) ------------------------------------------------------- Date: 2000-Aug-12 20:31 By: marangoz Comment: Status set to Postponed. Although promising, this hasn't enjoyed much user testing for the 2.0 time frame (partly because of the lack of an introspective Python interface which can't be completed in time according to the release schedule). Assigned to marangoz who's responsible to reopen it again in due time (except if BDFL decides otherwise). ------------------------------------------------------- Date: 2000-Aug-19 04:11 By: marangoz Comment: Update: (1) fixing a missing case for realloc(p,0) == free(p) + ret NULL (2) simplify the hooks interface: set_hooks/fetch_hooks are better than install/uninstall. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101104&group_id=5470 From noreply@sourceforge.net Sat Aug 19 05:30:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 21:30:36 -0700 Subject: [Patches] [Patch #101226] make threading fork-safe Message-ID: <200008190430.VAA01911@delerium.i.sourceforge.net> Patch #101226 has been updated. Project: Category: core (C code) Status: Open Summary: make threading fork-safe ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101226&group_id=5470 From noreply@sourceforge.net Sat Aug 19 07:49:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 23:49:39 -0700 Subject: [Patches] [Patch #101229] Optional memory profiler Message-ID: <200008190649.XAA18767@bush.i.sourceforge.net> Patch #101229 has been updated. Project: Category: core (C code) Status: Open Summary: Optional memory profiler ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101229&group_id=5470 From ping@lfw.org Sat Aug 19 07:50:36 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Fri, 18 Aug 2000 23:50:36 -0700 (PDT) Subject: [Patches] [Patch #101215] extend 'import x as y' syntax to 'import x as y.z' In-Reply-To: <200008181128.EAA31301@delerium.i.sourceforge.net> Message-ID: On Fri, 18 Aug 2000 noreply@sourceforge.net wrote: > Date: 2000-Aug-18 13:28 > By: twouters > > Comment: > Hmm... I like the idea a bit, but it'm -1 on the approach: > Special casing 'name.name' is *not* the way to go. Instead, > what we can do is to allow all normal assignment expressions > in the 'as ' so that you can do [...] > from myTools.cPickleFast import Pickler as shelve.Pickler [...] > from sys import stdin as x[0], stdout as x[1], stderr as x[2] [...] > from sys import stdin as x.in, stdout as x.out, stderr as x.err [...] > from sys import sys.version_info as (major, minor, patchlevel, releaselevel, releaseserial) I support this generalization. It just makes a lot of sense. -- ?!ng From noreply@sourceforge.net Sat Aug 19 08:18:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 00:18:46 -0700 Subject: [Patches] [Patch #101229] Optional memory profiler Message-ID: <200008190718.AAA06918@delerium.i.sourceforge.net> Patch #101229 has been updated. Project: Category: core (C code) Status: Postponed Summary: Optional memory profiler Follow-Ups: Date: 2000-Aug-19 07:18 By: marangoz Comment: An optional memory profiler, which goes in tandem with the optional object memory allocator (SourceForge patch #101104). The profiler was introduced briefly on python-dev: http://www.python.org/pipermail/python-dev/2000-August/015239.html Applying both patches gives for me (screen dump): ~> patch -p1 < ../obmalloc-patch patching file `Include/objimpl.h' patching file `Objects/object.c' patching file `Objects/obmalloc.c' patching file `acconfig.h' patching file `configure.in' ~> patch -p1 < ../memprof-patch patching file `Include/pydebug.h' patching file `Modules/Setup.config.in' patching file `Modules/main.c' patching file `Modules/memprof.c' patching file `Python/pythonrun.c' patching file `acconfig.h' patching file `configure.in' - Don't forget that you need to autoheader; autoconf; This patch: 1) introduces a new --with-memprof configure option. Off by default. 2) introduced a Py_ProfileFlag and a "-p" Python option which starts the profiler in Py_Initialize() before any initializations, and stops it in Py_Finalize() after all finalizations. 3) contains a new Modules/memprof.c module. The inclusion of this file in the core is similar to the thread and GC modules (Setup.config.in) The patch *can* be applied without the object allocator and it *does* compile on request. However, it issues a warning that it won't profile anything, because it can't be called (the profiler can't install its hooks). Besides, it will refuse to start(). The point is that both the profiler and the allocator are really optional. Needs docs & tests :( The interface can be improved (just like everything else) but the core functionality is there. It *is* useful for getting snapshots of the minimum allocated (object) memory, at least. Some worthy points to condifer, IMO, are listed in the TODO of memprof.c. I am submitting this for testing, reviewing, comments and more ideas. Overall, I think it is a BIG plus regarding Python's typical introspection. Comments welcome. As usual, flames to /dev/null . Status set straight to Postponed. Assigned to marangoz who's in charge of opening it in due time, together with #101104. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101229&group_id=5470 From Moshe Zadka Sat Aug 19 10:38:54 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 19 Aug 2000 12:38:54 +0300 (IDT) Subject: [Patches] [Patch #101055] Cookie.py In-Reply-To: <14749.38716.228254.649957@cj42289-a.reston1.va.home.com> Message-ID: On Fri, 18 Aug 2000, Fred L. Drake, Jr. wrote: > That would have no effect on any of the Python tagging. It's > probably worthwhile making sure there are no tags in the ,v file, but > that can be done after it gets dropped in place. > Now, Greg Stein will tell us that dropping this into place is the > wrong thing to do. What it *will* screw up is people asking for the > state of Python at a specific date before the file was actually added; > they'll get this file even for when it wasn't in the Python CVS tree. > I can live with that, but we should make a policy decision for the > Python tree regarding this sort of thing. Do we really need the ',v' version? It's not like we'll revert to any previous version. And by the way, there are a couple of things we should consider changing before slating this up for an official release: 1) Change __repr__ --> __str__, and give an honest __repr__ 2) Deprecate SmartCookie and SerilizedCookie: those two are real security holes, and I'm worried it might give Python an undeserved unsecure reputation. Or, maybe, add a mandatory password and only accept md5 signed versions. We *can* break backwards compatability now, because Cookie was not an official part of Python, and we *should* break it now, because that's the last chance we'll have. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From fdrake@beopen.com Sat Aug 19 13:46:54 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 19 Aug 2000 08:46:54 -0400 (EDT) Subject: [Patches] [Patch #101055] Cookie.py In-Reply-To: References: <14749.38716.228254.649957@cj42289-a.reston1.va.home.com> Message-ID: <14750.33214.321886.381296@cj42289-a.reston1.va.home.com> Moshe Zadka writes: > Do we really need the ',v' version? It's not like we'll revert to > any previous version. And by the way, there are a couple of things Not enough people think we need it, and Tim has presented a very good argument for not using it. > we should consider changing before slating this up for an official > release: I'll leave those details to people interested in the module. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From noreply@sourceforge.net Sat Aug 19 14:03:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 06:03:54 -0700 Subject: [Patches] [Patch #101055] Cookie.py Message-ID: <200008191303.GAA17117@delerium.i.sourceforge.net> Patch #101055 has been updated. Project: Category: library Status: Closed Summary: Cookie.py Follow-Ups: Date: 2000-Aug-15 19:01 By: tim_one Comment: Assigned to GregS as he seems to be a Cookie Guy too. Greg, please review this or pass it on. Barry, you realize this needs doc and test patches too else it will just get Postponed? ------------------------------------------------------- Date: 2000-Aug-15 20:25 By: bwarsaw Comment: Yes, but we're still waiting on a non-LGPL encumbered version of the file. Last I heard, Andrew had gotten in touch with O'Malley who said he had a BSD covered version, but hadn't given a link yet. ------------------------------------------------------- Date: 2000-Aug-15 21:26 By: tim_one Comment: OK, I assigned it to Andrew. If this isn't resolved in a few days, one of you please change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-18 19:51 By: akuchling Comment: I have a copy of Tim O'Malley's ,v file (in order to preserve the version history). I can either ask the SF admins to drop it into the right place in the CVS repository, but will that screw up the Python 1.6 tagging in some way? (I would expect not, but who knows?) The second option would be for me to retrace Cookie.py's development -- add revision 1.1, check in revision 1.2 with the right log message, check in revision 1.3, &c. Obviously I'd prefer to not do this. So, can I go write to the SF admins and send them the ,v file? ------------------------------------------------------- Date: 2000-Aug-19 13:03 By: akuchling Comment: Revision 2.26 of Cookie.py added to Lib/ directory. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101055&group_id=5470 From noreply@sourceforge.net Sat Aug 19 16:41:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 08:41:23 -0700 Subject: [Patches] [Patch #101233] PyModule_AddObject() and friends Message-ID: <200008191541.IAA01994@bush.i.sourceforge.net> Patch #101233 has been updated. Project: Category: core (C code) Status: Open Summary: PyModule_AddObject() and friends ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101233&group_id=5470 From noreply@sourceforge.net Sat Aug 19 18:17:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 10:17:05 -0700 Subject: [Patches] [Patch #101233] PyModule_AddObject() and friends Message-ID: <200008191717.KAA05080@bush.i.sourceforge.net> Patch #101233 has been updated. Project: Category: core (C code) Status: Open Summary: PyModule_AddObject() and friends Follow-Ups: Date: 2000-Aug-19 17:17 By: marangoz Comment: Looks good. BDFL need to Pronounce on API issues. What amount of changes would this imply in the distrib? Have patch? (the names could be tuned later directly in the patch ) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101233&group_id=5470 From noreply@sourceforge.net Sat Aug 19 18:13:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 10:13:26 -0700 Subject: [Patches] [Patch #101214] Improve exception message for PyErr_BadInternalCall() Message-ID: <200008191713.KAA04954@bush.i.sourceforge.net> Patch #101214 has been updated. Project: Category: core (C code) Status: Open Summary: Improve exception message for PyErr_BadInternalCall() Follow-Ups: Date: 2000-Aug-18 03:25 By: fdrake Comment: This patch uses a macro wrapper to provide the filename and line number of the call to PyErr_BadInternalCall(). This should be reasonable since the __FILE__ and __LINE__ macros are ANSI C (I think). There are 77 call sites for PyErr_BadInternalCall(), and this would make it a lot easier to get an initial foothold on errors generated through this function. ------------------------------------------------------- Date: 2000-Aug-18 11:15 By: marangoz Comment: OTOH, bad internal calls shouldn't happen, but I like this. You want to make my life easier as a developer, not as a user. +0, modulo the fact that you removed the original function from the API. External modules may fail. Let's keep the original function and its signature in the code. (this requires some preprocessor trickery). ------------------------------------------------------- Date: 2000-Aug-18 14:42 By: fdrake Comment: Add PyErr_BadInternalCall() entry point back for legacy compiled code, but continue to mask it for new code. ------------------------------------------------------- Date: 2000-Aug-19 17:13 By: marangoz Comment: Where's the legacy PyErr_BadInternalCall(void) *function* ? Try again :-) error.c: #undef PyErr_BadInternalCall void PyErr_BadInternalCall(void) { PyErr_SetString(PyExc_SystemError, "bad argument to internal function"); } void _PyErr_BadInternalCall(char *filename, int lineno) { PyErr_Format(PyExc_SystemError, "%s:%d: bad argument to internal function", filename, lineno); } ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101214&group_id=5470 From tim_one@email.msn.com Sat Aug 19 18:23:22 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 19 Aug 2000 13:23:22 -0400 Subject: [Patches] [Patch #101055] Cookie.py In-Reply-To: Message-ID: Please don't discuss patches on the patches list . From http://python.sourceforge.net/sf-faq.html: Discussion of major patches is carried out on the Python-Dev mailing list. For simple patches, the SourceForge comment mechanism should be sufficient. [xxx an email gateway would be great, ditto Ping's Roundup] Not all developers read patches-list, discussions *always* end up getting x-posted to Python-Dev too, and then some do and some don't, and then it's impossible to follow the discussion. So Guido asked that we stop using the patches-list for discussion, and that's where the rule above came from. Thanks. > -----Original Message----- > From: patches-admin@python.org [mailto:patches-admin@python.org]On > Behalf Of Moshe Zadka > Sent: Saturday, August 19, 2000 5:39 AM > To: Fred L. Drake, Jr. > Cc: noreply@sourceforge.net; akuchlin@mems-exchange.org; > patches@python.org > Subject: Re: [Patches] [Patch #101055] Cookie.py > > > On Fri, 18 Aug 2000, Fred L. Drake, Jr. wrote: > > > That would have no effect on any of the Python tagging. It's > > probably worthwhile making sure there are no tags in the ,v file, but > > that can be done after it gets dropped in place. > > Now, Greg Stein will tell us that dropping this into place is the > > wrong thing to do. What it *will* screw up is people asking for the > > state of Python at a specific date before the file was actually added; > > they'll get this file even for when it wasn't in the Python CVS tree. > > I can live with that, but we should make a policy decision for the > > Python tree regarding this sort of thing. > > Do we really need the ',v' version? It's not like we'll revert to > any previous version. And by the way, there are a couple of things > we should consider changing before slating this up for an official > release: > > 1) Change __repr__ --> __str__, and give an honest __repr__ > 2) Deprecate SmartCookie and SerilizedCookie: those two are real security > holes, and I'm worried it might give Python an undeserved unsecure > reputation. Or, maybe, add a mandatory password and only accept md5 > signed versions. > > We *can* break backwards compatability now, because Cookie was not an > official part of Python, and we *should* break it now, because that's > the last chance we'll have. > > -- > Moshe Zadka > There is no IGLU cabal. > http://advogato.org/person/moshez > > > _______________________________________________ > Patches mailing list > Patches@python.org > http://www.python.org/mailman/listinfo/patches From noreply@sourceforge.net Sat Aug 19 18:37:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 10:37:44 -0700 Subject: [Patches] [Patch #101214] Improve exception message for PyErr_BadInternalCall() Message-ID: <200008191737.KAA05729@bush.i.sourceforge.net> Patch #101214 has been updated. Project: Category: core (C code) Status: Open Summary: Improve exception message for PyErr_BadInternalCall() Follow-Ups: Date: 2000-Aug-17 23:25 By: fdrake Comment: This patch uses a macro wrapper to provide the filename and line number of the call to PyErr_BadInternalCall(). This should be reasonable since the __FILE__ and __LINE__ macros are ANSI C (I think). There are 77 call sites for PyErr_BadInternalCall(), and this would make it a lot easier to get an initial foothold on errors generated through this function. ------------------------------------------------------- Date: 2000-Aug-18 07:15 By: marangoz Comment: OTOH, bad internal calls shouldn't happen, but I like this. You want to make my life easier as a developer, not as a user. +0, modulo the fact that you removed the original function from the API. External modules may fail. Let's keep the original function and its signature in the code. (this requires some preprocessor trickery). ------------------------------------------------------- Date: 2000-Aug-18 10:42 By: fdrake Comment: Add PyErr_BadInternalCall() entry point back for legacy compiled code, but continue to mask it for new code. ------------------------------------------------------- Date: 2000-Aug-19 13:13 By: marangoz Comment: Where's the legacy PyErr_BadInternalCall(void) *function* ? Try again :-) error.c: #undef PyErr_BadInternalCall void PyErr_BadInternalCall(void) { PyErr_SetString(PyExc_SystemError, "bad argument to internal function"); } void _PyErr_BadInternalCall(char *filename, int lineno) { PyErr_Format(PyExc_SystemError, "%s:%d: bad argument to internal function", filename, lineno); } ------------------------------------------------------- Date: 2000-Aug-19 13:37 By: fdrake Comment: Ok, here 'tis... forgot to regenerate the patch before uploading it last time. Sorry! ;-( ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101214&group_id=5470 From guido@python.org Fri Aug 18 22:25:46 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 18 Aug 2000 17:25:46 -0400 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict References: <200008160935.CAA24745@delerium.i.sourceforge.net> Message-ID: <011701c00a1f$99902ac0$7aa41718@beopen.com> Can't see the patch or any more recent discussion here (still on a plane!), so apologies if this is taken care of. Isn't it confusing to have a get() method that doesn't return the same thing as __getitem__()? If I understand the discussion below correctly, to get the value for 'foo' you must use x['foo'].value but now you can also use x.get('foo') ??? That's inconsistent compared to how these two behave for regular dictionaries! --Guido ----- Original Message ----- From: To: ; ; Sent: Wednesday, August 16, 2000 5:35 AM Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict > Patch #101120 has been updated. > > Project: > Category: library > Status: Accepted > Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict > > Follow-Ups: > > Date: 2000-Aug-08 13:28 > By: ping > > Comment: > This actually adds all of the auxiliary dictionary > methods to FormContentDict (e.g. copy, update) since > it makes FormContentDict derive from UserDict. > > __version__ has been incremented to 2.3. > ------------------------------------------------------- > > Date: 2000-Aug-15 14:38 > By: tim_one > > Comment: > Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). > ------------------------------------------------------- > > Date: 2000-Aug-15 23:36 > By: tim_one > > Comment: > Assigned to Barry (sorry, Barry!) for sanity-checking. > > Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. > > Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. > ------------------------------------------------------- > > Date: 2000-Aug-15 23:41 > By: tim_one > > Comment: > Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . > > ------------------------------------------------------- > > Date: 2000-Aug-16 00:28 > By: moshez > > Comment: > OK, I gave it a short run around and it looked quite > all right. I do have on qualm, Ping: it's a bit awkward > to use .get() like that, because you still have to check > whether to use .value or not. > > Here's an example of what I mean > (I hope if I surround it with PRE tags it will be protected): > > 
> print cgi.FieldStorage().get("hello",
>              cgi.MiniFieldStorage("hello", "world)).value
>
> > Because otherwise .get() doesn't buy you much. However, > other then that it's great -- accept that there still > aren't docos and test cases. (So I've kept this "Open") > > ------------------------------------------------------- > > Date: 2000-Aug-16 02:16 > By: ping > > Comment: > Okay, here's the new patch. There is quite a bit more now: > > 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) > > 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. > > 3. FormContentDict is derived from UserDict (same as the original patch). > > 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. > > 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. > > Phew. > ------------------------------------------------------- > > Date: 2000-Aug-16 02:35 > By: moshez > > Comment: > OK, this one looks fine to me! I didn't test it again, > though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation > and it looks great! > > ------------------------------------------------------- > > ------------------------------------------------------- > For more info, visit: > > http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 > > _______________________________________________ > Patches mailing list > Patches@python.org > http://www.python.org/mailman/listinfo/patches From noreply@sourceforge.net Sat Aug 19 22:23:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 14:23:03 -0700 Subject: [Patches] [Patch #101234] Allow all assignment expressions after 'import something as' Message-ID: <200008192123.OAA00821@delerium.i.sourceforge.net> Patch #101234 has been updated. Project: Category: core (C code) Status: Open Summary: Allow all assignment expressions after 'import something as' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470 From noreply@sourceforge.net Sat Aug 19 22:29:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 14:29:03 -0700 Subject: [Patches] [Patch #101234] Allow all assignment expressions after 'import something as' Message-ID: <200008192129.OAA00978@delerium.i.sourceforge.net> Patch #101234 has been updated. Project: Category: core (C code) Status: Open Summary: Allow all assignment expressions after 'import something as' Follow-Ups: Date: 2000-Aug-19 23:29 By: twouters Comment: This absurdly simple patch (4 lines changed in 2 files) turns 'import-as' and 'from-import-as' into true assignment expressions: the name given after 'as' can be any expression that is a valid l-value: >>> from sys import version_info as (maj,min,pl,relnam,relno) >>> maj,min,pl,relnam,relno (2, 0, 0, 'beta', 1) >>> x = {} >>> import sys as x['sys'] >>> import os as x['os'] >>> x {'os': , 'sys': } >>> class X: pass ... >>> x = X() >>> import sys as x.sys >>> import os as x.os >>> import posixpath as x.posixpath >>> x.sys, x.os, x.posixpath (, , ) This looks so natural, I would almost treat this as a bugfix instead of a new feature ;) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470 From noreply@sourceforge.net Sat Aug 19 22:37:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 14:37:11 -0700 Subject: [Patches] [Patch #101215] extend 'import x as y' syntax to 'import x as y.z' Message-ID: <200008192137.OAA01278@delerium.i.sourceforge.net> Patch #101215 has been updated. Project: Category: core (C code) Status: Open Summary: extend 'import x as y' syntax to 'import x as y.z' Follow-Ups: Date: 2000-Aug-18 07:25 By: nowonder Comment: I've played a bit around with the new 'import x as y' syntax and found it would be useful to be able to assign to module/class members, too. Example from BaseHTTPServer: import SOCKS; socket = SOCKS; del SOCKS from socket import getfqdn; socket.getfqdn = getfqdn; del getfqdn could become: import SOCKS as socket # nothing new here from socket import getfqdn as socket.getfqdn # NEW! Assigned to Thomas for review. ------------------------------------------------------- Date: 2000-Aug-18 13:08 By: marangoz Comment: Before going too far with this, here's a strong -1 without even reviewing the patch. Playing with namespaces other than the current one is a bad idea. +1 on import x as y. As long as you introduce a new binding in the current namespace, being able to alter the original name for that binding is nice. -1 on import x as y.z, though, because you want to introduce a binding in a namespace which you don't own (y's namespace). For that matter, y must exist in the current namespace and allow bindings, which is not granted at all. Overall, this sucks . Example: >>> y = 1 >>> import sys as y.sys Please reject this before I see another patch update, or I'll reject it on the first update that'll hit my mailbox . ------------------------------------------------------- Date: 2000-Aug-18 13:28 By: twouters Comment: Hmm... I like the idea a bit, but it'm -1 on the approach: Special casing 'name.name' is *not* the way to go. Instead, what we can do is to allow all normal assignment expressions in the 'as ' so that you can do import shelve from myTools.cPickleFast import Pickler as shelve.Pickler as well as x = [] from sys import stdin as x[0], stdout as x[1], stderr as x[2] and class X: pass x = X() from sys import stdin as x.in, stdout as x.out, stderr as x.err and even from sys import sys.version_info as (major, minor, patchlevel, releaselevel, releaseserial) (though you'd need the parentheses to disambiguate) This is all possible by changing the Grammar slightly, and calling 'com_assign(c, )' rather than 'com_addbyte(c, STORE_NAME, )', I think. Just for laughs, I'll see if it's possible ;) It would certainly be consistent ! and it would behave exactly like import sys x = [sys.stdin, sys.stdout, sys.stderr] [insert other examples] except that sys won't be added to the local namespace. ------------------------------------------------------- Date: 2000-Aug-19 23:37 By: twouters Comment: Note that I just uploaded a smaller patch that does more than this patch. If that generalization is accepted, this patch would be obsolete. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101215&group_id=5470 From noreply@sourceforge.net Sun Aug 20 02:46:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 18:46:19 -0700 Subject: [Patches] [Patch #100970] extended print statement Message-ID: <200008200146.SAA21545@bush.i.sourceforge.net> Patch #100970 has been updated. Project: Category: core (C code) Status: Accepted Summary: extended print statement Follow-Ups: Date: 2000-Jul-23 22:44 By: bwarsaw Comment: This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout). This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement. An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM. I'm not sure which approach is better. ------------------------------------------------------- Date: 2000-Jul-23 22:45 By: bwarsaw Comment: The following is an example of how you might use the new extended print statement. 
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
------------------------------------------------------- Date: 2000-Aug-15 14:00 By: tim_one Comment: Assigned to Guido for Pronouncement. This was already discussed on Python-Dev. Mix of opinions there. I like it fine. Barry, this needs docs and test cases Real Soon if you want it considered for 2.0. I like the PRINT_TO idea better. ------------------------------------------------------- Date: 2000-Aug-15 18:43 By: bwarsaw Comment: Revised patch which uses the PRINT_ITEM_TO approach favored by Tim. This patch also includes doc and test suite updates. Please see PEP 214 for a discussion of the issues. This feature should be postponed until Python 2.1 ------------------------------------------------------- Date: 2000-Aug-15 19:05 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-15 19:16 By: bwarsaw Comment: Okay, I just thought that with the open issue (see PEP 214) it might not be ready for prime time. Let's wait for the BDFL pronounce before postponing. ------------------------------------------------------- Date: 2000-Aug-15 19:33 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-16 10:56 By: bwarsaw Comment: After channeling and encouragement from Tim, this patch represents the current definition of the feature as described in PEP 214. It is now ready for BDFL pronouncement for Python 2.0. ------------------------------------------------------- Date: 2000-Aug-17 15:31 By: gvanrossum Comment: I'm still not convinced. Let's save this for reopening in 2.1. I'm worried about language bloat... Assigned to Tim just so that he can reopen the debate when he sees fit. ------------------------------------------------------- Date: 2000-Aug-19 21:46 By: tim_one Comment: Changed status from Postponed to Accepted and assigned back to Barry for checkin. Ruling from Guido follows: I'm still reading my email off-line on the plane. I've now read PEP 214 and think I'll reverse my opinion: it's okay. Barry, check it in! (And change the SF PM status to 'Accepted'.) I think I'll start using it for error messages: errors should go to stderr, but it's often inconvenient, so in minor scripts instead of doing sys.stderr.write("Error: can't open %s\n" % filename) I often write print "Error: can't open", filename which is incorrect but more convenient. I can now start using print >>sys.stderr, "Error: can't open", filename --Guido ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470 From noreply@sourceforge.net Sun Aug 20 02:47:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 18:47:40 -0700 Subject: [Patches] [Patch #100874] Better error message with UnboundLocalError Message-ID: <200008200147.SAA21647@bush.i.sourceforge.net> Patch #100874 has been updated. Project: Category: None Status: Accepted Summary: Better error message with UnboundLocalError Follow-Ups: Date: 2000-Jul-13 00:56 By: tim_one Comment: Rejected and assigned back to Paul. I like the idea fine, the rejection is for style reasons and a repeated security hole. Please make the code look like the rest of ceval.c -- idiosyncracies (that aren't Guido's <0.3 wink>) are harmful in group-maintained code. Examples: > PyObject *nm=NULL; Should be a space on each side of "=". Ditto throughout the patch. BTW, is "nm" meant to be an abbreviation for "name"? If so, please spell out the two extra letters. If it's meant to be an abbreviation for New Mexico, capitalize it . > if(!nm) break; "if" isn't a function call: use a space between "if" and "(". It's also bad to slop "break" on the same line: makes it much harder to set a useful breakpoint here in a debugger. Everywhere else in the code this line would be spelled (if Guido wrote it -- and the "\t" business here is because SF comments don't preserve indentation): \tif (!nm) \t\tbreak > sprintf( buf, "Local variable %s No space between "(" and "buf" here. > PyExc_UnboundLocalError, buf ); No space between "buf" and ")" here. > char buf[500]; > ... followed by an unchecked sprintf into buf. This is a security hole: Python doesn't restrict identifiers to being no longer than 500 chars, so a hacker can easily trick this code into overwriting the buffer bounds. Easy but tedious to fix (e.g., #define the buf length, and use runtime code in conjunction with strncpy to guarantee buf's bounds are respected). ------------------------------------------------------- Date: 2000-Jul-14 17:17 By: prescod Comment: Small helper function format_exc_check_arg makes it easy to generate one string and a argument-type exceptions. It may be overkill in terms of null checking...reviewer can decide. Otherwise, error messages are added to NameErrors and UnboundLocalErrors. That means that all exceptions thrown in ceval have associated error messages. ------------------------------------------------------- Date: 2000-Jul-18 09:32 By: twouters Comment: The helper function is declared 'static', but not defined as such. Rest of the style issues seem solved ;) ------------------------------------------------------- Date: 2000-Jul-26 02:56 By: tim_one Comment: Accepted and assigned back to Paul. Paul, the new format_exc_check_arg function is defined K&R-style, but we've moved to ANSI almost everywhere else in the source. Would be nice if you fix that before checking this in. Else I'll look for it and fix it myself. Sorry for the delay in getting back to this! ------------------------------------------------------- Date: 2000-Aug-15 14:10 By: tim_one Comment: Paul, this was accepted weeks ago. Are you going to check it in? ------------------------------------------------------- Date: 2000-Aug-19 21:47 By: tim_one Comment: Yo! Paul! Check it in already! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100874&group_id=5470 From noreply@sourceforge.net Sun Aug 20 02:54:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 18:54:33 -0700 Subject: [Patches] [Patch #101107] libgetopt.py extensions (REJECT version) Message-ID: <200008200154.SAA21816@bush.i.sourceforge.net> Patch #101107 has been updated. Project: Category: documentation Status: Rejected Summary: libgetopt.py extensions (REJECT version) Follow-Ups: Date: 2000-Aug-07 12:12 By: goodger Comment: (summary should say libgetopt.tex, not .py) Applies to patch 101106. Untested TeX code; I hope it works! ------------------------------------------------------- Date: 2000-Aug-19 21:54 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101107&group_id=5470 From noreply@sourceforge.net Sun Aug 20 02:51:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 18:51:29 -0700 Subject: [Patches] [Patch #101226] make threading fork-safe Message-ID: <200008200151.SAA21704@bush.i.sourceforge.net> Patch #101226 has been updated. Project: Category: core (C code) Status: Open Summary: make threading fork-safe Follow-Ups: Date: 2000-Aug-19 00:46 By: cgw Comment: See http://www.lambdacs.com/newsgroup/FAQ.html#Q120 and "man pthread_atfork" for background. I don't use a pthread_atfork handler here - the explicit approach is more portable. However calling fork() from C extensions could still cause trouble. This patch causes the child to create a new interpreter lock after doing a fork. It would be nice to deallocate the old lock with PyThread_free_lock, but this does some unwanted error-checking in addition to deallocating the lock. So I waste a little memory instead. To really do this cleanly one could add a new PyThread_reset_lock function to all the thread_*.h files, and use that instead. ------------------------------------------------------- Date: 2000-Aug-19 21:51 By: tim_one Comment: Assigned to me. I'll discuss it with Guido too. So far 2e've gotten 3 reports from people who don't see failures in assorted test cases anymore, and no reports of remaining failures. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101226&group_id=5470 From noreply@sourceforge.net Sun Aug 20 02:56:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 18:56:34 -0700 Subject: [Patches] [Patch #101109] libgetopt.tex extensions (APPEND version) Message-ID: <200008200156.SAA21875@bush.i.sourceforge.net> Patch #101109 has been updated. Project: Category: documentation Status: Rejected Summary: libgetopt.tex extensions (APPEND version) Follow-Ups: Date: 2000-Aug-07 12:13 By: goodger Comment: Applies to patch 101108. Untested TeX code; I hope it works! ------------------------------------------------------- Date: 2000-Aug-19 21:56 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101109&group_id=5470 From noreply@sourceforge.net Sun Aug 20 02:53:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 18:53:52 -0700 Subject: [Patches] [Patch #101106] getopt.py extensions (REJECT version) Message-ID: <200008200153.SAA21812@bush.i.sourceforge.net> Patch #101106 has been updated. Project: Category: library Status: Rejected Summary: getopt.py extensions (REJECT version) Follow-Ups: Date: 2000-Aug-07 12:08 By: goodger Comment: Extensions to getopt.py, REJECT version* Frank Stajano added: (1) dictionary output function getoptdict(), which returns the options in a dictionary for random access, as opposed to getopt()'s list's sequential access (example usage in libgetopt.tex); and (2) specialised exceptions subclassed from GetoptError for fine-grained control. See http://deja.com/=dnc/getdoc.xp?AN=640434359 for Frank's original post to comp.lang.python. David Goodger : (3) reworked Frank's changes; (4) made None the argument value for argumentless options, removing ambiguity for 'program -o ""' (NOTE: possibly backwards incompatible, with "if optarg == '':" instead of "if optarg:"); (5) added to command-line test mode; (6) wrote test_getopt.py; (7) updated libgetopt.tex. * Why two sets of patches? Frank Stajano abhors repeated options and insists on making REJECT the default behavior for getoptdict() (i.e., repeated options raise an exception). David Goodger feels that APPEND is the appropriate default behavior, and friendlier too. Please use one set; the only difference is the default repeatedopts=REJECT or repeatedopts=APPEND, and its documentation. REJECT: 101106, 101107, 101110 APPEND: 101108, 101109, 101110 Patch 101110 is test_getopt.py, a new regression test module (for lib/test/) which applies to both REJECT and APPEND versions. ------------------------------------------------------- Date: 2000-Aug-09 00:26 By: goodger Comment: I examined the entire 1.6b1 tarball for incompatibilities, and found only 2 in 90+ modules using getopt.py. Their patches follow (nos. 101126 mimify.py, 101127 lib-old/dircmp.py). ------------------------------------------------------- Date: 2000-Aug-19 21:53 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101106&group_id=5470 From noreply@sourceforge.net Sun Aug 20 02:55:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 18:55:04 -0700 Subject: [Patches] [Patch #101108] getopt.py extensions (APPEND version) Message-ID: <200008200155.SAA21836@bush.i.sourceforge.net> Patch #101108 has been updated. Project: Category: None Status: Open Summary: getopt.py extensions (APPEND version) Follow-Ups: Date: 2000-Aug-07 12:11 By: goodger Comment: Extensions to getopt.py, APPEND version* Frank Stajano added: (1) dictionary output function getoptdict(), which returns the options in a dictionary for random access, as opposed to getopt()'s list's sequential access (example usage in libgetopt.tex); and (2) specialised exceptions subclassed from GetoptError for fine-grained control. See http://deja.com/=dnc/getdoc.xp?AN=640434359 for Frank's original post to comp.lang.python. David Goodger : (3) reworked Frank's changes; (4) made None the argument value for argumentless options, removing ambiguity for 'program -o ""' (NOTE: possibly backwards incompatible, with "if optarg == '':" instead of "if optarg:"); (5) added to command-line test mode; (6) wrote test_getopt.py; (7) updated libgetopt.tex. * Why two sets of patches? Frank Stajano abhors repeated options and insists on making REJECT the default behavior for getoptdict() (i.e., repeated options raise an exception). David Goodger feels that APPEND is the appropriate default behavior, and friendlier too. Please use one set; the only difference is the default repeatedopts=REJECT or repeatedopts=APPEND, and its documentation. REJECT: 101106, 101107, 101110 APPEND: 101108, 101109, 101110 Patch 101110 is test_getopt.py, a new regression test module (for lib/test/) which applies to both REJECT and APPEND versions. ------------------------------------------------------- Date: 2000-Aug-09 00:27 By: goodger Comment: I examined the entire 1.6b1 tarball for incompatibilities, and found only 2 in 90+ modules using getopt.py. Their patches follow (nos. 101126 mimify.py, 101127 lib-old/dircmp.py). ------------------------------------------------------- Date: 2000-Aug-19 21:55 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101108&group_id=5470 From noreply@sourceforge.net Sun Aug 20 02:56:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 18:56:02 -0700 Subject: [Patches] [Patch #101108] getopt.py extensions (APPEND version) Message-ID: <200008200156.SAA21871@bush.i.sourceforge.net> Patch #101108 has been updated. Project: Category: None Status: Rejected Summary: getopt.py extensions (APPEND version) Follow-Ups: Date: 2000-Aug-07 12:11 By: goodger Comment: Extensions to getopt.py, APPEND version* Frank Stajano added: (1) dictionary output function getoptdict(), which returns the options in a dictionary for random access, as opposed to getopt()'s list's sequential access (example usage in libgetopt.tex); and (2) specialised exceptions subclassed from GetoptError for fine-grained control. See http://deja.com/=dnc/getdoc.xp?AN=640434359 for Frank's original post to comp.lang.python. David Goodger : (3) reworked Frank's changes; (4) made None the argument value for argumentless options, removing ambiguity for 'program -o ""' (NOTE: possibly backwards incompatible, with "if optarg == '':" instead of "if optarg:"); (5) added to command-line test mode; (6) wrote test_getopt.py; (7) updated libgetopt.tex. * Why two sets of patches? Frank Stajano abhors repeated options and insists on making REJECT the default behavior for getoptdict() (i.e., repeated options raise an exception). David Goodger feels that APPEND is the appropriate default behavior, and friendlier too. Please use one set; the only difference is the default repeatedopts=REJECT or repeatedopts=APPEND, and its documentation. REJECT: 101106, 101107, 101110 APPEND: 101108, 101109, 101110 Patch 101110 is test_getopt.py, a new regression test module (for lib/test/) which applies to both REJECT and APPEND versions. ------------------------------------------------------- Date: 2000-Aug-09 00:27 By: goodger Comment: I examined the entire 1.6b1 tarball for incompatibilities, and found only 2 in 90+ modules using getopt.py. Their patches follow (nos. 101126 mimify.py, 101127 lib-old/dircmp.py). ------------------------------------------------------- Date: 2000-Aug-19 21:55 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. ------------------------------------------------------- Date: 2000-Aug-19 21:56 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101108&group_id=5470 From noreply@sourceforge.net Sun Aug 20 02:57:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 18:57:44 -0700 Subject: [Patches] [Patch #101126] mimify.py: mods for new getopt, & tab->spaces Message-ID: <200008200157.SAA21972@bush.i.sourceforge.net> Patch #101126 has been updated. Project: Category: library Status: Rejected Summary: mimify.py: mods for new getopt, & tab->spaces Follow-Ups: Date: 2000-Aug-09 00:19 By: goodger Comment: One of only two modules in 1.6b1 tarball requiring a fix for the new getopt.py, because of empty strings in (opt, optarg) tuples. Fixes are in script portion at end (under "if __name__ == '__main__':"). While I was at it, I converted tabs to spaces (there were mixed indents before). ------------------------------------------------------- Date: 2000-Aug-19 21:57 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. The tabs->spaces part should still get done anyway (unsure whether it has been, though! I'll check). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101126&group_id=5470 From noreply@sourceforge.net Sun Aug 20 03:00:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 19:00:25 -0700 Subject: [Patches] [Patch #101110] test_getopt.py: new test module Message-ID: <200008200200.TAA22023@bush.i.sourceforge.net> Patch #101110 has been updated. Project: Category: library Status: Rejected Summary: test_getopt.py: new test module Follow-Ups: Date: 2000-Aug-07 12:15 By: goodger Comment: new regression test module, applies to either of patches 101106 or 101108. ------------------------------------------------------- Date: 2000-Aug-19 17:22 By: goodger Comment: new regression test module, applies to the existing getopt.py. ------------------------------------------------------- Date: 2000-Aug-19 22:00 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. It would be sure be appreciated if you stripped the new-functionality parts out of the module and resubmitted the patch as a current-getopt test, though! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101110&group_id=5470 From noreply@sourceforge.net Sun Aug 20 03:02:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 19:02:59 -0700 Subject: [Patches] [Patch #101110] test_getopt.py: new test module Message-ID: <200008200202.TAA22157@bush.i.sourceforge.net> Patch #101110 has been updated. Project: Category: library Status: Open Summary: test_getopt.py: new test module Follow-Ups: Date: 2000-Aug-07 12:15 By: goodger Comment: new regression test module, applies to either of patches 101106 or 101108. ------------------------------------------------------- Date: 2000-Aug-19 17:22 By: goodger Comment: new regression test module, applies to the existing getopt.py. ------------------------------------------------------- Date: 2000-Aug-19 22:00 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. It would be sure be appreciated if you stripped the new-functionality parts out of the module and resubmitted the patch as a current-getopt test, though! ------------------------------------------------------- Date: 2000-Aug-19 22:02 By: tim_one Comment: Oops! I didn't see that you already had! Sorry about that. Re-Opened and assigned to me. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101110&group_id=5470 From noreply@sourceforge.net Sun Aug 20 02:58:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 18:58:12 -0700 Subject: [Patches] [Patch #101127] lib-old/dircmp.py mods for new getopt.py Message-ID: <200008200158.SAA21986@bush.i.sourceforge.net> Patch #101127 has been updated. Project: Category: library Status: Rejected Summary: lib-old/dircmp.py mods for new getopt.py Follow-Ups: Date: 2000-Aug-09 00:23 By: goodger Comment: One of only two modules in 1.6b1 tarball requiring a fix for the new getopt.py, because of empty strings in (opt, optarg) tuples. This module may be obsolete, but it ought to be able to run! ------------------------------------------------------- Date: 2000-Aug-19 21:58 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101127&group_id=5470 From noreply@sourceforge.net Sun Aug 20 05:18:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 21:18:58 -0700 Subject: [Patches] [Patch #101110] test_getopt.py: new test module Message-ID: <200008200418.VAA25952@bush.i.sourceforge.net> Patch #101110 has been updated. Project: Category: library Status: Closed Summary: test_getopt.py: new test module Follow-Ups: Date: 2000-Aug-07 12:15 By: goodger Comment: new regression test module, applies to either of patches 101106 or 101108. ------------------------------------------------------- Date: 2000-Aug-19 17:22 By: goodger Comment: new regression test module, applies to the existing getopt.py. ------------------------------------------------------- Date: 2000-Aug-19 22:00 By: tim_one Comment: Rejected. As discussed on Python-Dev, Guido doesn't want *any* getopt enhancements in the std library at this time, despite that these are very well done. It would be sure be appreciated if you stripped the new-functionality parts out of the module and resubmitted the patch as a current-getopt test, though! ------------------------------------------------------- Date: 2000-Aug-19 22:02 By: tim_one Comment: Oops! I didn't see that you already had! Sorry about that. Re-Opened and assigned to me. Thanks! ------------------------------------------------------- Date: 2000-Aug-20 00:18 By: tim_one Comment: Closed: checked in, after purging an "import *". ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101110&group_id=5470 From noreply@sourceforge.net Sun Aug 20 05:24:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 21:24:16 -0700 Subject: [Patches] [Patch #101214] Improve exception message for PyErr_BadInternalCall() Message-ID: <200008200424.VAA26108@bush.i.sourceforge.net> Patch #101214 has been updated. Project: Category: core (C code) Status: Open Summary: Improve exception message for PyErr_BadInternalCall() Follow-Ups: Date: 2000-Aug-17 23:25 By: fdrake Comment: This patch uses a macro wrapper to provide the filename and line number of the call to PyErr_BadInternalCall(). This should be reasonable since the __FILE__ and __LINE__ macros are ANSI C (I think). There are 77 call sites for PyErr_BadInternalCall(), and this would make it a lot easier to get an initial foothold on errors generated through this function. ------------------------------------------------------- Date: 2000-Aug-18 07:15 By: marangoz Comment: OTOH, bad internal calls shouldn't happen, but I like this. You want to make my life easier as a developer, not as a user. +0, modulo the fact that you removed the original function from the API. External modules may fail. Let's keep the original function and its signature in the code. (this requires some preprocessor trickery). ------------------------------------------------------- Date: 2000-Aug-18 10:42 By: fdrake Comment: Add PyErr_BadInternalCall() entry point back for legacy compiled code, but continue to mask it for new code. ------------------------------------------------------- Date: 2000-Aug-19 13:13 By: marangoz Comment: Where's the legacy PyErr_BadInternalCall(void) *function* ? Try again :-) error.c: #undef PyErr_BadInternalCall void PyErr_BadInternalCall(void) { PyErr_SetString(PyExc_SystemError, "bad argument to internal function"); } void _PyErr_BadInternalCall(char *filename, int lineno) { PyErr_Format(PyExc_SystemError, "%s:%d: bad argument to internal function", filename, lineno); } ------------------------------------------------------- Date: 2000-Aug-19 13:37 By: fdrake Comment: Ok, here 'tis... forgot to regenerate the patch before uploading it last time. Sorry! ;-( ------------------------------------------------------- Date: 2000-Aug-20 00:24 By: tim_one Comment: Assigned to Vladimir since his is the natural next voice. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101214&group_id=5470 From noreply@sourceforge.net Sun Aug 20 05:31:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 21:31:42 -0700 Subject: [Patches] [Patch #101233] PyModule_AddObject() and friends Message-ID: <200008200431.VAA26304@bush.i.sourceforge.net> Patch #101233 has been updated. Project: Category: core (C code) Status: Open Summary: PyModule_AddObject() and friends Follow-Ups: Date: 2000-Aug-19 13:17 By: marangoz Comment: Looks good. BDFL need to Pronounce on API issues. What amount of changes would this imply in the distrib? Have patch? (the names could be tuned later directly in the patch ) ------------------------------------------------------- Date: 2000-Aug-20 00:31 By: tim_one Comment: Assigned to Guido because, as Vlad says, he needs to Prounounce on the idea. Guido, the point here is to provide a single implementation to replace all the repeated and inconsistent functions and macros that modules are defining today for use in their init functions. Was discussed on Python-Dev and was well-received there. Andrew, I dislike the name PyModule_AddConstantLong, because that Python ints *happen* to be C longs should be an implementation detail. Since the function is actually adding a Python int, I'm afraid I like PyModule_AddConstantInt better. Oh, yuck. Ah! PyModule_AddConstantPyInt. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101233&group_id=5470 From noreply@sourceforge.net Sun Aug 20 15:13:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Aug 2000 07:13:26 -0700 Subject: [Patches] [Patch #101238] PyOS_CheckStack for Windows (MSVC) Message-ID: <200008201413.HAA01921@delerium.i.sourceforge.net> Patch #101238 has been updated. Project: Category: core (C code) Status: Open Summary: PyOS_CheckStack for Windows (MSVC) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101238&group_id=5470 From noreply@sourceforge.net Sun Aug 20 20:51:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Aug 2000 12:51:30 -0700 Subject: [Patches] [Patch #101215] extend 'import x as y' syntax to 'import x as y.z' Message-ID: <200008201951.MAA13088@delerium.i.sourceforge.net> Patch #101215 has been updated. Project: Category: core (C code) Status: Rejected Summary: extend 'import x as y' syntax to 'import x as y.z' Follow-Ups: Date: 2000-Aug-18 05:25 By: nowonder Comment: I've played a bit around with the new 'import x as y' syntax and found it would be useful to be able to assign to module/class members, too. Example from BaseHTTPServer: import SOCKS; socket = SOCKS; del SOCKS from socket import getfqdn; socket.getfqdn = getfqdn; del getfqdn could become: import SOCKS as socket # nothing new here from socket import getfqdn as socket.getfqdn # NEW! Assigned to Thomas for review. ------------------------------------------------------- Date: 2000-Aug-18 11:08 By: marangoz Comment: Before going too far with this, here's a strong -1 without even reviewing the patch. Playing with namespaces other than the current one is a bad idea. +1 on import x as y. As long as you introduce a new binding in the current namespace, being able to alter the original name for that binding is nice. -1 on import x as y.z, though, because you want to introduce a binding in a namespace which you don't own (y's namespace). For that matter, y must exist in the current namespace and allow bindings, which is not granted at all. Overall, this sucks . Example: >>> y = 1 >>> import sys as y.sys Please reject this before I see another patch update, or I'll reject it on the first update that'll hit my mailbox . ------------------------------------------------------- Date: 2000-Aug-18 11:28 By: twouters Comment: Hmm... I like the idea a bit, but it'm -1 on the approach: Special casing 'name.name' is *not* the way to go. Instead, what we can do is to allow all normal assignment expressions in the 'as ' so that you can do import shelve from myTools.cPickleFast import Pickler as shelve.Pickler as well as x = [] from sys import stdin as x[0], stdout as x[1], stderr as x[2] and class X: pass x = X() from sys import stdin as x.in, stdout as x.out, stderr as x.err and even from sys import sys.version_info as (major, minor, patchlevel, releaselevel, releaseserial) (though you'd need the parentheses to disambiguate) This is all possible by changing the Grammar slightly, and calling 'com_assign(c, )' rather than 'com_addbyte(c, STORE_NAME, )', I think. Just for laughs, I'll see if it's possible ;) It would certainly be consistent ! and it would behave exactly like import sys x = [sys.stdin, sys.stdout, sys.stderr] [insert other examples] except that sys won't be added to the local namespace. ------------------------------------------------------- Date: 2000-Aug-19 21:37 By: twouters Comment: Note that I just uploaded a smaller patch that does more than this patch. If that generalization is accepted, this patch would be obsolete. ------------------------------------------------------- Date: 2000-Aug-20 19:51 By: nowonder Comment: Obsolete. After seeing Thomas' version, I am -1 on this patch (which was only a hack anyway). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101215&group_id=5470 From noreply@sourceforge.net Sun Aug 20 21:02:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Aug 2000 13:02:32 -0700 Subject: [Patches] [Patch #101234] Allow all assignment expressions after 'import something as' Message-ID: <200008202002.NAA13530@delerium.i.sourceforge.net> Patch #101234 has been updated. Project: Category: core (C code) Status: Open Summary: Allow all assignment expressions after 'import something as' Follow-Ups: Date: 2000-Aug-19 21:29 By: twouters Comment: This absurdly simple patch (4 lines changed in 2 files) turns 'import-as' and 'from-import-as' into true assignment expressions: the name given after 'as' can be any expression that is a valid l-value: >>> from sys import version_info as (maj,min,pl,relnam,relno) >>> maj,min,pl,relnam,relno (2, 0, 0, 'beta', 1) >>> x = {} >>> import sys as x['sys'] >>> import os as x['os'] >>> x {'os': , 'sys': } >>> class X: pass ... >>> x = X() >>> import sys as x.sys >>> import os as x.os >>> import posixpath as x.posixpath >>> x.sys, x.os, x.posixpath (, , ) This looks so natural, I would almost treat this as a bugfix instead of a new feature ;) ------------------------------------------------------- Date: 2000-Aug-20 20:02 By: nowonder Comment: Looks fine. Works as I expect. Doesn't break old code. I hope Guido likes it (assigned to gvanrossum). Talk about beautiful! I *love* this patch -- feels so natural. It was just what I wanted to do. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470 From noreply@sourceforge.net Sun Aug 20 21:47:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Aug 2000 13:47:47 -0700 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' Message-ID: <200008202047.NAA25942@bush.i.sourceforge.net> Patch #101243 has been updated. Project: Category: None Status: Open Summary: Use a compile time mechanism to 'find "import-from" args' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 From noreply@sourceforge.net Sun Aug 20 21:57:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Aug 2000 13:57:31 -0700 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' Message-ID: <200008202057.NAA15551@delerium.i.sourceforge.net> Patch #101243 has been updated. Project: Category: core (C code) Status: Open Summary: Use a compile time mechanism to 'find "import-from" args' Follow-Ups: Date: 2000-Aug-20 22:57 By: twouters Comment: This patch changes the mechanism used to find the 'import-arguments' as passed to __import__ (and used by 'ni' and such dynamic import mechanisms.) The current mechanism looks into the 'future' bytecode stream (from the IMPORT_NAME statement onward) looking for IMPORT_FROM statements. The problem is that this limits the extend in which we can change IMPORT_FROM, and that this is a runtime check for information which was available at compile-time. Instead, we create a list of import-from arguments, and push it on the stack. The list creation is still done at runtime (it has to be, I think ?) but it's a simple push-constants-on-the-stack-and-BUILD_LIST operation. The result is that all 'import arguments' (the names imported-from another module) are present not only as normal 'names' in the co_names list, but also as PyString objects in the co_consts list. And that pystone runs a few promille faster on my machine. And that more trickery is allowed in imports, such as those that patch #101234 allows. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 From thomas@xs4all.net Sun Aug 20 22:14:51 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 20 Aug 2000 23:14:51 +0200 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' In-Reply-To: <200008202057.NAA15551@delerium.i.sourceforge.net>; from noreply@sourceforge.net on Sun, Aug 20, 2000 at 01:57:31PM -0700 References: <200008202057.NAA15551@delerium.i.sourceforge.net> Message-ID: <20000820231451.E4797@xs4all.nl> On Sun, Aug 20, 2000 at 01:57:31PM -0700, noreply@sourceforge.net wrote: > Comment: > [..] The problem is that this limits the extend in [..] ^^^^^^^^ Sigh. When I start making typos like that and I don't catch it on the third re-read, it means I need sleep ;) That should have been 'extent', of course. Ohwell, Brimstone is on, I'll catch up on email tomorrow :) I-can-write-english--really-I-can-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Mon Aug 21 04:42:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Aug 2000 20:42:47 -0700 Subject: [Patches] [Patch #100699] Augmented Assignment, the Python Way (huge) Message-ID: <200008210342.UAA29071@delerium.i.sourceforge.net> Patch #100699 has been updated. Project: Category: core (C code) Status: Open Summary: Augmented Assignment, the Python Way (huge) Follow-Ups: Date: 2000-Jul-01 00:49 By: twouters Comment: This patch adds augmented assignment (+=, **=, etc) to Python, in a manner which seems consistent with Guido and Tim's wishes (for as far as I know them.) Guido has already stated this patch will not make it to Python 2.0, so the first to read this should probably set the state to 'postponed'. I'll try and keep this patch up to date none the less, for peer (or rather parent ;) reviewal. The patch adds everything in one smack: Syntax, a new type of bytecode (2-argument), 9 new bytecodes, 13 new API calls, 11 new PyNumber_Methods members, 2 new PySequence_Methods members, and support for the new functionality in builtin types and supplied Python classes. Oh, and a test suite. None the less, it isn't that intrusive a patch, and the simplicity of the implementation still boggles me. For more information, see http://www.xs4all.nl/~thomas/python/ Comments greatly appreciated! Contact me on thomas@xs4all.net (I'm not on python-dev) ------------------------------------------------------- Date: 2000-Jul-01 01:10 By: gvanrossum Comment: Cool! We'll look at this after 2.0 is released... ------------------------------------------------------- Date: 2000-Jul-13 20:53 By: jhylton Comment: This patch needs to be postponed until the PEP is written. ------------------------------------------------------- Date: 2000-Jul-25 13:37 By: gvanrossum Comment: Not ready to be checked in, but Thomas is working on it! This will be in 2.0 after all... ------------------------------------------------------- Date: 2000-Aug-06 12:33 By: twouters Comment: New version of the patch, that eliminates the need for 2-argument opcodes and the GETSET_* opcodes. Instead, INPLACE_* opcodes are used, that mirror the BINARY_* opcodes, and two new 'utility' opcodes: ROT_FOUR and DUP_TOPX (duplicates the top items on the stack.) The PEP documenting this implementation will follow soon. ------------------------------------------------------- Date: 2000-Aug-21 03:42 By: gvanrossum Comment: BDFL pronouncement: please use __iadd__, __imul__ etc. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100699&group_id=5470 From noreply@sourceforge.net Mon Aug 21 13:38:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 05:38:45 -0700 Subject: [Patches] [Patch #101170] Prevent old extensions from crashing Message-ID: <200008211238.FAA14570@delerium.i.sourceforge.net> Patch #101170 has been updated. Project: Category: Windows Status: Postponed Summary: Prevent old extensions from crashing Follow-Ups: Date: 2000-Aug-12 18:55 By: chega Comment: This patch will prevent old (1.5/1.6) extensions from crashing under Python 2.0 (Also changed pathbuf[260] to pathbuf[MAX_PATH]) ------------------------------------------------------- Date: 2000-Aug-16 08:26 By: tim_one Comment: Assigned to MarkH. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-16 09:26 By: mhammond Comment: I'm not sure this is worth adding. Note that we already have code to prevent a crash in place - however, rather than raising an exception it simply calls Py_FatalError. This patch is potentially better, except that: * It will require regressing the patch made to modsupport.c (Rev 2.50) to prevent the same problem; that code will prevent this code kicking in! * It hard-codes the Python DLL names. This makes long term maintenance a PITA, and yet another file that needs to be updated when a version bumps. Are there other alternatives? * Once the module has been loaded, it may be too late to save the process anyway. I realize that the module init hasnt been called yet, but the module has been loaded, and may be doing things in its DllMain() that will destabilize the process. The big killer is simply that this code will never be triggered, as the check in modsupport.c will kick in first. Setting to postponed until we can get a better handle on this. A big advantage is that this style of change is not dependent on _old_ versions having the patch, only one actually running. Hence we can revive this patch at any time, and have it start working immediately. ------------------------------------------------------- Date: 2000-Aug-16 09:49 By: tim_one Comment: I agree with Postponing it. Thanks for the quick response! Feel like reviewing 7 controversial getopt patches now ? ------------------------------------------------------- Date: 2000-Aug-16 10:10 By: chega Comment: * The patch to modsupport.c will NOT save us in the case when someone loads 1.5 extension. See Guido's checkin comment. And I think that Python 1.6 will never be widely spread anyways, so in 99.9% cases it'll be 1.5 vs 2.0. * I agree that the hard-coded dll-names are PITA, but only a small one :-). The version check #if will make sure that this list gets updated. Also, if we keep Guido's patch in modsupport.c the list won't need updating. * I'd rather have an ImportError that PyFatalError() * I find the argument about DllMain() screwing up the process somewhat err... artificial ;-))) I have never seen such a module. Have you? The only thing I am not sure about is whether there is any legitimate reason to have python15 loaded. AFAIR, python COM servers are alwaus out-of-process, aren't they? Can you think of something else? If such reasons do exist, we may want to put another check before loading the module and then bypass the post-check if python15 has been already loaded. ------------------------------------------------------- Date: 2000-Aug-21 22:38 By: mhammond Comment: Another alternative would be to create a Win32 event object, with name "Python-%d" % pid, and have DllMain() attempt to acquire it. This would prevent the "old" Python subsystem starting at all, nipping it right in the bud (and should return a clean ImportError back to the caller!) Does this sound worthwhile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101170&group_id=5470 From noreply@sourceforge.net Mon Aug 21 13:43:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 05:43:49 -0700 Subject: [Patches] [Patch #101170] Prevent old extensions from crashing Message-ID: <200008211243.FAA14752@delerium.i.sourceforge.net> Patch #101170 has been updated. Project: Category: Windows Status: Postponed Summary: Prevent old extensions from crashing Follow-Ups: Date: 2000-Aug-12 18:55 By: chega Comment: This patch will prevent old (1.5/1.6) extensions from crashing under Python 2.0 (Also changed pathbuf[260] to pathbuf[MAX_PATH]) ------------------------------------------------------- Date: 2000-Aug-16 08:26 By: tim_one Comment: Assigned to MarkH. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-16 09:26 By: mhammond Comment: I'm not sure this is worth adding. Note that we already have code to prevent a crash in place - however, rather than raising an exception it simply calls Py_FatalError. This patch is potentially better, except that: * It will require regressing the patch made to modsupport.c (Rev 2.50) to prevent the same problem; that code will prevent this code kicking in! * It hard-codes the Python DLL names. This makes long term maintenance a PITA, and yet another file that needs to be updated when a version bumps. Are there other alternatives? * Once the module has been loaded, it may be too late to save the process anyway. I realize that the module init hasnt been called yet, but the module has been loaded, and may be doing things in its DllMain() that will destabilize the process. The big killer is simply that this code will never be triggered, as the check in modsupport.c will kick in first. Setting to postponed until we can get a better handle on this. A big advantage is that this style of change is not dependent on _old_ versions having the patch, only one actually running. Hence we can revive this patch at any time, and have it start working immediately. ------------------------------------------------------- Date: 2000-Aug-16 09:49 By: tim_one Comment: I agree with Postponing it. Thanks for the quick response! Feel like reviewing 7 controversial getopt patches now ? ------------------------------------------------------- Date: 2000-Aug-16 10:10 By: chega Comment: * The patch to modsupport.c will NOT save us in the case when someone loads 1.5 extension. See Guido's checkin comment. And I think that Python 1.6 will never be widely spread anyways, so in 99.9% cases it'll be 1.5 vs 2.0. * I agree that the hard-coded dll-names are PITA, but only a small one :-). The version check #if will make sure that this list gets updated. Also, if we keep Guido's patch in modsupport.c the list won't need updating. * I'd rather have an ImportError that PyFatalError() * I find the argument about DllMain() screwing up the process somewhat err... artificial ;-))) I have never seen such a module. Have you? The only thing I am not sure about is whether there is any legitimate reason to have python15 loaded. AFAIR, python COM servers are alwaus out-of-process, aren't they? Can you think of something else? If such reasons do exist, we may want to put another check before loading the module and then bypass the post-check if python15 has been already loaded. ------------------------------------------------------- Date: 2000-Aug-21 22:38 By: mhammond Comment: Another alternative would be to create a Win32 event object, with name "Python-%d" % pid, and have DllMain() attempt to acquire it. This would prevent the "old" Python subsystem starting at all, nipping it right in the bud (and should return a clean ImportError back to the caller!) Does this sound worthwhile? ------------------------------------------------------- Date: 2000-Aug-21 22:43 By: mhammond Comment: Oops - I should have mentioned - Jack Jansen mailed me with the DllMain() idea :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101170&group_id=5470 From noreply@sourceforge.net Mon Aug 21 15:33:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 07:33:46 -0700 Subject: [Patches] [Patch #101246] Let tramslate() method work with unicode data. Message-ID: <200008211433.HAA28402@bush.i.sourceforge.net> Patch #101246 has been updated. Project: Category: Modules Status: Open Summary: Let tramslate() method work with unicode data. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101246&group_id=5470 From noreply@sourceforge.net Mon Aug 21 16:07:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 08:07:01 -0700 Subject: [Patches] [Patch #101246] Let translate() method work with unicode data. Message-ID: <200008211507.IAA29610@bush.i.sourceforge.net> Patch #101246 has been updated. Project: Category: Modules Status: Open Summary: Let translate() method work with unicode data. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101246&group_id=5470 From noreply@sourceforge.net Mon Aug 21 16:08:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 08:08:30 -0700 Subject: [Patches] [Patch #101246] Let UserString.translate() method work with unicode data Message-ID: <200008211508.IAA29641@bush.i.sourceforge.net> Patch #101246 has been updated. Project: Category: Modules Status: Accepted Summary: Let UserString.translate() method work with unicode data Follow-Ups: Date: 2000-Aug-21 15:08 By: gvanrossum Comment: So simple it should go in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101246&group_id=5470 From noreply@sourceforge.net Mon Aug 21 16:11:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 08:11:12 -0700 Subject: [Patches] [Patch #101249] port to Monterey (64-bit AIX) and pthread fix Message-ID: <200008211511.IAA20075@delerium.i.sourceforge.net> Patch #101249 has been updated. Project: Category: Build Status: Open Summary: port to Monterey (64-bit AIX) and pthread fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101249&group_id=5470 From noreply@sourceforge.net Mon Aug 21 16:07:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 08:07:40 -0700 Subject: [Patches] [Patch #101246] Let UserString.translate() method work with unicode data Message-ID: <200008211507.IAA29619@bush.i.sourceforge.net> Patch #101246 has been updated. Project: Category: Modules Status: Open Summary: Let UserString.translate() method work with unicode data ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101246&group_id=5470 From noreply@sourceforge.net Mon Aug 21 16:16:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 08:16:44 -0700 Subject: [Patches] [Patch #101249] port to Monterey (64-bit AIX) and pthread fix Message-ID: <200008211516.IAA20286@delerium.i.sourceforge.net> Patch #101249 has been updated. Project: Category: Build Status: Open Summary: port to Monterey (64-bit AIX) and pthread fix Follow-Ups: Date: 2000-Aug-21 15:16 By: tmick Comment: This patch partly (some stuff went in already) ports Python to Monterey. Remember to 'autoconf' and 'autoheader'. - Fix bug in thread_pthread.h::PyThread_get_thread_ident() where sizeof(pthread) < sizeof(long). As Tim sort of suggested, note that function is inherently hosed. - Add 'configure' for: - SIZEOF_PTHREAD is pthread_t can be included via - setting Monterey system name - appropriate CC,LINKCC,LDSHARED,OPT, and CCSHARED for Monterey - Add section in README for Monterey build ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101249&group_id=5470 From noreply@sourceforge.net Mon Aug 21 16:18:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 08:18:40 -0700 Subject: [Patches] [Patch #101249] port to Monterey (64-bit AIX) and pthread fix Message-ID: <200008211518.IAA20413@delerium.i.sourceforge.net> Patch #101249 has been updated. Project: Category: Build Status: Open Summary: port to Monterey (64-bit AIX) and pthread fix Follow-Ups: Date: 2000-Aug-21 15:16 By: tmick Comment: This patch partly (some stuff went in already) ports Python to Monterey. Remember to 'autoconf' and 'autoheader'. - Fix bug in thread_pthread.h::PyThread_get_thread_ident() where sizeof(pthread) < sizeof(long). As Tim sort of suggested, note that function is inherently hosed. - Add 'configure' for: - SIZEOF_PTHREAD is pthread_t can be included via - setting Monterey system name - appropriate CC,LINKCC,LDSHARED,OPT, and CCSHARED for Monterey - Add section in README for Monterey build ------------------------------------------------------- Date: 2000-Aug-21 15:18 By: tmick Comment: Tim, could you verify my thread_pthread.h change and then pass this off to some Unix-weenie, as you say, to check the Autoconf changes. Thanks ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101249&group_id=5470 From noreply@sourceforge.net Mon Aug 21 16:34:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 08:34:34 -0700 Subject: [Patches] [Patch #101249] port to Monterey (64-bit AIX) and pthread fix Message-ID: <200008211534.IAA30547@bush.i.sourceforge.net> Patch #101249 has been updated. Project: Category: Build Status: Open Summary: port to Monterey (64-bit AIX) and pthread fix Follow-Ups: Date: 2000-Aug-21 15:16 By: tmick Comment: This patch partly (some stuff went in already) ports Python to Monterey. Remember to 'autoconf' and 'autoheader'. - Fix bug in thread_pthread.h::PyThread_get_thread_ident() where sizeof(pthread) < sizeof(long). As Tim sort of suggested, note that function is inherently hosed. - Add 'configure' for: - SIZEOF_PTHREAD is pthread_t can be included via - setting Monterey system name - appropriate CC,LINKCC,LDSHARED,OPT, and CCSHARED for Monterey - Add section in README for Monterey build ------------------------------------------------------- Date: 2000-Aug-21 15:18 By: tmick Comment: Tim, could you verify my thread_pthread.h change and then pass this off to some Unix-weenie, as you say, to check the Autoconf changes. Thanks ------------------------------------------------------- Date: 2000-Aug-21 15:34 By: gvanrossum Comment: Hm. is it a good idea to check in this many changes for a compiler that's in beta test? I bet that by the time the Monterey64 compiler is out of beta half of these hacks are no longer necessary. And how many other people are in a position to need these changes? [Not rejecting, just reflecting...] ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101249&group_id=5470 From noreply@sourceforge.net Mon Aug 21 17:29:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 09:29:26 -0700 Subject: [Patches] [Patch #101250] Use '*args' instead of providing defaults in User*.py Message-ID: <200008211629.JAA32645@bush.i.sourceforge.net> Patch #101250 has been updated. Project: Category: library Status: Open Summary: Use '*args' instead of providing defaults in User*.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101250&group_id=5470 From noreply@sourceforge.net Mon Aug 21 17:30:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 09:30:50 -0700 Subject: [Patches] [Patch #101250] Use '*args' instead of providing defaults in User*.py Message-ID: <200008211630.JAA32764@bush.i.sourceforge.net> Patch #101250 has been updated. Project: Category: library Status: Open Summary: Use '*args' instead of providing defaults in User*.py Follow-Ups: Date: 2000-Aug-21 18:30 By: twouters Comment: Use the '*args' construct rather than providing function defaults that are passed on to the underlying datatype, in the UserList, UserDict and UserString modules. Note: UserString.encode() might like a **kwargs argument as well, I don't know how it's used. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101250&group_id=5470 From noreply@sourceforge.net Mon Aug 21 17:52:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 09:52:48 -0700 Subject: [Patches] [Patch #101249] port to Monterey (64-bit AIX) and pthread fix Message-ID: <200008211652.JAA23779@delerium.i.sourceforge.net> Patch #101249 has been updated. Project: Category: Build Status: Open Summary: port to Monterey (64-bit AIX) and pthread fix Follow-Ups: Date: 2000-Aug-21 15:16 By: tmick Comment: This patch partly (some stuff went in already) ports Python to Monterey. Remember to 'autoconf' and 'autoheader'. - Fix bug in thread_pthread.h::PyThread_get_thread_ident() where sizeof(pthread) < sizeof(long). As Tim sort of suggested, note that function is inherently hosed. - Add 'configure' for: - SIZEOF_PTHREAD is pthread_t can be included via - setting Monterey system name - appropriate CC,LINKCC,LDSHARED,OPT, and CCSHARED for Monterey - Add section in README for Monterey build ------------------------------------------------------- Date: 2000-Aug-21 15:18 By: tmick Comment: Tim, could you verify my thread_pthread.h change and then pass this off to some Unix-weenie, as you say, to check the Autoconf changes. Thanks ------------------------------------------------------- Date: 2000-Aug-21 15:34 By: gvanrossum Comment: Hm. is it a good idea to check in this many changes for a compiler that's in beta test? I bet that by the time the Monterey64 compiler is out of beta half of these hacks are no longer necessary. And how many other people are in a position to need these changes? [Not rejecting, just reflecting...] ------------------------------------------------------- Date: 2000-Aug-21 16:52 By: tmick Comment: Well IMO: - The thread_pthread.h fix (and SIZEOF_PTHREAD_T) is an actual fix not a hack (there was some agreement between Fredrik, Tim and I on it) - The CC, CCSHARED, LINKCC, and LDSHARED are as per the (limited) Monterey compiler doc. I have no reason to believe that these will change post-Monterey-beta. - The only things that could be considered hacks are the RANLIB=: and OPT= settings. My p.o.v. is that by the time Monterey comes out of beta I may not be working on this and I would rather the information for compiling Python on Monterey successfully be out in the community rather than privately held (and forgotten) on my hard drive. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101249&group_id=5470 From noreply@sourceforge.net Mon Aug 21 21:48:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 13:48:04 -0700 Subject: [Patches] [Patch #100880] urllib.py patch Message-ID: <200008212048.NAA10348@bush.i.sourceforge.net> Patch #100880 has been updated. Project: Category: library Status: Accepted Summary: urllib.py patch Follow-Ups: Date: 2000-Jul-13 15:20 By: akuchling Comment: Patch from Paul Schreiber : Patch description ----------------- This addresses four issues: (1) usernames and passwords in urls with special characters are now decoded properly. i.e. http://foo%2C:bar@www.whatever.com/ (2) Basic Auth support has been added to HTTPS, like it was in HTTP. (3) Version 1.92 sent the POSTed data, but did not deal with errors (HTTP responses other than 200) properly. HTTPS now behaves the same way HTTP does. (4) made URL-checking beahve the same way with HTTPS as it does with HTTP (changed == to !=). ------------------------------------------------------- Date: 2000-Aug-15 13:37 By: tim_one Comment: Reassigned to Fred because Jeremy's gone and it's another urllib thingie that's been sitting here over a month. Please review or pass it on. ------------------------------------------------------- Date: 2000-Aug-21 16:48 By: fdrake Comment: This looks good -- go ahead and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100880&group_id=5470 From noreply@sourceforge.net Mon Aug 21 22:43:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 14:43:24 -0700 Subject: [Patches] [Patch #100880] urllib.py patch Message-ID: <200008212143.OAA12459@bush.i.sourceforge.net> Patch #100880 has been updated. Project: Category: library Status: Closed Summary: urllib.py patch Follow-Ups: Date: 2000-Jul-13 15:20 By: akuchling Comment: Patch from Paul Schreiber : Patch description ----------------- This addresses four issues: (1) usernames and passwords in urls with special characters are now decoded properly. i.e. http://foo%2C:bar@www.whatever.com/ (2) Basic Auth support has been added to HTTPS, like it was in HTTP. (3) Version 1.92 sent the POSTed data, but did not deal with errors (HTTP responses other than 200) properly. HTTPS now behaves the same way HTTP does. (4) made URL-checking beahve the same way with HTTPS as it does with HTTP (changed == to !=). ------------------------------------------------------- Date: 2000-Aug-15 13:37 By: tim_one Comment: Reassigned to Fred because Jeremy's gone and it's another urllib thingie that's been sitting here over a month. Please review or pass it on. ------------------------------------------------------- Date: 2000-Aug-21 16:48 By: fdrake Comment: This looks good -- go ahead and check it in. ------------------------------------------------------- Date: 2000-Aug-21 17:43 By: fdrake Comment: Checked in, since Andrew only reported the patch rather than created it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100880&group_id=5470 From noreply@sourceforge.net Mon Aug 21 22:47:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 14:47:47 -0700 Subject: [Patches] [Patch #101246] Let UserString.translate() method work with unicode data Message-ID: <200008212147.OAA12638@bush.i.sourceforge.net> Patch #101246 has been updated. Project: Category: Modules Status: Closed Summary: Let UserString.translate() method work with unicode data Follow-Ups: Date: 2000-Aug-21 11:08 By: gvanrossum Comment: So simple it should go in. ------------------------------------------------------- Date: 2000-Aug-21 17:47 By: fdrake Comment: Checked in as-is. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101246&group_id=5470 From noreply@sourceforge.net Tue Aug 22 00:57:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 16:57:40 -0700 Subject: [Patches] [Patch #101249] port to Monterey (64-bit AIX) and pthread fix Message-ID: <200008212357.QAA17195@bush.i.sourceforge.net> Patch #101249 has been updated. Project: Category: Build Status: Open Summary: port to Monterey (64-bit AIX) and pthread fix Follow-Ups: Date: 2000-Aug-21 11:16 By: tmick Comment: This patch partly (some stuff went in already) ports Python to Monterey. Remember to 'autoconf' and 'autoheader'. - Fix bug in thread_pthread.h::PyThread_get_thread_ident() where sizeof(pthread) < sizeof(long). As Tim sort of suggested, note that function is inherently hosed. - Add 'configure' for: - SIZEOF_PTHREAD is pthread_t can be included via - setting Monterey system name - appropriate CC,LINKCC,LDSHARED,OPT, and CCSHARED for Monterey - Add section in README for Monterey build ------------------------------------------------------- Date: 2000-Aug-21 11:18 By: tmick Comment: Tim, could you verify my thread_pthread.h change and then pass this off to some Unix-weenie, as you say, to check the Autoconf changes. Thanks ------------------------------------------------------- Date: 2000-Aug-21 11:34 By: gvanrossum Comment: Hm. is it a good idea to check in this many changes for a compiler that's in beta test? I bet that by the time the Monterey64 compiler is out of beta half of these hacks are no longer necessary. And how many other people are in a position to need these changes? [Not rejecting, just reflecting...] ------------------------------------------------------- Date: 2000-Aug-21 12:52 By: tmick Comment: Well IMO: - The thread_pthread.h fix (and SIZEOF_PTHREAD_T) is an actual fix not a hack (there was some agreement between Fredrik, Tim and I on it) - The CC, CCSHARED, LINKCC, and LDSHARED are as per the (limited) Monterey compiler doc. I have no reason to believe that these will change post-Monterey-beta. - The only things that could be considered hacks are the RANLIB=: and OPT= settings. My p.o.v. is that by the time Monterey comes out of beta I may not be working on this and I would rather the information for compiling Python on Monterey successfully be out in the community rather than privately held (and forgotten) on my hard drive. ------------------------------------------------------- Date: 2000-Aug-21 19:57 By: tim_one Comment: Jeremy made the mistake of revealing he was back from vacation, so reassigned to him. HAHAHA! The "interim release manager" gets some revenge. Jeremy, please eyeball the config stuff and check whether it breaks Linux. Trent and Guido, I agree with Trent that the get_ident change is fine, whether or not Monterey ever gets used. And so long as Monterey changes don't propagate thru the rest of the codebase, there's no harm here either. The only downside is cluttering up the config stuff with Yet Another flavor of Unix(tm), but that has an upside too (at least if Monterey *does* ever get used! it's a head start). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101249&group_id=5470 From noreply@sourceforge.net Tue Aug 22 00:59:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 16:59:54 -0700 Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display Message-ID: <200008212359.QAA17230@bush.i.sourceforge.net> Patch #100947 has been updated. Project: Category: library Status: Open Summary: increase control and default size of pdb traceback display Follow-Ups: Date: 2000-Aug-13 23:15 By: nowonder Comment: There is a detailed description in the patch. ------------------------------------------------------- Date: 2000-Aug-15 13:55 By: tim_one Comment: Reassigned to Guido in Jeremy's absence, cuz I never use pdb but know Guido has at least once . Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 15:36 By: gvanrossum Comment: I like the idea fine, but the command name "scaletb" sucks. Once a better name is coined Ken should get checkin permissions if he doesn't already have them, so he can check it in. (Isn't it ironic that Ken, who enjoys naming debates so much, came up with a sucky name? :-) Possibly a better name could include "control" (or an abbreviation) instead of "scale"? ------------------------------------------------------- Date: 2000-Aug-21 19:59 By: tim_one Comment: Ken, are you going to repsond to Guido's comments? And do you want developer privileges? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470 From noreply@sourceforge.net Tue Aug 22 01:03:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 17:03:55 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008220003.RAA17381@bush.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Open Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 15:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- Date: 2000-Aug-21 20:03 By: tim_one Comment: Skip, did you and/or Ping track down the problem you thought there might be with this? Or am I misremembering email? (Ironic note: we moved to the SF patch manager so discussions wouldn't get lost!) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Tue Aug 22 01:11:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 17:11:41 -0700 Subject: [Patches] [Patch #101238] PyOS_CheckStack for Windows (MSVC) Message-ID: <200008220011.RAA07046@delerium.i.sourceforge.net> Patch #101238 has been updated. Project: Category: core (C code) Status: Open Summary: PyOS_CheckStack for Windows (MSVC) Follow-Ups: Date: 2000-Aug-21 20:11 By: tim_one Comment: Assigned to Guido because there's a policy issue. This implements Jack's PyOS_CheckStack for the combo of Windows and MSVC. The question is whether you think there's a general approach waiting to be had here (I don't, except for adopting Stackless), or whether platform-specific tricks are the best we can do. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101238&group_id=5470 From noreply@sourceforge.net Tue Aug 22 01:18:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 17:18:41 -0700 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' Message-ID: <200008220018.RAA07360@delerium.i.sourceforge.net> Patch #101243 has been updated. Project: Category: core (C code) Status: Open Summary: Use a compile time mechanism to 'find "import-from" args' Follow-Ups: Date: 2000-Aug-20 16:57 By: twouters Comment: This patch changes the mechanism used to find the 'import-arguments' as passed to __import__ (and used by 'ni' and such dynamic import mechanisms.) The current mechanism looks into the 'future' bytecode stream (from the IMPORT_NAME statement onward) looking for IMPORT_FROM statements. The problem is that this limits the extend in which we can change IMPORT_FROM, and that this is a runtime check for information which was available at compile-time. Instead, we create a list of import-from arguments, and push it on the stack. The list creation is still done at runtime (it has to be, I think ?) but it's a simple push-constants-on-the-stack-and-BUILD_LIST operation. The result is that all 'import arguments' (the names imported-from another module) are present not only as normal 'names' in the co_names list, but also as PyString objects in the co_consts list. And that pystone runs a few promille faster on my machine. And that more trickery is allowed in imports, such as those that patch #101234 allows. ------------------------------------------------------- Date: 2000-Aug-21 20:18 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 From noreply@sourceforge.net Tue Aug 22 01:21:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 17:21:49 -0700 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' Message-ID: <200008220021.RAA07411@delerium.i.sourceforge.net> Patch #101243 has been updated. Project: Category: core (C code) Status: Open Summary: Use a compile time mechanism to 'find "import-from" args' Follow-Ups: Date: 2000-Aug-20 16:57 By: twouters Comment: This patch changes the mechanism used to find the 'import-arguments' as passed to __import__ (and used by 'ni' and such dynamic import mechanisms.) The current mechanism looks into the 'future' bytecode stream (from the IMPORT_NAME statement onward) looking for IMPORT_FROM statements. The problem is that this limits the extend in which we can change IMPORT_FROM, and that this is a runtime check for information which was available at compile-time. Instead, we create a list of import-from arguments, and push it on the stack. The list creation is still done at runtime (it has to be, I think ?) but it's a simple push-constants-on-the-stack-and-BUILD_LIST operation. The result is that all 'import arguments' (the names imported-from another module) are present not only as normal 'names' in the co_names list, but also as PyString objects in the co_consts list. And that pystone runs a few promille faster on my machine. And that more trickery is allowed in imports, such as those that patch #101234 allows. ------------------------------------------------------- Date: 2000-Aug-21 20:18 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-21 20:21 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 From noreply@sourceforge.net Tue Aug 22 01:27:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 17:27:48 -0700 Subject: [Patches] [Patch #101250] Use '*args' instead of providing defaults in User*.py Message-ID: <200008220027.RAA07566@delerium.i.sourceforge.net> Patch #101250 has been updated. Project: Category: library Status: Postponed Summary: Use '*args' instead of providing defaults in User*.py Follow-Ups: Date: 2000-Aug-21 12:30 By: twouters Comment: Use the '*args' construct rather than providing function defaults that are passed on to the underlying datatype, in the UserList, UserDict and UserString modules. Note: UserString.encode() might like a **kwargs argument as well, I don't know how it's used. ------------------------------------------------------- Date: 2000-Aug-21 20:27 By: tim_one Comment: Postponed, unless you can justify why this should be considered a bugfix instead of a new feature. I confess I don't see the point even as a feature: the list etc interfaces are well-defined, and aren't *meant* to support arbitrary collections of signatures. Passing on arbitrary *args *will* have the effect of making tracebacks more confusing when things finally get down to the level where the concrete implementation finally gets a chance to complain about a goofy arglist. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101250&group_id=5470 From noreply@sourceforge.net Tue Aug 22 01:46:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 17:46:13 -0700 Subject: [Patches] [Patch #101233] PyModule_AddObject() and friends Message-ID: <200008220046.RAA18725@bush.i.sourceforge.net> Patch #101233 has been updated. Project: Category: core (C code) Status: Postponed Summary: PyModule_AddObject() and friends Follow-Ups: Date: 2000-Aug-19 17:17 By: marangoz Comment: Looks good. BDFL need to Pronounce on API issues. What amount of changes would this imply in the distrib? Have patch? (the names could be tuned later directly in the patch ) ------------------------------------------------------- Date: 2000-Aug-20 04:31 By: tim_one Comment: Assigned to Guido because, as Vlad says, he needs to Prounounce on the idea. Guido, the point here is to provide a single implementation to replace all the repeated and inconsistent functions and macros that modules are defining today for use in their init functions. Was discussed on Python-Dev and was well-received there. Andrew, I dislike the name PyModule_AddConstantLong, because that Python ints *happen* to be C longs should be an implementation detail. Since the function is actually adding a Python int, I'm afraid I like PyModule_AddConstantInt better. Oh, yuck. Ah! PyModule_AddConstantPyInt. ------------------------------------------------------- Date: 2000-Aug-22 00:46 By: gvanrossum Comment: I like the idea fine, but don't think it's important enough to rush it into 2.0. Anyway it needs docs for api.tex. AddConstantPyInt is a bad name becase "PyInt" suggests that the argument is a Python int object, not a C int. Suggestion: PyModule_AddIntConstant and PyModule_AddStringConstant. I'm a bit worried by the implied DECREF in PyModule_AddObject -- this should better go into the other two, or the name should be changed, maybe to _AddNewObject. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101233&group_id=5470 From noreply@sourceforge.net Tue Aug 22 01:47:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 17:47:49 -0700 Subject: [Patches] [Patch #101234] Allow all assignment expressions after 'import something as' Message-ID: <200008220047.RAA18743@bush.i.sourceforge.net> Patch #101234 has been updated. Project: Category: core (C code) Status: Rejected Summary: Allow all assignment expressions after 'import something as' Follow-Ups: Date: 2000-Aug-19 21:29 By: twouters Comment: This absurdly simple patch (4 lines changed in 2 files) turns 'import-as' and 'from-import-as' into true assignment expressions: the name given after 'as' can be any expression that is a valid l-value: >>> from sys import version_info as (maj,min,pl,relnam,relno) >>> maj,min,pl,relnam,relno (2, 0, 0, 'beta', 1) >>> x = {} >>> import sys as x['sys'] >>> import os as x['os'] >>> x {'os': , 'sys': } >>> class X: pass ... >>> x = X() >>> import sys as x.sys >>> import os as x.os >>> import posixpath as x.posixpath >>> x.sys, x.os, x.posixpath (, , ) This looks so natural, I would almost treat this as a bugfix instead of a new feature ;) ------------------------------------------------------- Date: 2000-Aug-20 20:02 By: nowonder Comment: Looks fine. Works as I expect. Doesn't break old code. I hope Guido likes it (assigned to gvanrossum). Talk about beautiful! I *love* this patch -- feels so natural. It was just what I wanted to do. ------------------------------------------------------- Date: 2000-Aug-22 00:47 By: gvanrossum Comment: I don't like it. I think it's not needed. Let's try it with the simple name first. PS you still need to provide a separate patch (that you can check in directly) to support "import a.b.c as foo" which assigns a.b.c to foo. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470 From noreply@sourceforge.net Tue Aug 22 01:53:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 17:53:50 -0700 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' Message-ID: <200008220053.RAA18889@bush.i.sourceforge.net> Patch #101243 has been updated. Project: Category: core (C code) Status: Open Summary: Use a compile time mechanism to 'find "import-from" args' Follow-Ups: Date: 2000-Aug-20 20:57 By: twouters Comment: This patch changes the mechanism used to find the 'import-arguments' as passed to __import__ (and used by 'ni' and such dynamic import mechanisms.) The current mechanism looks into the 'future' bytecode stream (from the IMPORT_NAME statement onward) looking for IMPORT_FROM statements. The problem is that this limits the extend in which we can change IMPORT_FROM, and that this is a runtime check for information which was available at compile-time. Instead, we create a list of import-from arguments, and push it on the stack. The list creation is still done at runtime (it has to be, I think ?) but it's a simple push-constants-on-the-stack-and-BUILD_LIST operation. The result is that all 'import arguments' (the names imported-from another module) are present not only as normal 'names' in the co_names list, but also as PyString objects in the co_consts list. And that pystone runs a few promille faster on my machine. And that more trickery is allowed in imports, such as those that patch #101234 allows. ------------------------------------------------------- Date: 2000-Aug-22 00:18 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-22 00:21 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-22 00:53 By: gvanrossum Comment: Cool, but needs some work before you can check it in. Notes: - Yes, a tuple constant would be fine. (Note: co_names and co_consts are really redundant; all that's needed is co_consts.) - In ceval.c, why not place "u = POP()" *after* the test for x==NULL? Then you don't need to DECREF it when x==NULL. - You left the fprintf in com_pop() uncommented! - Barry just bumped the MAGIC number. There's no need to do this twice a week if no release occurred. :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:14:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:14:51 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008220114.SAA09086@delerium.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Open Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 15:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- Date: 2000-Aug-21 20:03 By: tim_one Comment: Skip, did you and/or Ping track down the problem you thought there might be with this? Or am I misremembering email? (Ironic note: we moved to the SF patch manager so discussions wouldn't get lost!) ------------------------------------------------------- Date: 2000-Aug-21 21:14 By: montanaro Comment: Yes, Ping found and fixed the problem. The patch that I submitted should do the right thing. I'm reassigning it to Guido for his pronouncement. I believe it's ready to go. (I am still pretty unclear on the sequence of events that are required to take a patch from idea to cvs checkin...) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:16:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:16:08 -0700 Subject: [Patches] [Patch #101238] PyOS_CheckStack for Windows (MSVC) Message-ID: <200008220116.SAA09111@delerium.i.sourceforge.net> Patch #101238 has been updated. Project: Category: core (C code) Status: Open Summary: PyOS_CheckStack for Windows (MSVC) Follow-Ups: Date: 2000-Aug-22 00:11 By: tim_one Comment: Assigned to Guido because there's a policy issue. This implements Jack's PyOS_CheckStack for the combo of Windows and MSVC. The question is whether you think there's a general approach waiting to be had here (I don't, except for adopting Stackless), or whether platform-specific tricks are the best we can do. ------------------------------------------------------- Date: 2000-Aug-22 01:16 By: gvanrossum Comment: The semantics of the stack are completely implementation dependent so I wouldn't know how to do this platform-independent. This looks fine to me -- but when I test it (VC 6 on Win98), it doesn't work. Try this: class C: def __getattr__(self, a): return self.x C() This still aborts the program. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101238&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:24:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:24:21 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008220124.SAA19807@bush.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Accepted Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 19:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- Date: 2000-Aug-22 00:03 By: tim_one Comment: Skip, did you and/or Ping track down the problem you thought there might be with this? Or am I misremembering email? (Ironic note: we moved to the SF patch manager so discussions wouldn't get lost!) ------------------------------------------------------- Date: 2000-Aug-22 01:14 By: montanaro Comment: Yes, Ping found and fixed the problem. The patch that I submitted should do the right thing. I'm reassigning it to Guido for his pronouncement. I believe it's ready to go. (I am still pretty unclear on the sequence of events that are required to take a patch from idea to cvs checkin...) ------------------------------------------------------- Date: 2000-Aug-22 01:24 By: gvanrossum Comment: Thanks! To both of you. Also for the doc additions. Skip, please check it in and then set the status to Closed. When you submit a patch (or update one), it's best to leave it unassigned or assign it to the release manager (today still Tim, after tomorrow Jeremy). If it *needs* BDFL pronouncement, the release manager will assign it to me with appropriate comments. Note: the patch part for graminit.c failed -- you may want to run pgen again before you check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:29:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:29:35 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008220129.SAA09579@delerium.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Open Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 15:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- Date: 2000-Aug-21 20:03 By: tim_one Comment: Skip, did you and/or Ping track down the problem you thought there might be with this? Or am I misremembering email? (Ironic note: we moved to the SF patch manager so discussions wouldn't get lost!) ------------------------------------------------------- Date: 2000-Aug-21 21:14 By: montanaro Comment: Yes, Ping found and fixed the problem. The patch that I submitted should do the right thing. I'm reassigning it to Guido for his pronouncement. I believe it's ready to go. (I am still pretty unclear on the sequence of events that are required to take a patch from idea to cvs checkin...) ------------------------------------------------------- Date: 2000-Aug-21 21:24 By: gvanrossum Comment: Thanks! To both of you. Also for the doc additions. Skip, please check it in and then set the status to Closed. When you submit a patch (or update one), it's best to leave it unassigned or assign it to the release manager (today still Tim, after tomorrow Jeremy). If it *needs* BDFL pronouncement, the release manager will assign it to me with appropriate comments. Note: the patch part for graminit.c failed -- you may want to run pgen again before you check it in. ------------------------------------------------------- Date: 2000-Aug-21 21:29 By: tim_one Comment: Thanks, Skip! Have you read http://python.sourceforge.net/sf-faq.html#a1 ? If there's something about the patch process that wasn't answered there, let me know. I must say that, from my POV as "interim release manager" the past couple weeks, few people are playing along with the intent -- it's like nothing *moves* unless I step in to kick, prod or harass. You assigning this to the person *you* believe should take the next step is exactly how it's supposed to work. Thanks for taking the initiative! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:39:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:39:55 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008220139.SAA09966@delerium.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Accepted Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 15:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- Date: 2000-Aug-21 20:03 By: tim_one Comment: Skip, did you and/or Ping track down the problem you thought there might be with this? Or am I misremembering email? (Ironic note: we moved to the SF patch manager so discussions wouldn't get lost!) ------------------------------------------------------- Date: 2000-Aug-21 21:14 By: montanaro Comment: Yes, Ping found and fixed the problem. The patch that I submitted should do the right thing. I'm reassigning it to Guido for his pronouncement. I believe it's ready to go. (I am still pretty unclear on the sequence of events that are required to take a patch from idea to cvs checkin...) ------------------------------------------------------- Date: 2000-Aug-21 21:24 By: gvanrossum Comment: Thanks! To both of you. Also for the doc additions. Skip, please check it in and then set the status to Closed. When you submit a patch (or update one), it's best to leave it unassigned or assign it to the release manager (today still Tim, after tomorrow Jeremy). If it *needs* BDFL pronouncement, the release manager will assign it to me with appropriate comments. Note: the patch part for graminit.c failed -- you may want to run pgen again before you check it in. ------------------------------------------------------- Date: 2000-Aug-21 21:29 By: tim_one Comment: Thanks, Skip! Have you read http://python.sourceforge.net/sf-faq.html#a1 ? If there's something about the patch process that wasn't answered there, let me know. I must say that, from my POV as "interim release manager" the past couple weeks, few people are playing along with the intent -- it's like nothing *moves* unless I step in to kick, prod or harass. You assigning this to the person *you* believe should take the next step is exactly how it's supposed to work. Thanks for taking the initiative! ------------------------------------------------------- Date: 2000-Aug-21 21:37 By: tim_one Comment: Assigned back to Skip since Guido Pronounced. Please feel free to check it in and Close it after addressing his comments. ------------------------------------------------------- Date: 2000-Aug-21 21:39 By: tim_one Comment: AHA! A SourceForge insecurity: I'm deducing from the log that Guido changed the status to Accepted when he wrote his last comment, but I was writing a comment at the same time but without changing the status, and a submitted after he did. So ended up undoing his status change without knowing it! Changed Status back to Accepted. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:37:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:37:03 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008220137.SAA09830@delerium.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Open Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 15:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- Date: 2000-Aug-21 20:03 By: tim_one Comment: Skip, did you and/or Ping track down the problem you thought there might be with this? Or am I misremembering email? (Ironic note: we moved to the SF patch manager so discussions wouldn't get lost!) ------------------------------------------------------- Date: 2000-Aug-21 21:14 By: montanaro Comment: Yes, Ping found and fixed the problem. The patch that I submitted should do the right thing. I'm reassigning it to Guido for his pronouncement. I believe it's ready to go. (I am still pretty unclear on the sequence of events that are required to take a patch from idea to cvs checkin...) ------------------------------------------------------- Date: 2000-Aug-21 21:24 By: gvanrossum Comment: Thanks! To both of you. Also for the doc additions. Skip, please check it in and then set the status to Closed. When you submit a patch (or update one), it's best to leave it unassigned or assign it to the release manager (today still Tim, after tomorrow Jeremy). If it *needs* BDFL pronouncement, the release manager will assign it to me with appropriate comments. Note: the patch part for graminit.c failed -- you may want to run pgen again before you check it in. ------------------------------------------------------- Date: 2000-Aug-21 21:29 By: tim_one Comment: Thanks, Skip! Have you read http://python.sourceforge.net/sf-faq.html#a1 ? If there's something about the patch process that wasn't answered there, let me know. I must say that, from my POV as "interim release manager" the past couple weeks, few people are playing along with the intent -- it's like nothing *moves* unless I step in to kick, prod or harass. You assigning this to the person *you* believe should take the next step is exactly how it's supposed to work. Thanks for taking the initiative! ------------------------------------------------------- Date: 2000-Aug-21 21:37 By: tim_one Comment: Assigned back to Skip since Guido Pronounced. Please feel free to check it in and Close it after addressing his comments. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:42:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:42:15 -0700 Subject: [Patches] [Patch #100895] safe version of PyErr_Format Message-ID: <200008220142.SAA09991@delerium.i.sourceforge.net> Patch #100895 has been updated. Project: Category: core (C code) Status: Open Summary: safe version of PyErr_Format Follow-Ups: Date: 2000-Jul-17 17:56 By: effbot Comment: minor tweaks (mostly comments), based on input from moshe. ------------------------------------------------------- Date: 2000-Jul-18 02:23 By: moshez Comment: I'm +1 on that! It will plug one more security hole in Python, and seems a "good enough" replacement for an unsure snprintf() ------------------------------------------------------- Date: 2000-Aug-08 13:19 By: effbot Comment: regenerated, since moshez reported that it didn't apply cleanly to the current CVS tree. reassigned, since it's been sitting here for ages. ------------------------------------------------------- Date: 2000-Aug-11 00:04 By: tim_one Comment: Rejected and back to /F. Major: no docs! Format strings processed by this have different semantics than anyone could guess (e.g., flags are ignored, width is ignored, some format codes are copied verbatim). Reverse-engineering the code each time there's a question is just too painful. You're basically inventing a new sublanguage here, so document what the heck it is & means. Mechanical: There's a "step 1" but no "step 2" . We shouldn't be #ifdef'ing on prototypes anymore. Guido did not yield to the push for 4-space indents in C code, so this should use hard tabs. ------------------------------------------------------- Date: 2000-Aug-15 20:05 By: tim_one Comment: Changed status from Rejeced to Open so we only have to look in one place for the status of putative 2.0 patches. But the patch is still *effectively* rejected pending response to the objections. ------------------------------------------------------- Date: 2000-Aug-21 21:42 By: tim_one Comment: Just reminding you this is still on your plate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:45:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:45:35 -0700 Subject: [Patches] [Patch #100851] traceback.py, with unicode exceptions Message-ID: <200008220145.SAA10137@delerium.i.sourceforge.net> Patch #100851 has been updated. Project: Category: None Status: Accepted Summary: traceback.py, with unicode exceptions Follow-Ups: Date: 2000-Jul-11 06:58 By: htrd Comment: traceback.py can format an exception as a string - but what happens when an exception is raised during the string conversion? In this case it is better to discard the inner exception, to allow the original exception to be reported. The migration to unicode strings makes this quite common. Old code might report a failue with something like.... raise IWasntExpectingThisError('nobody expects %s' % x) An alternative fix is to change __str__ for exceptions to handle the exception. This would be neater, but I chose to follow the example set by PyErr_PrintEx which has a comment: /* If an error happened here, don't show it. XXX This is wrong, but too many callers rely on this behavior. */ ------------------------------------------------------- Date: 2000-Jul-27 16:25 By: gvanrossum Comment: Actually I like this, but instead of the id() of the value you should show its type, e.g. "" % type(value). ------------------------------------------------------- Date: 2000-Aug-01 12:18 By: htrd Comment: Updated patch now formats tracebacks using type(value).__name__ Traceback (most recent call last): File "", line 1, in ? ValueError: ------------------------------------------------------- Date: 2000-Aug-15 14:09 By: tim_one Comment: Guido, if you accepted this and left it assigned to you, check it in! ------------------------------------------------------- Date: 2000-Aug-21 21:45 By: tim_one Comment: Guido, this is not an accidentally repeated comment : if you accepted this and left it assigned to you, check it in! Else assign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100851&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:46:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:46:44 -0700 Subject: [Patches] [Patch #100970] extended print statement Message-ID: <200008220146.SAA10157@delerium.i.sourceforge.net> Patch #100970 has been updated. Project: Category: core (C code) Status: Accepted Summary: extended print statement Follow-Ups: Date: 2000-Jul-23 22:44 By: bwarsaw Comment: This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout). This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement. An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM. I'm not sure which approach is better. ------------------------------------------------------- Date: 2000-Jul-23 22:45 By: bwarsaw Comment: The following is an example of how you might use the new extended print statement. 
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
------------------------------------------------------- Date: 2000-Aug-15 14:00 By: tim_one Comment: Assigned to Guido for Pronouncement. This was already discussed on Python-Dev. Mix of opinions there. I like it fine. Barry, this needs docs and test cases Real Soon if you want it considered for 2.0. I like the PRINT_TO idea better. ------------------------------------------------------- Date: 2000-Aug-15 18:43 By: bwarsaw Comment: Revised patch which uses the PRINT_ITEM_TO approach favored by Tim. This patch also includes doc and test suite updates. Please see PEP 214 for a discussion of the issues. This feature should be postponed until Python 2.1 ------------------------------------------------------- Date: 2000-Aug-15 19:05 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-15 19:16 By: bwarsaw Comment: Okay, I just thought that with the open issue (see PEP 214) it might not be ready for prime time. Let's wait for the BDFL pronounce before postponing. ------------------------------------------------------- Date: 2000-Aug-15 19:33 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-16 10:56 By: bwarsaw Comment: After channeling and encouragement from Tim, this patch represents the current definition of the feature as described in PEP 214. It is now ready for BDFL pronouncement for Python 2.0. ------------------------------------------------------- Date: 2000-Aug-17 15:31 By: gvanrossum Comment: I'm still not convinced. Let's save this for reopening in 2.1. I'm worried about language bloat... Assigned to Tim just so that he can reopen the debate when he sees fit. ------------------------------------------------------- Date: 2000-Aug-19 21:46 By: tim_one Comment: Changed status from Postponed to Accepted and assigned back to Barry for checkin. Ruling from Guido follows: I'm still reading my email off-line on the plane. I've now read PEP 214 and think I'll reverse my opinion: it's okay. Barry, check it in! (And change the SF PM status to 'Accepted'.) I think I'll start using it for error messages: errors should go to stderr, but it's often inconvenient, so in minor scripts instead of doing sys.stderr.write("Error: can't open %s\n" % filename) I often write print "Error: can't open", filename which is incorrect but more convenient. I can now start using print >>sys.stderr, "Error: can't open", filename --Guido ------------------------------------------------------- Date: 2000-Aug-21 21:46 By: tim_one Comment: Barry, if you checked this in, please change the Status to Closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:47:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:47:46 -0700 Subject: [Patches] [Patch #100874] Better error message with UnboundLocalError Message-ID: <200008220147.SAA10182@delerium.i.sourceforge.net> Patch #100874 has been updated. Project: Category: None Status: Accepted Summary: Better error message with UnboundLocalError Follow-Ups: Date: 2000-Jul-13 00:56 By: tim_one Comment: Rejected and assigned back to Paul. I like the idea fine, the rejection is for style reasons and a repeated security hole. Please make the code look like the rest of ceval.c -- idiosyncracies (that aren't Guido's <0.3 wink>) are harmful in group-maintained code. Examples: > PyObject *nm=NULL; Should be a space on each side of "=". Ditto throughout the patch. BTW, is "nm" meant to be an abbreviation for "name"? If so, please spell out the two extra letters. If it's meant to be an abbreviation for New Mexico, capitalize it . > if(!nm) break; "if" isn't a function call: use a space between "if" and "(". It's also bad to slop "break" on the same line: makes it much harder to set a useful breakpoint here in a debugger. Everywhere else in the code this line would be spelled (if Guido wrote it -- and the "\t" business here is because SF comments don't preserve indentation): \tif (!nm) \t\tbreak > sprintf( buf, "Local variable %s No space between "(" and "buf" here. > PyExc_UnboundLocalError, buf ); No space between "buf" and ")" here. > char buf[500]; > ... followed by an unchecked sprintf into buf. This is a security hole: Python doesn't restrict identifiers to being no longer than 500 chars, so a hacker can easily trick this code into overwriting the buffer bounds. Easy but tedious to fix (e.g., #define the buf length, and use runtime code in conjunction with strncpy to guarantee buf's bounds are respected). ------------------------------------------------------- Date: 2000-Jul-14 17:17 By: prescod Comment: Small helper function format_exc_check_arg makes it easy to generate one string and a argument-type exceptions. It may be overkill in terms of null checking...reviewer can decide. Otherwise, error messages are added to NameErrors and UnboundLocalErrors. That means that all exceptions thrown in ceval have associated error messages. ------------------------------------------------------- Date: 2000-Jul-18 09:32 By: twouters Comment: The helper function is declared 'static', but not defined as such. Rest of the style issues seem solved ;) ------------------------------------------------------- Date: 2000-Jul-26 02:56 By: tim_one Comment: Accepted and assigned back to Paul. Paul, the new format_exc_check_arg function is defined K&R-style, but we've moved to ANSI almost everywhere else in the source. Would be nice if you fix that before checking this in. Else I'll look for it and fix it myself. Sorry for the delay in getting back to this! ------------------------------------------------------- Date: 2000-Aug-15 14:10 By: tim_one Comment: Paul, this was accepted weeks ago. Are you going to check it in? ------------------------------------------------------- Date: 2000-Aug-19 21:47 By: tim_one Comment: Yo! Paul! Check it in already! ------------------------------------------------------- Date: 2000-Aug-21 21:47 By: tim_one Comment: Knock, knock! Anybody home? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100874&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:49:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:49:36 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008220149.SAA10306@delerium.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Accepted Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 08:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 21:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 05:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 19:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 10:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-28 01:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 17:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- Date: 2000-Aug-09 01:26 By: tim_one Comment: Changed status to Rejected, but left assigned to me (I'll Open it again when it's updated). As I said at the bottom of my last comment on this, you cannot assume sizeof(short)==2: please get rid of the new big-endian/little-endian trickery. The code is not portable as-is. Even on machines where sizeof(short) does equal 2, shorts in the opcode stream are not guaranteed to be naturally aligned, and trying to access them as if they were can lead to anything from a core dump to an expensive trap to the OS to fix up the unaligned read. And on the only machines where this gimmick could actually pay (a little-endian machine where sizeof(short)==2 *and* the HW doesn't penalize unnatural alignment), the compiler should be smart enough to optimize the old expression for us. ------------------------------------------------------- Date: 2000-Aug-09 07:36 By: gvanrossum Comment: I think that all Tim wants is that you undo the changes you made to the NEXTARG() macro. ------------------------------------------------------- Date: 2000-Aug-10 17:51 By: cgw Comment: Understood. I've now put the NEXTARG macro back to its original form; sorry for overlooking this on the previous pass. ------------------------------------------------------- Date: 2000-Aug-11 00:25 By: tim_one Comment: Changed to Open and assigned to Vladimir. Vlad, have any comments on this? Care to test it? I'm inclined to accept it now "by eyeball", because it does fix some bugs. ------------------------------------------------------- Date: 2000-Aug-12 12:54 By: marangoz Comment: Yes, comments: there are things I like and others I don't really like. The tactics here is to remove the 2-byte integral type limit and replace it with sizeof(int). On some systems, sizeof(int) == 8, so I don't see a reason for generating only one EXTENDED_ARG opcode if the arg exceeds 2 bytes. If the arg exceeds 4 bytes, let the code generate more 2-byte arg slices, i.e. several EXTENDED_ARG in a row. Costs nothing. Overall, we both converged on the same solution. Things I like: - the fix in node.h (short -> int) - the error check in com_backpatch Things I don't really like: - the removal of E_OVERFLOW and associated checks I'd suggest using int types in node.h (instead of unsigned int) and change the existing short checks with int checks (with INT_MAX) - the label "extended_arg" in ceval.c. (after the oparg fetch) It should be really be named "dispatch_opcode". I'd suggest integrating the com_oparg & ceval's case EXTENDED_ARG code that I've posted to python-dev and adjust the rest accordingly. http://www.python.org/pipermail/python-dev/2000-August/014604.html Overall, it looks okay. I'll test it when the things I don't really like are gone. (the Python code seems to be somewhat more complex than it should be, though...) Can we get another patch from the author? Otherwise I'll try to make some time to relay this. ------------------------------------------------------- Date: 2000-Aug-15 13:29 By: tim_one Comment: Charles, do you have anything to say to Vladimir's comments? I don't see a need to have an indefinitely-extensible extended opcode gimmick today. What you already did solves real problems now, and indeed the only real problems in this area we've ever seen. I want to get that into 2.0. That doesn't preclude Vlad extending it again later. But I agree that removing the overflow checks was a bad decision. If we ever *do* bump into a case where more than what you've done is needed, Python will silently go insane. So if you can fix that much, I'll accept the patch for 2.0 immediately after. Agree too that "dispatch_opcode" is a clearer name for the label than "extended_arg". ------------------------------------------------------- Date: 2000-Aug-15 16:45 By: cgw Comment: You know, I've been fooling around with this silly little patch for quite a while. And about 3 months ago I had developed a version where you could stack up the EXTENDED_ARG opcodes, and also where I had dealt with the "offset too big" problem in com_backpatch by inserting some EXTENDED_ARGS and then relocating the subsequent code, by walking through and fixing up offsets. It worked, but it was rather hairy and slow and I convinced myself that such a patch would simply *never*get accepted. So I simplified it down as much as possible to solve the actual problem that we were having here at FNAL. I didn't really decide to take out the overflow checks, it's just that my patch pre-dated their addition. I'm uploading a new version which restores the overflow checks and renames the label as per your wishes. ------------------------------------------------------- Date: 2000-Aug-15 22:49 By: tim_one Comment: Accepted and assigned to Fred Drake for checkin. Sorry again, Fred! I'll get a patch that works one of these days (the Cygwin stuff works fine, but I can't afford the download time!). And, Charles, thank you for patience and good humor during this long ordeal. It's appreciated! ------------------------------------------------------- Date: 2000-Aug-21 21:49 By: tim_one Comment: Yo! Fred! Please check this in or assign to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:51:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:51:14 -0700 Subject: [Patches] [Patch #100955] ptags, eptags: regex->re, 4 char indent. Message-ID: <200008220151.SAA10352@delerium.i.sourceforge.net> Patch #100955 has been updated. Project: Category: None Status: Accepted Summary: ptags, eptags: regex->re, 4 char indent. Follow-Ups: Date: 2000-Jul-22 04:35 By: hooft Comment: This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex. ------------------------------------------------------- Date: 2000-Jul-23 02:44 By: moshez Comment: I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this? ------------------------------------------------------- Date: 2000-Jul-25 16:57 By: gvanrossum Comment: SRE should be faster again, right? The parser module is a very big gun for this simple app -- look at it as an example for text processing (and documentation for TAGS files :-). I say go for it. ------------------------------------------------------- Date: 2000-Jul-26 10:12 By: moshez Comment: Somehow it passed through me, so I added ptags change too. Anyway, Jeremy, Guido is for this. ------------------------------------------------------- Date: 2000-Aug-15 14:12 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-15 14:13 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-15 14:13 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-21 21:51 By: tim_one Comment: Barry, please follow up on this, or assign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:52:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:52:24 -0700 Subject: [Patches] [Patch #100994] Allow JPython to use more tests Message-ID: <200008220152.SAA10359@delerium.i.sourceforge.net> Patch #100994 has been updated. Project: Category: library Status: Accepted Summary: Allow JPython to use more tests Follow-Ups: Date: 2000-Jul-27 15:47 By: bckfnn Comment: Several test can almost but not quite be used from JPython. test_b1: JPython does no longer have a strop module. Instead the builtin "time" module is used. test_exceptions.py: In JPython the builtin exception does not have type ClassType but type TypeType. The TypeType is a subclass of ClassType which make the isinstance work for both pythons. test_pkg.py: JPython does not insert __builtins__ in the module namespace. I hope that removing __builtins__ from the output does not devaluate the test. ------------------------------------------------------- Date: 2000-Jul-27 15:52 By: gvanrossum Comment: Note that Lib/test/output/test_pkg must be changed too! Regenerate it by running "regrtest.py -g test_pkh". ------------------------------------------------------- Date: 2000-Aug-15 14:07 By: tim_one Comment: Reassigned to Barry in Jeremy's absence. Barry, note that Guido already Accepted this. If you do too, check it in. ------------------------------------------------------- Date: 2000-Aug-21 21:52 By: tim_one Comment: Barry, this is still on your plate. Eat it or give it to a starving child. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100994&group_id=5470 From noreply@sourceforge.net Tue Aug 22 02:54:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 18:54:11 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008220154.SAA10475@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Accepted Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 16:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 17:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-16 02:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-16 02:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 03:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 05:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 05:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-21 21:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Tue Aug 22 03:04:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 19:04:54 -0700 Subject: [Patches] [Patch #100851] traceback.py, with unicode exceptions Message-ID: <200008220204.TAA10784@delerium.i.sourceforge.net> Patch #100851 has been updated. Project: Category: None Status: Closed Summary: traceback.py, with unicode exceptions Follow-Ups: Date: 2000-Jul-11 10:58 By: htrd Comment: traceback.py can format an exception as a string - but what happens when an exception is raised during the string conversion? In this case it is better to discard the inner exception, to allow the original exception to be reported. The migration to unicode strings makes this quite common. Old code might report a failue with something like.... raise IWasntExpectingThisError('nobody expects %s' % x) An alternative fix is to change __str__ for exceptions to handle the exception. This would be neater, but I chose to follow the example set by PyErr_PrintEx which has a comment: /* If an error happened here, don't show it. XXX This is wrong, but too many callers rely on this behavior. */ ------------------------------------------------------- Date: 2000-Jul-27 20:25 By: gvanrossum Comment: Actually I like this, but instead of the id() of the value you should show its type, e.g. "" % type(value). ------------------------------------------------------- Date: 2000-Aug-01 16:18 By: htrd Comment: Updated patch now formats tracebacks using type(value).__name__ Traceback (most recent call last): File "", line 1, in ? ValueError: ------------------------------------------------------- Date: 2000-Aug-15 18:09 By: tim_one Comment: Guido, if you accepted this and left it assigned to you, check it in! ------------------------------------------------------- Date: 2000-Aug-22 01:45 By: tim_one Comment: Guido, this is not an accidentally repeated comment : if you accepted this and left it assigned to you, check it in! Else assign it to someone else. ------------------------------------------------------- Date: 2000-Aug-22 02:04 By: gvanrossum Comment: Checked in now. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100851&group_id=5470 From noreply@sourceforge.net Tue Aug 22 03:35:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 19:35:28 -0700 Subject: [Patches] [Patch #101238] PyOS_CheckStack for Windows (MSVC) Message-ID: <200008220235.TAA11733@delerium.i.sourceforge.net> Patch #101238 has been updated. Project: Category: core (C code) Status: Open Summary: PyOS_CheckStack for Windows (MSVC) Follow-Ups: Date: 2000-Aug-22 00:11 By: tim_one Comment: Assigned to Guido because there's a policy issue. This implements Jack's PyOS_CheckStack for the combo of Windows and MSVC. The question is whether you think there's a general approach waiting to be had here (I don't, except for adopting Stackless), or whether platform-specific tricks are the best we can do. ------------------------------------------------------- Date: 2000-Aug-22 01:16 By: gvanrossum Comment: The semantics of the stack are completely implementation dependent so I wouldn't know how to do this platform-independent. This looks fine to me -- but when I test it (VC 6 on Win98), it doesn't work. Try this: class C: def __getattr__(self, a): return self.x C() This still aborts the program. ------------------------------------------------------- Date: 2000-Aug-22 02:35 By: gvanrossum Comment: And are you sure you tested this? As shown it breaks the build for _sre because the declaration for PyOS_CheckStack() doesn't use DL_IMPORT(). (MSVC 6.0 on Win98.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101238&group_id=5470 From noreply@sourceforge.net Tue Aug 22 03:54:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 19:54:06 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200008220254.TAA12319@delerium.i.sourceforge.net> Patch #101162 has been updated. Project: Category: Build Status: Postponed Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2000-Aug-11 16:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 16:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 16:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. ------------------------------------------------------- Date: 2000-Aug-15 18:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- Date: 2000-Aug-16 15:05 By: tmick Comment: re: delaying to 2.1: doesn't bother me much Should it now be "postponed", Tim? ------------------------------------------------------- Date: 2000-Aug-21 22:54 By: montanaro Comment: postponed until 2.1 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Tue Aug 22 03:52:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 19:52:04 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008220252.TAA12203@delerium.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Closed Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 15:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- Date: 2000-Aug-21 20:03 By: tim_one Comment: Skip, did you and/or Ping track down the problem you thought there might be with this? Or am I misremembering email? (Ironic note: we moved to the SF patch manager so discussions wouldn't get lost!) ------------------------------------------------------- Date: 2000-Aug-21 21:14 By: montanaro Comment: Yes, Ping found and fixed the problem. The patch that I submitted should do the right thing. I'm reassigning it to Guido for his pronouncement. I believe it's ready to go. (I am still pretty unclear on the sequence of events that are required to take a patch from idea to cvs checkin...) ------------------------------------------------------- Date: 2000-Aug-21 21:24 By: gvanrossum Comment: Thanks! To both of you. Also for the doc additions. Skip, please check it in and then set the status to Closed. When you submit a patch (or update one), it's best to leave it unassigned or assign it to the release manager (today still Tim, after tomorrow Jeremy). If it *needs* BDFL pronouncement, the release manager will assign it to me with appropriate comments. Note: the patch part for graminit.c failed -- you may want to run pgen again before you check it in. ------------------------------------------------------- Date: 2000-Aug-21 21:29 By: tim_one Comment: Thanks, Skip! Have you read http://python.sourceforge.net/sf-faq.html#a1 ? If there's something about the patch process that wasn't answered there, let me know. I must say that, from my POV as "interim release manager" the past couple weeks, few people are playing along with the intent -- it's like nothing *moves* unless I step in to kick, prod or harass. You assigning this to the person *you* believe should take the next step is exactly how it's supposed to work. Thanks for taking the initiative! ------------------------------------------------------- Date: 2000-Aug-21 21:37 By: tim_one Comment: Assigned back to Skip since Guido Pronounced. Please feel free to check it in and Close it after addressing his comments. ------------------------------------------------------- Date: 2000-Aug-21 21:39 By: tim_one Comment: AHA! A SourceForge insecurity: I'm deducing from the log that Guido changed the status to Accepted when he wrote his last comment, but I was writing a comment at the same time but without changing the status, and a submitted after he did. So ended up undoing his status change without knowing it! Changed Status back to Accepted. ------------------------------------------------------- Date: 2000-Aug-21 22:52 By: montanaro Comment: changes have been checked in. Lib/test/test_parser.py breaks, but I forwarded a context diff to Fred Drake, who's been working on that module. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Tue Aug 22 04:03:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 20:03:07 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008220303.UAA12526@delerium.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Open Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 15:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- Date: 2000-Aug-21 20:03 By: tim_one Comment: Skip, did you and/or Ping track down the problem you thought there might be with this? Or am I misremembering email? (Ironic note: we moved to the SF patch manager so discussions wouldn't get lost!) ------------------------------------------------------- Date: 2000-Aug-21 21:14 By: montanaro Comment: Yes, Ping found and fixed the problem. The patch that I submitted should do the right thing. I'm reassigning it to Guido for his pronouncement. I believe it's ready to go. (I am still pretty unclear on the sequence of events that are required to take a patch from idea to cvs checkin...) ------------------------------------------------------- Date: 2000-Aug-21 21:24 By: gvanrossum Comment: Thanks! To both of you. Also for the doc additions. Skip, please check it in and then set the status to Closed. When you submit a patch (or update one), it's best to leave it unassigned or assign it to the release manager (today still Tim, after tomorrow Jeremy). If it *needs* BDFL pronouncement, the release manager will assign it to me with appropriate comments. Note: the patch part for graminit.c failed -- you may want to run pgen again before you check it in. ------------------------------------------------------- Date: 2000-Aug-21 21:29 By: tim_one Comment: Thanks, Skip! Have you read http://python.sourceforge.net/sf-faq.html#a1 ? If there's something about the patch process that wasn't answered there, let me know. I must say that, from my POV as "interim release manager" the past couple weeks, few people are playing along with the intent -- it's like nothing *moves* unless I step in to kick, prod or harass. You assigning this to the person *you* believe should take the next step is exactly how it's supposed to work. Thanks for taking the initiative! ------------------------------------------------------- Date: 2000-Aug-21 21:37 By: tim_one Comment: Assigned back to Skip since Guido Pronounced. Please feel free to check it in and Close it after addressing his comments. ------------------------------------------------------- Date: 2000-Aug-21 21:39 By: tim_one Comment: AHA! A SourceForge insecurity: I'm deducing from the log that Guido changed the status to Accepted when he wrote his last comment, but I was writing a comment at the same time but without changing the status, and a submitted after he did. So ended up undoing his status change without knowing it! Changed Status back to Accepted. ------------------------------------------------------- Date: 2000-Aug-21 22:52 By: montanaro Comment: changes have been checked in. Lib/test/test_parser.py breaks, but I forwarded a context diff to Fred Drake, who's been working on that module. ------------------------------------------------------- Date: 2000-Aug-21 23:03 By: montanaro Comment: forgot to reassign to Fred for documentation checks... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Tue Aug 22 05:18:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 21:18:39 -0700 Subject: [Patches] [Patch #100970] extended print statement Message-ID: <200008220418.VAA25632@bush.i.sourceforge.net> Patch #100970 has been updated. Project: Category: core (C code) Status: Closed Summary: extended print statement Follow-Ups: Date: 2000-Jul-23 22:44 By: bwarsaw Comment: This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout). This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement. An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM. I'm not sure which approach is better. ------------------------------------------------------- Date: 2000-Jul-23 22:45 By: bwarsaw Comment: The following is an example of how you might use the new extended print statement. 
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
------------------------------------------------------- Date: 2000-Aug-15 14:00 By: tim_one Comment: Assigned to Guido for Pronouncement. This was already discussed on Python-Dev. Mix of opinions there. I like it fine. Barry, this needs docs and test cases Real Soon if you want it considered for 2.0. I like the PRINT_TO idea better. ------------------------------------------------------- Date: 2000-Aug-15 18:43 By: bwarsaw Comment: Revised patch which uses the PRINT_ITEM_TO approach favored by Tim. This patch also includes doc and test suite updates. Please see PEP 214 for a discussion of the issues. This feature should be postponed until Python 2.1 ------------------------------------------------------- Date: 2000-Aug-15 19:05 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-15 19:16 By: bwarsaw Comment: Okay, I just thought that with the open issue (see PEP 214) it might not be ready for prime time. Let's wait for the BDFL pronounce before postponing. ------------------------------------------------------- Date: 2000-Aug-15 19:33 By: tim_one Comment: I don't understand. If you wanted to Postpone it, you could have done so yourself. Why do you want to postpone it? It's already been discussed, and the patch was submitted well before the feature-freeze date. ------------------------------------------------------- Date: 2000-Aug-16 10:56 By: bwarsaw Comment: After channeling and encouragement from Tim, this patch represents the current definition of the feature as described in PEP 214. It is now ready for BDFL pronouncement for Python 2.0. ------------------------------------------------------- Date: 2000-Aug-17 15:31 By: gvanrossum Comment: I'm still not convinced. Let's save this for reopening in 2.1. I'm worried about language bloat... Assigned to Tim just so that he can reopen the debate when he sees fit. ------------------------------------------------------- Date: 2000-Aug-19 21:46 By: tim_one Comment: Changed status from Postponed to Accepted and assigned back to Barry for checkin. Ruling from Guido follows: I'm still reading my email off-line on the plane. I've now read PEP 214 and think I'll reverse my opinion: it's okay. Barry, check it in! (And change the SF PM status to 'Accepted'.) I think I'll start using it for error messages: errors should go to stderr, but it's often inconvenient, so in minor scripts instead of doing sys.stderr.write("Error: can't open %s\n" % filename) I often write print "Error: can't open", filename which is incorrect but more convenient. I can now start using print >>sys.stderr, "Error: can't open", filename --Guido ------------------------------------------------------- Date: 2000-Aug-21 21:46 By: tim_one Comment: Barry, if you checked this in, please change the Status to Closed. ------------------------------------------------------- Date: 2000-Aug-22 00:18 By: bwarsaw Comment: Patch checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470 From noreply@sourceforge.net Tue Aug 22 05:41:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 21:41:29 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008220441.VAA15805@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 20:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 21:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-16 06:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-16 06:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 07:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 09:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 09:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-22 01:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- Date: 2000-Aug-22 04:41 By: moshez Comment: Actually, it's now waiting for someone's pronouncement -- Guido had a problem with .get() and __getitem__ not being equivalent (the first does an implicit .value). Ping and I thought it best that way, but if the BDFL has strong feelings otherwise, he should pronounce. Assigned to him for final verdict. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Tue Aug 22 07:06:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 23:06:31 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008220606.XAA29086@bush.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Out of date Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 08:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 21:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 05:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 19:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 10:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-28 01:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 17:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- Date: 2000-Aug-09 01:26 By: tim_one Comment: Changed status to Rejected, but left assigned to me (I'll Open it again when it's updated). As I said at the bottom of my last comment on this, you cannot assume sizeof(short)==2: please get rid of the new big-endian/little-endian trickery. The code is not portable as-is. Even on machines where sizeof(short) does equal 2, shorts in the opcode stream are not guaranteed to be naturally aligned, and trying to access them as if they were can lead to anything from a core dump to an expensive trap to the OS to fix up the unaligned read. And on the only machines where this gimmick could actually pay (a little-endian machine where sizeof(short)==2 *and* the HW doesn't penalize unnatural alignment), the compiler should be smart enough to optimize the old expression for us. ------------------------------------------------------- Date: 2000-Aug-09 07:36 By: gvanrossum Comment: I think that all Tim wants is that you undo the changes you made to the NEXTARG() macro. ------------------------------------------------------- Date: 2000-Aug-10 17:51 By: cgw Comment: Understood. I've now put the NEXTARG macro back to its original form; sorry for overlooking this on the previous pass. ------------------------------------------------------- Date: 2000-Aug-11 00:25 By: tim_one Comment: Changed to Open and assigned to Vladimir. Vlad, have any comments on this? Care to test it? I'm inclined to accept it now "by eyeball", because it does fix some bugs. ------------------------------------------------------- Date: 2000-Aug-12 12:54 By: marangoz Comment: Yes, comments: there are things I like and others I don't really like. The tactics here is to remove the 2-byte integral type limit and replace it with sizeof(int). On some systems, sizeof(int) == 8, so I don't see a reason for generating only one EXTENDED_ARG opcode if the arg exceeds 2 bytes. If the arg exceeds 4 bytes, let the code generate more 2-byte arg slices, i.e. several EXTENDED_ARG in a row. Costs nothing. Overall, we both converged on the same solution. Things I like: - the fix in node.h (short -> int) - the error check in com_backpatch Things I don't really like: - the removal of E_OVERFLOW and associated checks I'd suggest using int types in node.h (instead of unsigned int) and change the existing short checks with int checks (with INT_MAX) - the label "extended_arg" in ceval.c. (after the oparg fetch) It should be really be named "dispatch_opcode". I'd suggest integrating the com_oparg & ceval's case EXTENDED_ARG code that I've posted to python-dev and adjust the rest accordingly. http://www.python.org/pipermail/python-dev/2000-August/014604.html Overall, it looks okay. I'll test it when the things I don't really like are gone. (the Python code seems to be somewhat more complex than it should be, though...) Can we get another patch from the author? Otherwise I'll try to make some time to relay this. ------------------------------------------------------- Date: 2000-Aug-15 13:29 By: tim_one Comment: Charles, do you have anything to say to Vladimir's comments? I don't see a need to have an indefinitely-extensible extended opcode gimmick today. What you already did solves real problems now, and indeed the only real problems in this area we've ever seen. I want to get that into 2.0. That doesn't preclude Vlad extending it again later. But I agree that removing the overflow checks was a bad decision. If we ever *do* bump into a case where more than what you've done is needed, Python will silently go insane. So if you can fix that much, I'll accept the patch for 2.0 immediately after. Agree too that "dispatch_opcode" is a clearer name for the label than "extended_arg". ------------------------------------------------------- Date: 2000-Aug-15 16:45 By: cgw Comment: You know, I've been fooling around with this silly little patch for quite a while. And about 3 months ago I had developed a version where you could stack up the EXTENDED_ARG opcodes, and also where I had dealt with the "offset too big" problem in com_backpatch by inserting some EXTENDED_ARGS and then relocating the subsequent code, by walking through and fixing up offsets. It worked, but it was rather hairy and slow and I convinced myself that such a patch would simply *never*get accepted. So I simplified it down as much as possible to solve the actual problem that we were having here at FNAL. I didn't really decide to take out the overflow checks, it's just that my patch pre-dated their addition. I'm uploading a new version which restores the overflow checks and renames the label as per your wishes. ------------------------------------------------------- Date: 2000-Aug-15 22:49 By: tim_one Comment: Accepted and assigned to Fred Drake for checkin. Sorry again, Fred! I'll get a patch that works one of these days (the Cygwin stuff works fine, but I can't afford the download time!). And, Charles, thank you for patience and good humor during this long ordeal. It's appreciated! ------------------------------------------------------- Date: 2000-Aug-21 21:49 By: tim_one Comment: Yo! Fred! Please check this in or assign to someone else. ------------------------------------------------------- Date: 2000-Aug-22 02:06 By: fdrake Comment: Accepted, but no builds cleanly -- causes pgen to core dump! Perhaps there are conflicts with some of the other changes? Here's the error: cd Grammar ; make OPT="-g -O2" VERSION="2.0" \ prefix="/usr/local" exec_prefix="/usr/local" all ../Parser/pgen ../../Grammar/Grammar make[1]: *** [graminit.h] Segmentation fault make: *** [Grammar] Error 2 Charles, please update the patch and I'll apply it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Tue Aug 22 08:09:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 00:09:37 -0700 Subject: [Patches] [Patch #101187] Patch for ftplib to support REST Message-ID: <200008220709.AAA20505@delerium.i.sourceforge.net> Patch #101187 has been updated. Project: Category: Modules Status: Open Summary: Patch for ftplib to support REST Follow-Ups: Date: 2000-Aug-15 22:34 By: tim_one Comment: Assigned to Barry for an opinion. This came in after feature freeze, but it's arguably more of a bugfix than a new feature. If you're capable of making that decision with more confidence than me, please Postpone it or assign it to a competent (not me) reviewer for 2.0. ------------------------------------------------------- Date: 2000-Aug-22 07:09 By: moshez Comment: This seems great, and I'm very +1, except for one thing: the ``self.sendcmd("REST %.0f" % rest)'' thing: wouldn't it be better to self.sendcmd("REST %d" % int(rest))? Other then that, it seems to do nothing when the rest argument is not given, so it can't hurt too much. Oh, and of course, this needs doc patches. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101187&group_id=5470 From noreply@sourceforge.net Tue Aug 22 08:11:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 00:11:31 -0700 Subject: [Patches] [Patch #100852] Add poll() to select module Message-ID: <200008220711.AAA20564@delerium.i.sourceforge.net> Patch #100852 has been updated. Project: Category: Modules Status: Open Summary: Add poll() to select module Follow-Ups: Date: 2000-Jul-11 11:25 By: akuchling Comment: Derived from Sam Rushing's pollmodule.c that forms part of Medusa. Once I get a second opinion about the patch, I'll check it in. ------------------------------------------------------- Date: 2000-Jul-21 13:33 By: akuchling Comment: Updated version of the patch, which adds poll() to the select module. .register() and .unregister() add/remove fds, and .poll() performs the system call. Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored. Open question: should there be a function or attribute to get the list of registered fds? Still to do: write documentation, add the test case. ------------------------------------------------------- Date: 2000-Jul-25 00:54 By: akuchling Comment: Assigned to Jeremy for review; feel free to bounce it to someone else. ------------------------------------------------------- Date: 2000-Jul-25 17:25 By: akuchling Comment: Update patch to latest version, which adds poll() to the select() module. ------------------------------------------------------- Date: 2000-Jul-25 20:30 By: jhylton Comment: Several style nits changed, mostly to do with whitespace. Substantive changes: 1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens 2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND One more Open Issue: I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions: - interface to register many fds at once - keep the list of fds in sorted order - use a dict to store fds and generate fdarry lazily - keep track of allocated length and used length for ufds, so that fewer reallocs are required Each of these suggestions has some added complexity, so I'm not sure that I like any of them. ------------------------------------------------------- Date: 2000-Jul-25 20:41 By: akuchling Comment: I wondered about the linear search, too; it means balancing efficiency versus the lines of code to write this one object? IMHO implementing both #1 and #3 would be good; allow passing an arbitrary # of fds to register (and unregister?), store them in a dict, and then lazily generate the ufd array when needed. Or is there some built-in more suited than a dict for this? Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors. ------------------------------------------------------- Date: 2000-Jul-25 21:40 By: jhylton Comment: I think a dict is the right data structure, but I don't think it should be exposed directly. If it is not exposed, then the ufd array need only be generated for poll calls after a register or unregister. If there are multiple polls without a change, the same array can be re-used. ------------------------------------------------------- Date: 2000-Aug-13 04:13 By: akuchling Comment: Latest version, which stores an underlying dict as suggested in jhylton's previous comment. p.unregister() raises KeyError if you unregister a fd that wasn't registered in the first place; seem reasonable? It does to me... The code should now be completed; the only remaining task is to write docstrings and finish the documentation patch. ------------------------------------------------------- Date: 2000-Aug-15 17:36 By: tim_one Comment: Tickling you as part of 2.0 nagging. Please leave a note saying when you intend to "write docstrings and finish the documentation". ------------------------------------------------------- Date: 2000-Aug-16 00:57 By: akuchling Comment: Revised version -- documentation & docstrings completed, and there's a test script (not part of patch). Ready to check in once someone gives the patch a quick once-over and sanity check. ------------------------------------------------------- Date: 2000-Aug-16 02:38 By: tim_one Comment: Assigned to Barry for a quick once-over and sanity check, as he's looking at the socket code and "select" also begins with an "s", while the "p" in "poll" doesn't show up in "Cravin' Dogs" at all! A natural fit. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 From noreply@sourceforge.net Tue Aug 22 08:12:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 00:12:00 -0700 Subject: [Patches] [Patch #100837] urllib patch to simplify POST form query Message-ID: <200008220712.AAA20567@delerium.i.sourceforge.net> Patch #100837 has been updated. Project: Category: library Status: Open Summary: urllib patch to simplify POST form query Follow-Ups: Date: 2000-Jul-10 12:49 By: VizNut Comment: (SourceForce tossed my comment for the original patch, so here it is.) Current GET form query: filename, headers = urllib.urlretrieve( "%s?%s" % ( BASE_URL, urllib.urlencode( parms ) ), filename ) Desirable POST form query: filename, headers = urllib.urlretrieve( BASE_URL, filename, data=urllib.urlencode( parms ) ) Current POST form query: fp = urllib.urlopen( BASE_URL, urllib.urlencode( parms ) ) tfp = open(filename, 'wb') bs = 1024*8 block = fp.read(bs) while block: tfp.write(block) block = fp.read(bs) tfp.close() fp.close() The latter is required because there is no way to feed the data parameters for the POST query to urlretrieve. The chunked read is necessary because these forms sometimes generate datasets larger than virtual memory (as in this case). ------------------------------------------------------- Date: 2000-Jul-12 14:04 By: moshez Comment: This looks cool! I'm +1 on this. (I haven't tested this patch yet, so I'll need to. From a cursory glance at the implementation it looks quite straightforward) ------------------------------------------------------- Date: 2000-Aug-15 17:33 By: tim_one Comment: Reassigned to Fred because Jeremy's gone. Fred, know anything about this stuff? Review or assign to someone else, please. ------------------------------------------------------- Date: 2000-Aug-15 18:09 By: fdrake Comment: This patch requires documentation; please update to modify Doc/lib/liburllib.tex, or provide specific (unmarked) text in a comment. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100837&group_id=5470 From noreply@sourceforge.net Tue Aug 22 08:32:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 00:32:10 -0700 Subject: [Patches] [Patch #100837] urllib patch to simplify POST form query Message-ID: <200008220732.AAA21238@delerium.i.sourceforge.net> Patch #100837 has been updated. Project: Category: library Status: Open Summary: urllib patch to simplify POST form query Follow-Ups: Date: 2000-Jul-10 12:49 By: VizNut Comment: (SourceForce tossed my comment for the original patch, so here it is.) Current GET form query: filename, headers = urllib.urlretrieve( "%s?%s" % ( BASE_URL, urllib.urlencode( parms ) ), filename ) Desirable POST form query: filename, headers = urllib.urlretrieve( BASE_URL, filename, data=urllib.urlencode( parms ) ) Current POST form query: fp = urllib.urlopen( BASE_URL, urllib.urlencode( parms ) ) tfp = open(filename, 'wb') bs = 1024*8 block = fp.read(bs) while block: tfp.write(block) block = fp.read(bs) tfp.close() fp.close() The latter is required because there is no way to feed the data parameters for the POST query to urlretrieve. The chunked read is necessary because these forms sometimes generate datasets larger than virtual memory (as in this case). ------------------------------------------------------- Date: 2000-Jul-12 14:04 By: moshez Comment: This looks cool! I'm +1 on this. (I haven't tested this patch yet, so I'll need to. From a cursory glance at the implementation it looks quite straightforward) ------------------------------------------------------- Date: 2000-Aug-15 17:33 By: tim_one Comment: Reassigned to Fred because Jeremy's gone. Fred, know anything about this stuff? Review or assign to someone else, please. ------------------------------------------------------- Date: 2000-Aug-15 18:09 By: fdrake Comment: This patch requires documentation; please update to modify Doc/lib/liburllib.tex, or provide specific (unmarked) text in a comment. ------------------------------------------------------- Date: 2000-Aug-22 07:32 By: moshez Comment: Documentation updates summary: add the following paragraph (copied from urlopen's description) to urlretrieve's description: If the \var{url} uses the \file{http:} scheme identifier, the optional \var{data} argument may be given to specify a \code{POST} request (normally the request type is \code{GET}). The \var{data} argument must in standard \file{application/x-www-form-urlencoded} format; see the \function{urlencode()} function below. And add the same paragraph to URLopener's retrieve method. Additionally, of course, \optional{, data} should be added to the synopsis of these methods. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100837&group_id=5470 From Fredrik Lundh" Message-ID: <008501c00c0c$6dde4d00$f2a6b5d4@hagrid> This is a multi-part message in MIME format. ------=_NextPart_000_007E_01C00C1D.2FA1ED60 Content-Type: text/plain; charset="ibm850" Content-Transfer-Encoding: 7bit (cannot login to SF right now, so I'll follow up by mail instead) guido: > This looks fine to me -- but when I test it (VC 6 on Win98), it doesn't > work. Try this: > > class C: > def __getattr__(self, a): return self.x > > C() > > This still aborts the program. note that I've just implemented the CheckStack operation for MSVC; I didn't plug more holes in the interpreter. see the attached patch for an attempt to fix this one. (it seems to work, but the getattr code is a bit convoluted, so it's possible that the stack check should really be placed some- where else...) > As shown it breaks the build for _sre because the declaration for > PyOS_CheckStack() doesn't use DL_IMPORT(). (MSVC 6.0 on Win98.) well, I just rebuilt the core interpreter, and tested the __str__ and __repr__ cases (Bug #110615). this glitch is fixed in the new patch. ::: CheckStack is also used to prevent run-away recursion in main interpreter, but the recursion limit check catches that before you run out of stack on Windows (with a standard stack, that is). maybe the recursion limit check should be disabled if CheckStack is available? ::: I've attached a new version of the patch. I'll post it to SF later today. ------=_NextPart_000_007E_01C00C1D.2FA1ED60 Content-Type: text/plain; name="stack-patch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="stack-patch.txt" Index: Include/pythonrun.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/pythonrun.h,v retrieving revision 2.32 diff -c -r2.32 pythonrun.h *** Include/pythonrun.h 2000/08/07 21:00:42 2.32 --- Include/pythonrun.h 2000/08/22 07:13:15 *************** *** 87,94 **** DL_IMPORT(char *) PyOS_Readline(char *); extern DL_IMPORT(int) (*PyOS_InputHook)(void); extern DL_IMPORT(char) *(*PyOS_ReadlineFunctionPointer)(char *); #ifdef USE_STACKCHECK ! int PyOS_CheckStack(void); /* Check that we aren't overflowing our stack */ #endif #ifdef __cplusplus --- 87,106 ---- DL_IMPORT(char *) PyOS_Readline(char *); extern DL_IMPORT(int) (*PyOS_InputHook)(void); extern DL_IMPORT(char) *(*PyOS_ReadlineFunctionPointer)(char *); + + /* Stack size, in "pointers" (so we get extra safety margins + on 64-bit platforms). On a 32-bit platform, this translates + to a 2000-byte margin. */ + #define PYOS_STACK_THRESHOLD 500 + + #if defined(WIN32) && defined(_MSC_VER) + /* Enable stack checking under Microsoft C */ + #define USE_STACKCHECK + #endif + #ifdef USE_STACKCHECK ! /* Check that we aren't overflowing our stack */ ! DL_IMPORT(int) PyOS_CheckStack(void); #endif #ifdef __cplusplus Index: Python/pythonrun.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/pythonrun.c,v retrieving revision 2.107 diff -c -r2.107 pythonrun.c *** Python/pythonrun.c 2000/08/15 16:13:37 2.107 --- Python/pythonrun.c 2000/08/22 07:13:18 *************** *** 1165,1167 **** --- 1165,1196 ---- (strcmp(filename, "") == 0) || (strcmp(filename, "???") == 0); } + + + #if defined(USE_STACKCHECK) + #if defined(WIN32) && defined(_MSC_VER) + + /* Stack checking for Microsoft C */ + + #include + #include + + int + PyOS_CheckStack() + { + __try { + /* _alloca throws a stack overflow exception if there's + not enough space left on the stack */ + _alloca(PYOS_STACK_THRESHOLD * sizeof(void*)); + return 0; + } __except (EXCEPTION_EXECUTE_HANDLER) { + /* just ignore all errors */ + } + return 1; + } + + #endif /* WIN32 && _MSC_VER */ + + /* Alternate implementations can be added here... */ + + #endif /* USE_STACKCHECK */ Index: Objects/classobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v retrieving revision 2.104 diff -c -r2.104 classobject.c *** Objects/classobject.c 2000/08/18 04:57:32 2.104 --- Objects/classobject.c 2000/08/22 07:13:21 *************** *** 639,644 **** --- 639,650 ---- res = instance_getattr1(inst, name); if (res == NULL && (func = inst->in_class->cl_getattr) != NULL) { PyObject *args; + #ifdef USE_STACKCHECK + if (PyOS_CheckStack()) { + PyErr_SetString(PyExc_MemoryError, "Stack overflow"); + return NULL; + } + #endif PyErr_Clear(); args = Py_BuildValue("(OO)", inst, name); if (args == NULL) ------=_NextPart_000_007E_01C00C1D.2FA1ED60-- From guido@beopen.com Tue Aug 22 13:57:31 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 22 Aug 2000 07:57:31 -0500 Subject: [Patches] Re: [Patch #101238] PyOS_CheckStack for Windows (MSVC) In-Reply-To: Your message of "Tue, 22 Aug 2000 09:41:45 +0200." <008501c00c0c$6dde4d00$f2a6b5d4@hagrid> References: <200008220235.TAA11733@delerium.i.sourceforge.net> <008501c00c0c$6dde4d00$f2a6b5d4@hagrid> Message-ID: <200008221257.HAA09963@cj20424-a.reston1.va.home.com> > guido: > > This looks fine to me -- but when I test it (VC 6 on Win98), it doesn't > > work. Try this: > > > > class C: > > def __getattr__(self, a): return self.x > > > > C() > > > > This still aborts the program. effbot: > note that I've just implemented the CheckStack operation for > MSVC; I didn't plug more holes in the interpreter. see the > attached patch for an attempt to fix this one. Hm. My reasoning was that since CheckStack is called every 10 recursions by ceval.c, and the above example clearly executes Python code at each recursion, it should be caught. Why isn't it? is the margin (2K) too small for 10 recursions? > (it seems to work, but the getattr code is a bit convoluted, so > it's possible that the stack check should really be placed some- > where else...) > > > As shown it breaks the build for _sre because the declaration for > > PyOS_CheckStack() doesn't use DL_IMPORT(). (MSVC 6.0 on Win98.) > > well, I just rebuilt the core interpreter, and tested the __str__ > and __repr__ cases (Bug #110615). this glitch is fixed in the > new patch. I'll look at it more when I have more time. (Today we've got a group meeting all day first.) > ::: > > CheckStack is also used to prevent run-away recursion in main > interpreter, but the recursion limit check catches that before you > run out of stack on Windows (with a standard stack, that is). > > maybe the recursion limit check should be disabled if CheckStack > is available? I think so. But it ought to be tested. Have you timed this? --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From noreply@sourceforge.net Tue Aug 22 15:39:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 07:39:18 -0700 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' Message-ID: <200008221439.HAA13961@bush.i.sourceforge.net> Patch #101243 has been updated. Project: Category: core (C code) Status: Open Summary: Use a compile time mechanism to 'find "import-from" args' Follow-Ups: Date: 2000-Aug-20 22:57 By: twouters Comment: This patch changes the mechanism used to find the 'import-arguments' as passed to __import__ (and used by 'ni' and such dynamic import mechanisms.) The current mechanism looks into the 'future' bytecode stream (from the IMPORT_NAME statement onward) looking for IMPORT_FROM statements. The problem is that this limits the extend in which we can change IMPORT_FROM, and that this is a runtime check for information which was available at compile-time. Instead, we create a list of import-from arguments, and push it on the stack. The list creation is still done at runtime (it has to be, I think ?) but it's a simple push-constants-on-the-stack-and-BUILD_LIST operation. The result is that all 'import arguments' (the names imported-from another module) are present not only as normal 'names' in the co_names list, but also as PyString objects in the co_consts list. And that pystone runs a few promille faster on my machine. And that more trickery is allowed in imports, such as those that patch #101234 allows. ------------------------------------------------------- Date: 2000-Aug-22 02:18 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-22 02:21 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-22 02:53 By: gvanrossum Comment: Cool, but needs some work before you can check it in. Notes: - Yes, a tuple constant would be fine. (Note: co_names and co_consts are really redundant; all that's needed is co_consts.) - In ceval.c, why not place "u = POP()" *after* the test for x==NULL? Then you don't need to DECREF it when x==NULL. - You left the fprintf in com_pop() uncommented! - Barry just bumped the MAGIC number. There's no need to do this twice a week if no release occurred. :) ------------------------------------------------------- Date: 2000-Aug-22 16:39 By: twouters Comment: - Okay, I'll rewrite it to create a tuple. Note, however ! This means that the import mechanism gets passed in a tuple, instead of a list. I'm not sure if that will break anything, or influence user-code in any way, because I can't say I fully understand the import mechanisms yet ;) But I did notice that PyImport_ImportModule() takes care to build a list instead of a tuple, to pass to PyImport_ImportModuleEx() - moving the POP(): fine. I'm never quite sure when to POP an item or not. I was under the impression that you needed to pop all items the bytecode is 'supposed' to pop (and push back the number of items it's supposed to push, even if they are NULL) before raising an exception. But that's just the impression I got from reading the code, not from reading the exception mechanism. - The entries in co_names are not really redundant. The co_names entries are used for the actual IMPORT_FROM and STORE_NAME opcodes, this new tuple (or list) only for the IMPORT_NAME opcode. I don't think it's worth the effort to combine the two, because it would require either rewriting the STORE opcodes to use a const rather than a name, or find out in some way which 'names' are used in imports. Anyway, since they're both PyStrings, and both likely to be interned, it's just a pointer duplication. - fprintf: oops. Will fix. - Bumping the magic: I'm not so certain about not upping the bytecode magic: we're not using up a scarce resource, here, because it's upped according to date anyway. Is not upping it worth the small chance that someone imports new bytecode in an old interpreter and gets weird behaviour ? Patch follows later: I'm trying not to neglect my other patches in the mean time, and that's proven tricky with the number of conflicting checkins in the last two weeks :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 From noreply@sourceforge.net Tue Aug 22 15:56:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 07:56:44 -0700 Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test Message-ID: <200008221456.HAA14663@bush.i.sourceforge.net> Patch #101257 has been updated. Project: Category: library Status: Open Summary: Update test cases for posixpath, ntpath, add dospath test ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101257&group_id=5470 From noreply@sourceforge.net Tue Aug 22 15:59:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 07:59:02 -0700 Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test Message-ID: <200008221459.HAA14688@bush.i.sourceforge.net> Patch #101257 has been updated. Project: Category: library Status: Open Summary: Update test cases for posixpath, ntpath, add dospath test Follow-Ups: Date: 2000-Aug-22 10:59 By: montanaro Comment: assigned to fred since it contains a (minor) doc change. ;-) Fred - it probably should go to Tim or Guido next. Note that ntpath and dospath are not documented if someone wants to take the time... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101257&group_id=5470 From thomas@xs4all.net Tue Aug 22 16:24:44 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 22 Aug 2000 17:24:44 +0200 Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test In-Reply-To: <200008221459.HAA14688@bush.i.sourceforge.net>; from noreply@sourceforge.net on Tue, Aug 22, 2000 at 07:59:02AM -0700 References: <200008221459.HAA14688@bush.i.sourceforge.net> Message-ID: <20000822172443.J4933@xs4all.nl> On Tue, Aug 22, 2000 at 07:59:02AM -0700, noreply@sourceforge.net wrote: > Patch #101257 has been updated. > Project: > Category: library > Status: Open > Summary: Update test cases for posixpath, ntpath, add dospath test > > Follow-Ups: > > Date: 2000-Aug-22 10:59 > By: montanaro > > Comment: > assigned to fred since it contains a (minor) doc change. ;-) > Fred - it probably should go to Tim or Guido next. > > Note that ntpath and dospath are not documented if > someone wants to take the time... Uhm, why is this change uploaded ? You already broke the test cases (at least, as far as I can tell: I was testing two patches and test_posixpath is failing for me. Wasn't the policy that no checking should leave failing tests ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Tue Aug 22 16:32:24 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 22 Aug 2000 10:32:24 -0500 (CDT) Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test In-Reply-To: <20000822172443.J4933@xs4all.nl> References: <200008221459.HAA14688@bush.i.sourceforge.net> <20000822172443.J4933@xs4all.nl> Message-ID: <14754.40200.906372.542375@beluga.mojam.com> Thomas> Uhm, why is this change uploaded ? You already broke the test Thomas> cases (at least, as far as I can tell: I was testing two patches Thomas> and test_posixpath is failing for me. Wasn't the policy that no Thomas> checking should leave failing tests ? Dunno. I told Tim & Guido that's how I was going to do it. Neither one complained. I assume this will pass through the system fairly quickly and be checked in later today. Skip From noreply@sourceforge.net Tue Aug 22 17:13:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 09:13:59 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008221613.JAA17755@bush.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-16 01:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 17:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-23 00:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 15:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 19:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 19:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 20:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 23:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 23:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 18:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Tue Aug 22 17:26:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 09:26:50 -0700 Subject: [Patches] [Patch #100699] Augmented Assignment, the Python Way (huge) Message-ID: <200008221626.JAA07677@delerium.i.sourceforge.net> Patch #100699 has been updated. Project: Category: core (C code) Status: Open Summary: Augmented Assignment, the Python Way (huge) Follow-Ups: Date: 2000-Jul-01 02:49 By: twouters Comment: This patch adds augmented assignment (+=, **=, etc) to Python, in a manner which seems consistent with Guido and Tim's wishes (for as far as I know them.) Guido has already stated this patch will not make it to Python 2.0, so the first to read this should probably set the state to 'postponed'. I'll try and keep this patch up to date none the less, for peer (or rather parent ;) reviewal. The patch adds everything in one smack: Syntax, a new type of bytecode (2-argument), 9 new bytecodes, 13 new API calls, 11 new PyNumber_Methods members, 2 new PySequence_Methods members, and support for the new functionality in builtin types and supplied Python classes. Oh, and a test suite. None the less, it isn't that intrusive a patch, and the simplicity of the implementation still boggles me. For more information, see http://www.xs4all.nl/~thomas/python/ Comments greatly appreciated! Contact me on thomas@xs4all.net (I'm not on python-dev) ------------------------------------------------------- Date: 2000-Jul-01 03:10 By: gvanrossum Comment: Cool! We'll look at this after 2.0 is released... ------------------------------------------------------- Date: 2000-Jul-13 22:53 By: jhylton Comment: This patch needs to be postponed until the PEP is written. ------------------------------------------------------- Date: 2000-Jul-25 15:37 By: gvanrossum Comment: Not ready to be checked in, but Thomas is working on it! This will be in 2.0 after all... ------------------------------------------------------- Date: 2000-Aug-06 14:33 By: twouters Comment: New version of the patch, that eliminates the need for 2-argument opcodes and the GETSET_* opcodes. Instead, INPLACE_* opcodes are used, that mirror the BINARY_* opcodes, and two new 'utility' opcodes: ROT_FOUR and DUP_TOPX (duplicates the top items on the stack.) The PEP documenting this implementation will follow soon. ------------------------------------------------------- Date: 2000-Aug-21 05:42 By: gvanrossum Comment: BDFL pronouncement: please use __iadd__, __imul__ etc. ------------------------------------------------------- Date: 2000-Aug-22 18:26 By: twouters Comment: Up to date version that incorporates the BDFL-Pronouncement to use __iadd__ rather than __add_ab__. Also made PyNumber_InPlacePower() a three-argument function (since normal Power() is one, and we can't change this functions' prototype later, if we would want to.) The three argument InPlacePower() does the normal batch of coercions, so it's not terribly likely to remain an 'in-place' operation :-S I'm working on docs, but on my laptop, not incorporated in this patch. Also, the testcase needs to be expanded a bit, and probably incorporated with the test_class testcase I added last week. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100699&group_id=5470 From ping@lfw.org Tue Aug 22 20:30:53 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Tue, 22 Aug 2000 12:30:53 -0700 (PDT) Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict In-Reply-To: <011701c00a1f$99902ac0$7aa41718@beopen.com> Message-ID: On Fri, 18 Aug 2000, Guido van Rossum wrote: > If I understand the discussion below correctly, to get the > value for 'foo' you must use > > x['foo'].value > > but now you can also use > > x.get('foo') This is true. > ??? That's inconsistent compared to how these two behave for regular > dictionaries! I mulled this over a while when doing the patch. Initially, i did make form.get(x) behave exactly like form[x], and proceeded to try to make the FieldStorage object behave as much like a dictionary as possible (since the docs say it can be "accessed like a dictionary"). FormContentDict and its descendants clearly behave like a dictionary since they are derived from UserDict. But as i investigated FieldStorage further, i found that it actually lacks lots of dictionary behaviour: no update(), no clear(), no copy(), no items(), no values(). The only dictionary-like semantics we really care about are [key], keys(), and has_key(). Implementing items() and values() would require an uncertain choice, since the FieldStorage represents a multimap: do multi-valued fields appear as multiple key-value pairs with the same key, or a single pair with a list for its value? In the end, i decided to abandon true dictionary-like behaviour, because the thing being represented is a bit too much more than a dictionary. By far the most common use of the FieldStorage (and even the entire cgi module) is just to decode simple strings from single-valued form fields, and the interface should do its best to facilitate that common use. I decided it was okay to break consistency with regular dictionaries (a) as long as the behaviour is clearly documented and (b) since it doesn't fully satisfy one's expectations of a dictionary anyway. Moshe's response drove home the point when he demonstrated that the advantage of get() -- to provide a default when a value is missing -- is overwhelmed by the awkwardness of the .value interface. If get() returns a MiniFieldStorage, then to default the "spam" field to "eggs" i have to say field = form.get("spam", "eggs") if type(field) is type(""): process(field) else: process(field.value) or field = form.get("spam", None) if field is None: process("eggs") else: process(field.value) or field = form.get("spam", cgi.MiniFieldStorage("spam", "eggs")) process(field.value) which are hardly any better than if form.has_key("spam"): process(form["spam"].value) else: process("eggs") at all! If get() returns a string, then i can just say process(form.get("spam", "eggs")) and i can be on my way. I have personally stayed away from FieldStorage because it's so annoying to use; having to look up the "value" attribute on every form field makes programs verbose and awkward. This gets worse when a field has multple values. In fact, the usage example provided in Doc/lib/libcgi.tex is a perfect demonstration: username = form["username"] if type(username) is type([]): usernames = "" for item in username: if username: usernames = usernames + "," + item.value else: usernames = item.value else: usernames = username.value The above can be shortened somewhat with map(), but with the new get() method, this can simply be written in the obvious way: value = form.get("username", "") if type(value) is type([]): usernames = ",".join(value) else: usernames = value (The latter is what you would do with a FormContentDict, which is why i find it so vastly more convenient than the FieldStorage. It's slightly better, though: it also painlessly handles the case where the "username" field is not present.) As mentioned earlier, i'm more concerned about the default setting for keep_blank_values. The message i wrote providing a complete explanation of this issue is included below so you don't have to search through old e-mail to find it. -- ?!ng -------- the headers of the original message -------- From ping@lfw.org Wed Aug 16 10:31:48 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 16 Aug 2000 02:31:48 -0700 (PDT) Subject: [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict -------- the message body, with some edits -------- Hi, guys. This patch includes a "fix" to make cgi.parse_qsl honour its "keep_blank_values" argument. This fix might require a bit more discussion since it could break compatibility, so i thought i would air it for your consideration. BACKGROUND ---------- cgi.FieldStorage(), cgi.parse(), cgi.parse_qs(), and cgi.parse_qsl() all accept an optional "keep_blank_values" argument which is supposed to indicate whether form fields with empty strings as values should be included in the result. In reality, only cgi.parse_qs() honours this flag (cgi.parse() is okay because it uses cgi.parse_qs()). cgi.parse_qsl() totally ignores it, and always includes all values including empty ones. cgi.FieldStorage(), which uses cgi.parse_qsl(), similarly does not honour the "keep_blank_values" flag. The patch contains a fix to make cgi.parse_qsl() honour this flag. FOR --- It's clear that this was the intent of the "keep_blank_values" argument. The doc string for parse_qsl says: """Parse a query given as a string argument. Arguments: qs: URL-encoded query string to be parsed keep_blank_values: flag indicating whether blank values in URL encoded queries should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. Returns a list, as God intended. """ Its current disregard for "keep_blank_values" clearly contradicts this doc string. The doc string for FieldStorage.__init__ says: """Constructor. Read multipart/* until last part. Arguments, all optional: fp : file pointer; default: sys.stdin (not used when the request method is GET) headers : header dictionary-like object; default: taken from environ as per CGI spec outerboundary : terminating multipart boundary (for internal use only) environ : environment dictionary; default: os.environ keep_blank_values: flag indicating whether blank values in URL encoded forms should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. """ ...and the current behaviour of FieldStorage.__init__ contradicts what it says here about "keep_blank_values". AGAINST ------- Existing code which uses FieldStorage and relies on its current behaviour could break. If a form field is left blank by the user and the form is submitted, that key will not appear in the FieldStorage -- and an attempt to index it with form[key] will produce a KeyError where previously it yielded a MiniFieldStorage containing an empty string. The existing TeX documentation for the cgi module does not mention empty values or the keep_blank_values argument at all, so to those who have only read the library reference manual, this could be a surprise. OPTIONS ------- The reason this never showed up before is that there have never been *any* tests for FieldStorage in test_cgi.py! Naughty, naughty. One easy way to maintain compatibility is to change FieldStorage so that the default value for keep_blank_values is 1 (previously this was 0 but the FieldStorage *acted* as though it were 1). -- ?!ng From noreply@sourceforge.net Tue Aug 22 21:46:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 13:46:41 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008222046.NAA17768@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 20:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 21:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-16 06:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-16 06:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 07:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 09:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 09:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-22 01:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- Date: 2000-Aug-22 04:41 By: moshez Comment: Actually, it's now waiting for someone's pronouncement -- Guido had a problem with .get() and __getitem__ not being equivalent (the first does an implicit .value). Ping and I thought it best that way, but if the BDFL has strong feelings otherwise, he should pronounce. Assigned to him for final verdict. ------------------------------------------------------- Date: 2000-Aug-22 20:46 By: ping Comment: On Fri, 18 Aug 2000, Guido van Rossum wrote: > If I understand the discussion below correctly, to get the > value for 'foo' you must use > > x['foo'].value > > but now you can also use > > x.get('foo') This is true. > ??? That's inconsistent compared to how these two behave for regular > dictionaries! I mulled this over a while when doing the patch. Initially, i did make form.get(x) behave exactly like form[x], and proceeded to try to make the FieldStorage object behave as much like a dictionary as possible (since the docs say it can be "accessed like a dictionary"). FormContentDict and its descendants clearly behave like a dictionary since they are derived from UserDict. But as i investigated FieldStorage further, i found that it actually lacks lots of dictionary behaviour: no update(), no clear(), no copy(), no items(), no values(). The only dictionary-like semantics we really care about are [key], keys(), and has_key(). Implementing items() and values() would require an uncertain choice, since the FieldStorage represents a multimap: do multi-valued fields appear as multiple key-value pairs with the same key, or a single pair with a list for its value? In the end, i decided to abandon true dictionary-like behaviour, because the thing being represented is a bit too much more than a dictionary. By far the most common use of the FieldStorage (and even the entire cgi module) is just to decode simple strings from single-valued form fields, and the interface should do its best to facilitate that common use. I decided it was okay to break consistency with regular dictionaries (a) as long as the behaviour is clearly documented and (b) since it doesn't fully satisfy one's expectations of a dictionary anyway. Moshe's response drove home the point when he demonstrated that the advantage of get() -- to provide a default when a value is missing -- is overwhelmed by the awkwardness of the .value interface. If get() returns a MiniFieldStorage, then to default the "spam" field to "eggs" i have to say field = form.get("spam", "eggs") if type(field) is type(""): process(field) else: process(field.value) or field = form.get("spam", None) if field is None: process("eggs") else: process(field.value) or field = form.get("spam", cgi.MiniFieldStorage("spam", "eggs")) process(field.value) which are hardly any better than if form.has_key("spam"): process(form["spam"].value) else: process("eggs") at all! If get() returns a string, then i can just say process(form.get("spam", "eggs")) and i can be on my way. I have personally stayed away from FieldStorage because it's so annoying to use; having to look up the "value" attribute on every form field makes programs verbose and awkward. This gets worse when a field has multple values. In fact, the usage example provided in Doc/lib/libcgi.tex is a perfect demonstration: username = form["username"] if type(username) is type([]): usernames = "" for item in username: if username: usernames = usernames + "," + item.value else: usernames = item.value else: usernames = username.value The above can be shortened somewhat with map(), but with the new get() method, this can simply be written in the obvious way: value = form.get("username", "") if type(value) is type([]): usernames = ",".join(value) else: usernames = value (The latter is what you would do with a FormContentDict, which is why i find it so vastly more convenient than the FieldStorage. It's slightly better, though: it also painlessly handles the case where the "username" field is not present.) As mentioned earlier, i'm more concerned about the default setting for keep_blank_values. The message i wrote providing a complete explanation of this issue is included below so you don't have to search through old e-mail to find it. -- ?!ng -------- the headers of the original message -------- >From ping@lfw.org Tue Aug 22 12:18:57 2000 Date: Wed, 16 Aug 2000 02:31:48 -0700 (PDT) From: Ka-Ping Yee To: Moshe Zadka , bwarsaw@beopen.com, tpeters@beopen.com Subject: Re: [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict -------- the message body, with some edits -------- Hi, guys. This patch includes a "fix" to make cgi.parse_qsl honour its "keep_blank_values" argument. This fix might require a bit more discussion since it could break compatibility, so i thought i would air it for your consideration. BACKGROUND ---------- cgi.FieldStorage(), cgi.parse(), cgi.parse_qs(), and cgi.parse_qsl() all accept an optional "keep_blank_values" argument which is supposed to indicate whether form fields with empty strings as values should be included in the result. In reality, only cgi.parse_qs() honours this flag (cgi.parse() is okay because it uses cgi.parse_qs()). cgi.parse_qsl() totally ignores it, and always includes all values including empty ones. cgi.FieldStorage(), which uses cgi.parse_qsl(), similarly does not honour the "keep_blank_values" flag. The patch contains a fix to make cgi.parse_qsl() honour this flag. FOR --- It's clear that this was the intent of the "keep_blank_values" argument. The doc string for parse_qsl says: """Parse a query given as a string argument. Arguments: qs: URL-encoded query string to be parsed keep_blank_values: flag indicating whether blank values in URL encoded queries should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. Returns a list, as God intended. """ Its current disregard for "keep_blank_values" clearly contradicts this doc string. The doc string for FieldStorage.__init__ says: """Constructor. Read multipart/* until last part. Arguments, all optional: fp : file pointer; default: sys.stdin (not used when the request method is GET) headers : header dictionary-like object; default: taken from environ as per CGI spec outerboundary : terminating multipart boundary (for internal use only) environ : environment dictionary; default: os.environ keep_blank_values: flag indicating whether blank values in URL encoded forms should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. """ ...and the current behaviour of FieldStorage.__init__ contradicts what it says here about "keep_blank_values". AGAINST ------- Existing code which uses FieldStorage and relies on its current behaviour could break. If a form field is left blank by the user and the form is submitted, that key will not appear in the FieldStorage -- and an attempt to index it with form[key] will produce a KeyError where previously it yielded a MiniFieldStorage containing an empty string. The existing TeX documentation for the cgi module does not mention empty values or the keep_blank_values argument at all, so to those who have only read the library reference manual, this could be a surprise. OPTIONS ------- The reason this never showed up before is that there have never been *any* tests for FieldStorage in test_cgi.py! Naughty, naughty. One easy way to maintain compatibility is to change FieldStorage so that the default value for keep_blank_values is 1 (previously this was 0 but the FieldStorage *acted* as though it were 1). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Wed Aug 23 10:18:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 02:18:01 -0700 Subject: [Patches] [Patch #101264] Attribute Doc-Strings Message-ID: <200008230918.CAA10855@delerium.i.sourceforge.net> Patch #101264 has been updated. Project: Category: core (C code) Status: Open Summary: Attribute Doc-Strings ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470 From noreply@sourceforge.net Wed Aug 23 10:22:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 02:22:28 -0700 Subject: [Patches] [Patch #101264] Attribute Doc-Strings Message-ID: <200008230922.CAA11039@delerium.i.sourceforge.net> Patch #101264 has been updated. Project: Category: core (C code) Status: Open Summary: Attribute Doc-Strings Follow-Ups: Date: 2000-Aug-23 09:22 By: lemburg Comment: This patch implements the proposed addition of doc-strings for e.g. class attribute, module attributes, etc. See the upcoming PEP for details (the PEP was already submitted to the PEP editor for review). Here's a shot excerpt: class C: " class C doc-string " a = 1 " attribute C.a doc-string (1)" b = 2 " attribute C.b doc-string (2)" results in following new class attributes to be created: C.__doc__a__ == " attribute C.a doc-string (1)" C.__doc__b__ == " attribute C.b doc-string (2)" ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470 From noreply@sourceforge.net Wed Aug 23 10:32:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 02:32:06 -0700 Subject: [Patches] [Patch #100895] safe version of PyErr_Format Message-ID: <200008230932.CAA11360@delerium.i.sourceforge.net> Patch #100895 has been updated. Project: Category: core (C code) Status: Open Summary: safe version of PyErr_Format Follow-Ups: Date: 2000-Jul-17 21:56 By: effbot Comment: minor tweaks (mostly comments), based on input from moshe. ------------------------------------------------------- Date: 2000-Jul-18 06:23 By: moshez Comment: I'm +1 on that! It will plug one more security hole in Python, and seems a "good enough" replacement for an unsure snprintf() ------------------------------------------------------- Date: 2000-Aug-08 17:19 By: effbot Comment: regenerated, since moshez reported that it didn't apply cleanly to the current CVS tree. reassigned, since it's been sitting here for ages. ------------------------------------------------------- Date: 2000-Aug-11 04:04 By: tim_one Comment: Rejected and back to /F. Major: no docs! Format strings processed by this have different semantics than anyone could guess (e.g., flags are ignored, width is ignored, some format codes are copied verbatim). Reverse-engineering the code each time there's a question is just too painful. You're basically inventing a new sublanguage here, so document what the heck it is & means. Mechanical: There's a "step 1" but no "step 2" . We shouldn't be #ifdef'ing on prototypes anymore. Guido did not yield to the push for 4-space indents in C code, so this should use hard tabs. ------------------------------------------------------- Date: 2000-Aug-16 00:05 By: tim_one Comment: Changed status from Rejeced to Open so we only have to look in one place for the status of putative 2.0 patches. But the patch is still *effectively* rejected pending response to the objections. ------------------------------------------------------- Date: 2000-Aug-22 01:42 By: tim_one Comment: Just reminding you this is still on your plate. ------------------------------------------------------- Date: 2000-Aug-23 09:32 By: moshez Comment: Here's a summary, for a future documentation patch: PyObject *PyErr_Format(PyObject *exception, char *fmt, ...) exception should be a Python object. "fmt" should be a string, containing format codes, similar to "printf". width.precision is parsed, but the width part is ignored. Formatting characters --------------------- 'c' -- format a character, as an "int" argument 'd' -- format a number in decimal, as an "int" argument 'x' -- format a number in hex, as an "int" argument 's' -- format a C string, as a "char *" argument An unrecognized format character causes all the rest of the format string to be copied as-is to the result string, and any extra arguments discarded. A new reference is returned, which is owned by the caller. I don't want to clobber the patch with an API docs patch, but the above should be pretty much cut-and-pastable (or, if not, tell me what's wrong and I'll try and fix it) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From noreply@sourceforge.net Wed Aug 23 15:06:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 07:06:27 -0700 Subject: [Patches] [Patch #101238] PyOS_CheckStack for Windows (MSVC) Message-ID: <200008231406.HAA20915@delerium.i.sourceforge.net> Patch #101238 has been updated. Project: Category: core (C code) Status: Open Summary: PyOS_CheckStack for Windows (MSVC) Follow-Ups: Date: 2000-Aug-22 00:11 By: tim_one Comment: Assigned to Guido because there's a policy issue. This implements Jack's PyOS_CheckStack for the combo of Windows and MSVC. The question is whether you think there's a general approach waiting to be had here (I don't, except for adopting Stackless), or whether platform-specific tricks are the best we can do. ------------------------------------------------------- Date: 2000-Aug-22 01:16 By: gvanrossum Comment: The semantics of the stack are completely implementation dependent so I wouldn't know how to do this platform-independent. This looks fine to me -- but when I test it (VC 6 on Win98), it doesn't work. Try this: class C: def __getattr__(self, a): return self.x C() This still aborts the program. ------------------------------------------------------- Date: 2000-Aug-22 02:35 By: gvanrossum Comment: And are you sure you tested this? As shown it breaks the build for _sre because the declaration for PyOS_CheckStack() doesn't use DL_IMPORT(). (MSVC 6.0 on Win98.) ------------------------------------------------------- Date: 2000-Aug-23 14:06 By: effbot Comment: bumped stack margin to 8k on a 32-bit box (same as on the Macintosh). this solves the __getattr__ problem, as well as bug #110615. also: fixed the DL_IMPORT problem. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101238&group_id=5470 From noreply@sourceforge.net Wed Aug 23 16:21:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 08:21:15 -0700 Subject: [Patches] [Patch #101264] Attribute Doc-Strings Message-ID: <200008231521.IAA23589@delerium.i.sourceforge.net> Patch #101264 has been updated. Project: Category: core (C code) Status: Postponed Summary: Attribute Doc-Strings Follow-Ups: Date: 2000-Aug-23 05:22 By: lemburg Comment: This patch implements the proposed addition of doc-strings for e.g. class attribute, module attributes, etc. See the upcoming PEP for details (the PEP was already submitted to the PEP editor for review). Here's a shot excerpt: class C: " class C doc-string " a = 1 " attribute C.a doc-string (1)" b = 2 " attribute C.b doc-string (2)" results in following new class attributes to be created: C.__doc__a__ == " attribute C.a doc-string (1)" C.__doc__b__ == " attribute C.b doc-string (2)" ------------------------------------------------------- Date: 2000-Aug-23 11:21 By: tim_one Comment: Postponed due to 2.0 feature freeze and assigned to the release manager for re-opening. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470 From noreply@sourceforge.net Wed Aug 23 16:42:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 08:42:40 -0700 Subject: [Patches] [Patch #100699] Augmented Assignment, the Python Way (huge) Message-ID: <200008231542.IAA24468@delerium.i.sourceforge.net> Patch #100699 has been updated. Project: Category: core (C code) Status: Accepted Summary: Augmented Assignment, the Python Way (huge) Follow-Ups: Date: 2000-Jul-01 00:49 By: twouters Comment: This patch adds augmented assignment (+=, **=, etc) to Python, in a manner which seems consistent with Guido and Tim's wishes (for as far as I know them.) Guido has already stated this patch will not make it to Python 2.0, so the first to read this should probably set the state to 'postponed'. I'll try and keep this patch up to date none the less, for peer (or rather parent ;) reviewal. The patch adds everything in one smack: Syntax, a new type of bytecode (2-argument), 9 new bytecodes, 13 new API calls, 11 new PyNumber_Methods members, 2 new PySequence_Methods members, and support for the new functionality in builtin types and supplied Python classes. Oh, and a test suite. None the less, it isn't that intrusive a patch, and the simplicity of the implementation still boggles me. For more information, see http://www.xs4all.nl/~thomas/python/ Comments greatly appreciated! Contact me on thomas@xs4all.net (I'm not on python-dev) ------------------------------------------------------- Date: 2000-Jul-01 01:10 By: gvanrossum Comment: Cool! We'll look at this after 2.0 is released... ------------------------------------------------------- Date: 2000-Jul-13 20:53 By: jhylton Comment: This patch needs to be postponed until the PEP is written. ------------------------------------------------------- Date: 2000-Jul-25 13:37 By: gvanrossum Comment: Not ready to be checked in, but Thomas is working on it! This will be in 2.0 after all... ------------------------------------------------------- Date: 2000-Aug-06 12:33 By: twouters Comment: New version of the patch, that eliminates the need for 2-argument opcodes and the GETSET_* opcodes. Instead, INPLACE_* opcodes are used, that mirror the BINARY_* opcodes, and two new 'utility' opcodes: ROT_FOUR and DUP_TOPX (duplicates the top items on the stack.) The PEP documenting this implementation will follow soon. ------------------------------------------------------- Date: 2000-Aug-21 03:42 By: gvanrossum Comment: BDFL pronouncement: please use __iadd__, __imul__ etc. ------------------------------------------------------- Date: 2000-Aug-22 16:26 By: twouters Comment: Up to date version that incorporates the BDFL-Pronouncement to use __iadd__ rather than __add_ab__. Also made PyNumber_InPlacePower() a three-argument function (since normal Power() is one, and we can't change this functions' prototype later, if we would want to.) The three argument InPlacePower() does the normal batch of coercions, so it's not terribly likely to remain an 'in-place' operation :-S I'm working on docs, but on my laptop, not incorporated in this patch. Also, the testcase needs to be expanded a bit, and probably incorporated with the test_class testcase I added last week. ------------------------------------------------------- Date: 2000-Aug-23 15:42 By: gvanrossum Comment: Accepted. Please check it in. Then work on the docs. Please send us the docs even if you don't get to finish them!!! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100699&group_id=5470 From noreply@sourceforge.net Wed Aug 23 16:54:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 08:54:25 -0700 Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test Message-ID: <200008231554.IAA02827@bush.i.sourceforge.net> Patch #101257 has been updated. Project: Category: library Status: Open Summary: Update test cases for posixpath, ntpath, add dospath test Follow-Ups: Date: 2000-Aug-22 14:59 By: montanaro Comment: assigned to fred since it contains a (minor) doc change. ;-) Fred - it probably should go to Tim or Guido next. Note that ntpath and dospath are not documented if someone wants to take the time... ------------------------------------------------------- Date: 2000-Aug-23 15:54 By: jhylton Comment: Tim-- Can you check the validity of the dospath code? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101257&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:06:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:06:49 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008231606.JAA03210@bush.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Open Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 08:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 21:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 05:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 19:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 10:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-28 01:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 17:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- Date: 2000-Aug-09 01:26 By: tim_one Comment: Changed status to Rejected, but left assigned to me (I'll Open it again when it's updated). As I said at the bottom of my last comment on this, you cannot assume sizeof(short)==2: please get rid of the new big-endian/little-endian trickery. The code is not portable as-is. Even on machines where sizeof(short) does equal 2, shorts in the opcode stream are not guaranteed to be naturally aligned, and trying to access them as if they were can lead to anything from a core dump to an expensive trap to the OS to fix up the unaligned read. And on the only machines where this gimmick could actually pay (a little-endian machine where sizeof(short)==2 *and* the HW doesn't penalize unnatural alignment), the compiler should be smart enough to optimize the old expression for us. ------------------------------------------------------- Date: 2000-Aug-09 07:36 By: gvanrossum Comment: I think that all Tim wants is that you undo the changes you made to the NEXTARG() macro. ------------------------------------------------------- Date: 2000-Aug-10 17:51 By: cgw Comment: Understood. I've now put the NEXTARG macro back to its original form; sorry for overlooking this on the previous pass. ------------------------------------------------------- Date: 2000-Aug-11 00:25 By: tim_one Comment: Changed to Open and assigned to Vladimir. Vlad, have any comments on this? Care to test it? I'm inclined to accept it now "by eyeball", because it does fix some bugs. ------------------------------------------------------- Date: 2000-Aug-12 12:54 By: marangoz Comment: Yes, comments: there are things I like and others I don't really like. The tactics here is to remove the 2-byte integral type limit and replace it with sizeof(int). On some systems, sizeof(int) == 8, so I don't see a reason for generating only one EXTENDED_ARG opcode if the arg exceeds 2 bytes. If the arg exceeds 4 bytes, let the code generate more 2-byte arg slices, i.e. several EXTENDED_ARG in a row. Costs nothing. Overall, we both converged on the same solution. Things I like: - the fix in node.h (short -> int) - the error check in com_backpatch Things I don't really like: - the removal of E_OVERFLOW and associated checks I'd suggest using int types in node.h (instead of unsigned int) and change the existing short checks with int checks (with INT_MAX) - the label "extended_arg" in ceval.c. (after the oparg fetch) It should be really be named "dispatch_opcode". I'd suggest integrating the com_oparg & ceval's case EXTENDED_ARG code that I've posted to python-dev and adjust the rest accordingly. http://www.python.org/pipermail/python-dev/2000-August/014604.html Overall, it looks okay. I'll test it when the things I don't really like are gone. (the Python code seems to be somewhat more complex than it should be, though...) Can we get another patch from the author? Otherwise I'll try to make some time to relay this. ------------------------------------------------------- Date: 2000-Aug-15 13:29 By: tim_one Comment: Charles, do you have anything to say to Vladimir's comments? I don't see a need to have an indefinitely-extensible extended opcode gimmick today. What you already did solves real problems now, and indeed the only real problems in this area we've ever seen. I want to get that into 2.0. That doesn't preclude Vlad extending it again later. But I agree that removing the overflow checks was a bad decision. If we ever *do* bump into a case where more than what you've done is needed, Python will silently go insane. So if you can fix that much, I'll accept the patch for 2.0 immediately after. Agree too that "dispatch_opcode" is a clearer name for the label than "extended_arg". ------------------------------------------------------- Date: 2000-Aug-15 16:45 By: cgw Comment: You know, I've been fooling around with this silly little patch for quite a while. And about 3 months ago I had developed a version where you could stack up the EXTENDED_ARG opcodes, and also where I had dealt with the "offset too big" problem in com_backpatch by inserting some EXTENDED_ARGS and then relocating the subsequent code, by walking through and fixing up offsets. It worked, but it was rather hairy and slow and I convinced myself that such a patch would simply *never*get accepted. So I simplified it down as much as possible to solve the actual problem that we were having here at FNAL. I didn't really decide to take out the overflow checks, it's just that my patch pre-dated their addition. I'm uploading a new version which restores the overflow checks and renames the label as per your wishes. ------------------------------------------------------- Date: 2000-Aug-15 22:49 By: tim_one Comment: Accepted and assigned to Fred Drake for checkin. Sorry again, Fred! I'll get a patch that works one of these days (the Cygwin stuff works fine, but I can't afford the download time!). And, Charles, thank you for patience and good humor during this long ordeal. It's appreciated! ------------------------------------------------------- Date: 2000-Aug-21 21:49 By: tim_one Comment: Yo! Fred! Please check this in or assign to someone else. ------------------------------------------------------- Date: 2000-Aug-22 02:06 By: fdrake Comment: Accepted, but no builds cleanly -- causes pgen to core dump! Perhaps there are conflicts with some of the other changes? Here's the error: cd Grammar ; make OPT="-g -O2" VERSION="2.0" \ prefix="/usr/local" exec_prefix="/usr/local" all ../Parser/pgen ../../Grammar/Grammar make[1]: *** [graminit.h] Segmentation fault make: *** [Grammar] Error 2 Charles, please update the patch and I'll apply it. ------------------------------------------------------- Date: 2000-Aug-23 10:02 By: cgw Comment: I think all that's needed is a "make clean" - as far as I can tell, the dependencies on files like node.h and opcode.h aren't spelled out in the Makefiles. I think I see what's going on here. If you never do a "make depend" then the .h dependencies never get incorporated into the Makefiles. The normal "./configure; make" sequence doesn't seem to run "make depend", and so most people probably don't ever do this, since it's not in the build instructions anywhere. If you still can't get this to compile after "make clean depend" give me a holler and I'll investigate. ------------------------------------------------------- Date: 2000-Aug-23 12:06 By: fdrake Comment: Reopened after making sure I did a clean before building. This patch seems mostly fine, but needs to address test_longexp, which suddenly no longer needs to expect a SyntaxError for the long expression. This should only be a matter of regenerating the output; if this is the expected behavior, just note it in a comment here rather than changing the patch, and I can regenerate before checking it in. Thanks for all the work on this! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:17:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:17:04 -0700 Subject: [Patches] [Patch #101249] port to Monterey (64-bit AIX) and pthread fix Message-ID: <200008231617.JAA25797@delerium.i.sourceforge.net> Patch #101249 has been updated. Project: Category: Build Status: Accepted Summary: port to Monterey (64-bit AIX) and pthread fix Follow-Ups: Date: 2000-Aug-21 15:16 By: tmick Comment: This patch partly (some stuff went in already) ports Python to Monterey. Remember to 'autoconf' and 'autoheader'. - Fix bug in thread_pthread.h::PyThread_get_thread_ident() where sizeof(pthread) < sizeof(long). As Tim sort of suggested, note that function is inherently hosed. - Add 'configure' for: - SIZEOF_PTHREAD is pthread_t can be included via - setting Monterey system name - appropriate CC,LINKCC,LDSHARED,OPT, and CCSHARED for Monterey - Add section in README for Monterey build ------------------------------------------------------- Date: 2000-Aug-21 15:18 By: tmick Comment: Tim, could you verify my thread_pthread.h change and then pass this off to some Unix-weenie, as you say, to check the Autoconf changes. Thanks ------------------------------------------------------- Date: 2000-Aug-21 15:34 By: gvanrossum Comment: Hm. is it a good idea to check in this many changes for a compiler that's in beta test? I bet that by the time the Monterey64 compiler is out of beta half of these hacks are no longer necessary. And how many other people are in a position to need these changes? [Not rejecting, just reflecting...] ------------------------------------------------------- Date: 2000-Aug-21 16:52 By: tmick Comment: Well IMO: - The thread_pthread.h fix (and SIZEOF_PTHREAD_T) is an actual fix not a hack (there was some agreement between Fredrik, Tim and I on it) - The CC, CCSHARED, LINKCC, and LDSHARED are as per the (limited) Monterey compiler doc. I have no reason to believe that these will change post-Monterey-beta. - The only things that could be considered hacks are the RANLIB=: and OPT= settings. My p.o.v. is that by the time Monterey comes out of beta I may not be working on this and I would rather the information for compiling Python on Monterey successfully be out in the community rather than privately held (and forgotten) on my hard drive. ------------------------------------------------------- Date: 2000-Aug-21 23:57 By: tim_one Comment: Jeremy made the mistake of revealing he was back from vacation, so reassigned to him. HAHAHA! The "interim release manager" gets some revenge. Jeremy, please eyeball the config stuff and check whether it breaks Linux. Trent and Guido, I agree with Trent that the get_ident change is fine, whether or not Monterey ever gets used. And so long as Monterey changes don't propagate thru the rest of the codebase, there's no harm here either. The only downside is cluttering up the config stuff with Yet Another flavor of Unix(tm), but that has an upside too (at least if Monterey *does* ever get used! it's a head start). ------------------------------------------------------- Date: 2000-Aug-23 16:17 By: jhylton Comment: Looks fine to me; has no adverse effects on Linux build. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101249&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:26:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:26:34 -0700 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <200008231626.JAA26140@delerium.i.sourceforge.net> Patch #100938 has been updated. Project: Category: None Status: Postponed Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2000-Jul-19 21:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 17:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-16 07:40 By: moshez Comment: I suggest we postpone it. It isn't really complete (only works on real distributions ), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ------------------------------------------------------- Date: 2000-Aug-23 16:26 By: jhylton Comment: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:31:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:31:05 -0700 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <200008231631.JAA26246@delerium.i.sourceforge.net> Patch #101137 has been updated. Project: Category: Modules Status: Open Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2000-Aug-09 21:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 22:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway . ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:33:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:33:27 -0700 Subject: [Patches] [Patch #100852] Add poll() to select module Message-ID: <200008231633.JAA26376@delerium.i.sourceforge.net> Patch #100852 has been updated. Project: Category: Modules Status: Open Summary: Add poll() to select module Follow-Ups: Date: 2000-Jul-11 11:25 By: akuchling Comment: Derived from Sam Rushing's pollmodule.c that forms part of Medusa. Once I get a second opinion about the patch, I'll check it in. ------------------------------------------------------- Date: 2000-Jul-21 13:33 By: akuchling Comment: Updated version of the patch, which adds poll() to the select module. .register() and .unregister() add/remove fds, and .poll() performs the system call. Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored. Open question: should there be a function or attribute to get the list of registered fds? Still to do: write documentation, add the test case. ------------------------------------------------------- Date: 2000-Jul-25 00:54 By: akuchling Comment: Assigned to Jeremy for review; feel free to bounce it to someone else. ------------------------------------------------------- Date: 2000-Jul-25 17:25 By: akuchling Comment: Update patch to latest version, which adds poll() to the select() module. ------------------------------------------------------- Date: 2000-Jul-25 20:30 By: jhylton Comment: Several style nits changed, mostly to do with whitespace. Substantive changes: 1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens 2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND One more Open Issue: I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions: - interface to register many fds at once - keep the list of fds in sorted order - use a dict to store fds and generate fdarry lazily - keep track of allocated length and used length for ufds, so that fewer reallocs are required Each of these suggestions has some added complexity, so I'm not sure that I like any of them. ------------------------------------------------------- Date: 2000-Jul-25 20:41 By: akuchling Comment: I wondered about the linear search, too; it means balancing efficiency versus the lines of code to write this one object? IMHO implementing both #1 and #3 would be good; allow passing an arbitrary # of fds to register (and unregister?), store them in a dict, and then lazily generate the ufd array when needed. Or is there some built-in more suited than a dict for this? Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors. ------------------------------------------------------- Date: 2000-Jul-25 21:40 By: jhylton Comment: I think a dict is the right data structure, but I don't think it should be exposed directly. If it is not exposed, then the ufd array need only be generated for poll calls after a register or unregister. If there are multiple polls without a change, the same array can be re-used. ------------------------------------------------------- Date: 2000-Aug-13 04:13 By: akuchling Comment: Latest version, which stores an underlying dict as suggested in jhylton's previous comment. p.unregister() raises KeyError if you unregister a fd that wasn't registered in the first place; seem reasonable? It does to me... The code should now be completed; the only remaining task is to write docstrings and finish the documentation patch. ------------------------------------------------------- Date: 2000-Aug-15 17:36 By: tim_one Comment: Tickling you as part of 2.0 nagging. Please leave a note saying when you intend to "write docstrings and finish the documentation". ------------------------------------------------------- Date: 2000-Aug-16 00:57 By: akuchling Comment: Revised version -- documentation & docstrings completed, and there's a test script (not part of patch). Ready to check in once someone gives the patch a quick once-over and sanity check. ------------------------------------------------------- Date: 2000-Aug-16 02:38 By: tim_one Comment: Assigned to Barry for a quick once-over and sanity check, as he's looking at the socket code and "select" also begins with an "s", while the "p" in "poll" doesn't show up in "Cravin' Dogs" at all! A natural fit. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:38:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:38:07 -0700 Subject: [Patches] [Patch #101121] cosmetic cleanup of cgi.py, using Guido's style conventions Message-ID: <200008231638.JAA26555@delerium.i.sourceforge.net> Patch #101121 has been updated. Project: Category: library Status: Accepted Summary: cosmetic cleanup of cgi.py, using Guido's style conventions Follow-Ups: Date: 2000-Aug-08 20:37 By: ping Comment: This is an immediate follow-on to #101120 (i just wanted to keep the semantic and non-semantic changes separate). ------------------------------------------------------- Date: 2000-Aug-15 22:06 By: tim_one Comment: I'm not sure what you mean by "follow-on". If this patch is *independent* of 101120, just Accept it yourself and check it in -- there's no need to go thru a review process for mechanical cleanup. Assigning to you on that basis. Ah, and you *can* check it in, in about 6 hours: you've been added to the Python project as a Developer. That means I get to assign patches to you for review, too From noreply@sourceforge.net Wed Aug 23 17:35:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:35:59 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008231635.JAA26430@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 20:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 21:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-16 06:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-16 06:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 07:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 09:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 09:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-22 01:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- Date: 2000-Aug-22 04:41 By: moshez Comment: Actually, it's now waiting for someone's pronouncement -- Guido had a problem with .get() and __getitem__ not being equivalent (the first does an implicit .value). Ping and I thought it best that way, but if the BDFL has strong feelings otherwise, he should pronounce. Assigned to him for final verdict. ------------------------------------------------------- Date: 2000-Aug-22 20:46 By: ping Comment: On Fri, 18 Aug 2000, Guido van Rossum wrote: > If I understand the discussion below correctly, to get the > value for 'foo' you must use > > x['foo'].value > > but now you can also use > > x.get('foo') This is true. > ??? That's inconsistent compared to how these two behave for regular > dictionaries! I mulled this over a while when doing the patch. Initially, i did make form.get(x) behave exactly like form[x], and proceeded to try to make the FieldStorage object behave as much like a dictionary as possible (since the docs say it can be "accessed like a dictionary"). FormContentDict and its descendants clearly behave like a dictionary since they are derived from UserDict. But as i investigated FieldStorage further, i found that it actually lacks lots of dictionary behaviour: no update(), no clear(), no copy(), no items(), no values(). The only dictionary-like semantics we really care about are [key], keys(), and has_key(). Implementing items() and values() would require an uncertain choice, since the FieldStorage represents a multimap: do multi-valued fields appear as multiple key-value pairs with the same key, or a single pair with a list for its value? In the end, i decided to abandon true dictionary-like behaviour, because the thing being represented is a bit too much more than a dictionary. By far the most common use of the FieldStorage (and even the entire cgi module) is just to decode simple strings from single-valued form fields, and the interface should do its best to facilitate that common use. I decided it was okay to break consistency with regular dictionaries (a) as long as the behaviour is clearly documented and (b) since it doesn't fully satisfy one's expectations of a dictionary anyway. Moshe's response drove home the point when he demonstrated that the advantage of get() -- to provide a default when a value is missing -- is overwhelmed by the awkwardness of the .value interface. If get() returns a MiniFieldStorage, then to default the "spam" field to "eggs" i have to say field = form.get("spam", "eggs") if type(field) is type(""): process(field) else: process(field.value) or field = form.get("spam", None) if field is None: process("eggs") else: process(field.value) or field = form.get("spam", cgi.MiniFieldStorage("spam", "eggs")) process(field.value) which are hardly any better than if form.has_key("spam"): process(form["spam"].value) else: process("eggs") at all! If get() returns a string, then i can just say process(form.get("spam", "eggs")) and i can be on my way. I have personally stayed away from FieldStorage because it's so annoying to use; having to look up the "value" attribute on every form field makes programs verbose and awkward. This gets worse when a field has multple values. In fact, the usage example provided in Doc/lib/libcgi.tex is a perfect demonstration: username = form["username"] if type(username) is type([]): usernames = "" for item in username: if username: usernames = usernames + "," + item.value else: usernames = item.value else: usernames = username.value The above can be shortened somewhat with map(), but with the new get() method, this can simply be written in the obvious way: value = form.get("username", "") if type(value) is type([]): usernames = ",".join(value) else: usernames = value (The latter is what you would do with a FormContentDict, which is why i find it so vastly more convenient than the FieldStorage. It's slightly better, though: it also painlessly handles the case where the "username" field is not present.) As mentioned earlier, i'm more concerned about the default setting for keep_blank_values. The message i wrote providing a complete explanation of this issue is included below so you don't have to search through old e-mail to find it. -- ?!ng -------- the headers of the original message -------- >From ping@lfw.org Tue Aug 22 12:18:57 2000 Date: Wed, 16 Aug 2000 02:31:48 -0700 (PDT) From: Ka-Ping Yee To: Moshe Zadka , bwarsaw@beopen.com, tpeters@beopen.com Subject: Re: [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict -------- the message body, with some edits -------- Hi, guys. This patch includes a "fix" to make cgi.parse_qsl honour its "keep_blank_values" argument. This fix might require a bit more discussion since it could break compatibility, so i thought i would air it for your consideration. BACKGROUND ---------- cgi.FieldStorage(), cgi.parse(), cgi.parse_qs(), and cgi.parse_qsl() all accept an optional "keep_blank_values" argument which is supposed to indicate whether form fields with empty strings as values should be included in the result. In reality, only cgi.parse_qs() honours this flag (cgi.parse() is okay because it uses cgi.parse_qs()). cgi.parse_qsl() totally ignores it, and always includes all values including empty ones. cgi.FieldStorage(), which uses cgi.parse_qsl(), similarly does not honour the "keep_blank_values" flag. The patch contains a fix to make cgi.parse_qsl() honour this flag. FOR --- It's clear that this was the intent of the "keep_blank_values" argument. The doc string for parse_qsl says: """Parse a query given as a string argument. Arguments: qs: URL-encoded query string to be parsed keep_blank_values: flag indicating whether blank values in URL encoded queries should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. Returns a list, as God intended. """ Its current disregard for "keep_blank_values" clearly contradicts this doc string. The doc string for FieldStorage.__init__ says: """Constructor. Read multipart/* until last part. Arguments, all optional: fp : file pointer; default: sys.stdin (not used when the request method is GET) headers : header dictionary-like object; default: taken from environ as per CGI spec outerboundary : terminating multipart boundary (for internal use only) environ : environment dictionary; default: os.environ keep_blank_values: flag indicating whether blank values in URL encoded forms should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. """ ...and the current behaviour of FieldStorage.__init__ contradicts what it says here about "keep_blank_values". AGAINST ------- Existing code which uses FieldStorage and relies on its current behaviour could break. If a form field is left blank by the user and the form is submitted, that key will not appear in the FieldStorage -- and an attempt to index it with form[key] will produce a KeyError where previously it yielded a MiniFieldStorage containing an empty string. The existing TeX documentation for the cgi module does not mention empty values or the keep_blank_values argument at all, so to those who have only read the library reference manual, this could be a surprise. OPTIONS ------- The reason this never showed up before is that there have never been *any* tests for FieldStorage in test_cgi.py! Naughty, naughty. One easy way to maintain compatibility is to change FieldStorage so that the default value for keep_blank_values is 1 (previously this was 0 but the FieldStorage *acted* as though it were 1). ------------------------------------------------------- Date: 2000-Aug-23 16:35 By: jhylton Comment: Since we are in feature freeze, let's not worry about whether we should have a get method or not. Please limit this patch to bug fixes and re-submit. I'll be happy to accept. Let's do a more thorough job of revising this module for 2.1. It looks amazingly complicated to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:54:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:54:11 -0700 Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test Message-ID: <200008231654.JAA27152@delerium.i.sourceforge.net> Patch #101257 has been updated. Project: Category: library Status: Open Summary: Update test cases for posixpath, ntpath, add dospath test Follow-Ups: Date: 2000-Aug-22 10:59 By: montanaro Comment: assigned to fred since it contains a (minor) doc change. ;-) Fred - it probably should go to Tim or Guido next. Note that ntpath and dospath are not documented if someone wants to take the time... ------------------------------------------------------- Date: 2000-Aug-23 11:54 By: jhylton Comment: Tim-- Can you check the validity of the dospath code? ------------------------------------------------------- Date: 2000-Aug-23 12:40 By: tim_one Comment: Actually not! I've never used DOS (DOS != Windows of any flavor), and "we" don't even build a DOS Python (I'm not sure anyone does anymore). By *eyeballing* the dospath tests, though, they certainly *ought* to work as advertised. Assigned back to Fred, since it was assigned to him before me, and it doesn't look like he got to his part yet. After that, just check it in! The std posixpath test is failing now for lack of this (I believe). ------------------------------------------------------- Date: 2000-Aug-23 12:52 By: fdrake Comment: Check it in. ------------------------------------------------------- Date: 2000-Aug-23 12:54 By: montanaro Comment: On the assumption that Tim's eyeballs are "good enough", I'm checking in test_posixpath.py, test_ntpath.py and test_dospath.py. Fred, all that's left for you to do is pronounce on the niggling little doc change. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101257&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:58:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:58:07 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008231658.JAA27329@delerium.i.sourceforge.net> Patch #101211 has been updated. Project: Category: None Status: Accepted Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 15:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- Date: 2000-Aug-21 20:03 By: tim_one Comment: Skip, did you and/or Ping track down the problem you thought there might be with this? Or am I misremembering email? (Ironic note: we moved to the SF patch manager so discussions wouldn't get lost!) ------------------------------------------------------- Date: 2000-Aug-21 21:14 By: montanaro Comment: Yes, Ping found and fixed the problem. The patch that I submitted should do the right thing. I'm reassigning it to Guido for his pronouncement. I believe it's ready to go. (I am still pretty unclear on the sequence of events that are required to take a patch from idea to cvs checkin...) ------------------------------------------------------- Date: 2000-Aug-21 21:24 By: gvanrossum Comment: Thanks! To both of you. Also for the doc additions. Skip, please check it in and then set the status to Closed. When you submit a patch (or update one), it's best to leave it unassigned or assign it to the release manager (today still Tim, after tomorrow Jeremy). If it *needs* BDFL pronouncement, the release manager will assign it to me with appropriate comments. Note: the patch part for graminit.c failed -- you may want to run pgen again before you check it in. ------------------------------------------------------- Date: 2000-Aug-21 21:29 By: tim_one Comment: Thanks, Skip! Have you read http://python.sourceforge.net/sf-faq.html#a1 ? If there's something about the patch process that wasn't answered there, let me know. I must say that, from my POV as "interim release manager" the past couple weeks, few people are playing along with the intent -- it's like nothing *moves* unless I step in to kick, prod or harass. You assigning this to the person *you* believe should take the next step is exactly how it's supposed to work. Thanks for taking the initiative! ------------------------------------------------------- Date: 2000-Aug-21 21:37 By: tim_one Comment: Assigned back to Skip since Guido Pronounced. Please feel free to check it in and Close it after addressing his comments. ------------------------------------------------------- Date: 2000-Aug-21 21:39 By: tim_one Comment: AHA! A SourceForge insecurity: I'm deducing from the log that Guido changed the status to Accepted when he wrote his last comment, but I was writing a comment at the same time but without changing the status, and a submitted after he did. So ended up undoing his status change without knowing it! Changed Status back to Accepted. ------------------------------------------------------- Date: 2000-Aug-21 22:52 By: montanaro Comment: changes have been checked in. Lib/test/test_parser.py breaks, but I forwarded a context diff to Fred Drake, who's been working on that module. ------------------------------------------------------- Date: 2000-Aug-21 23:03 By: montanaro Comment: forgot to reassign to Fred for documentation checks... ------------------------------------------------------- Date: 2000-Aug-23 12:58 By: fdrake Comment: The parser module has been with a different patch, so test_parser passes once again. The first hunk of the ref5.tex patch maintains the existing use of double quotes to mark keywords ("if"); this should be changed to use \keyword (\keyword{if}). Please make this change and check it in without another round of review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:59:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:59:33 -0700 Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test Message-ID: <200008231659.JAA27362@delerium.i.sourceforge.net> Patch #101257 has been updated. Project: Category: library Status: Closed Summary: Update test cases for posixpath, ntpath, add dospath test Follow-Ups: Date: 2000-Aug-22 10:59 By: montanaro Comment: assigned to fred since it contains a (minor) doc change. ;-) Fred - it probably should go to Tim or Guido next. Note that ntpath and dospath are not documented if someone wants to take the time... ------------------------------------------------------- Date: 2000-Aug-23 11:54 By: jhylton Comment: Tim-- Can you check the validity of the dospath code? ------------------------------------------------------- Date: 2000-Aug-23 12:40 By: tim_one Comment: Actually not! I've never used DOS (DOS != Windows of any flavor), and "we" don't even build a DOS Python (I'm not sure anyone does anymore). By *eyeballing* the dospath tests, though, they certainly *ought* to work as advertised. Assigned back to Fred, since it was assigned to him before me, and it doesn't look like he got to his part yet. After that, just check it in! The std posixpath test is failing now for lack of this (I believe). ------------------------------------------------------- Date: 2000-Aug-23 12:52 By: fdrake Comment: Check it in. ------------------------------------------------------- Date: 2000-Aug-23 12:54 By: montanaro Comment: On the assumption that Tim's eyeballs are "good enough", I'm checking in test_posixpath.py, test_ntpath.py and test_dospath.py. Fred, all that's left for you to do is pronounce on the niggling little doc change. ------------------------------------------------------- Date: 2000-Aug-23 12:59 By: montanaro Comment: okay - it's all checked in. my apologies for the furor this caused... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101257&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:00:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:00:11 -0700 Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test Message-ID: <200008231700.KAA27386@delerium.i.sourceforge.net> Patch #101257 has been updated. Project: Category: library Status: Accepted Summary: Update test cases for posixpath, ntpath, add dospath test Follow-Ups: Date: 2000-Aug-22 10:59 By: montanaro Comment: assigned to fred since it contains a (minor) doc change. ;-) Fred - it probably should go to Tim or Guido next. Note that ntpath and dospath are not documented if someone wants to take the time... ------------------------------------------------------- Date: 2000-Aug-23 11:54 By: jhylton Comment: Tim-- Can you check the validity of the dospath code? ------------------------------------------------------- Date: 2000-Aug-23 12:40 By: tim_one Comment: Actually not! I've never used DOS (DOS != Windows of any flavor), and "we" don't even build a DOS Python (I'm not sure anyone does anymore). By *eyeballing* the dospath tests, though, they certainly *ought* to work as advertised. Assigned back to Fred, since it was assigned to him before me, and it doesn't look like he got to his part yet. After that, just check it in! The std posixpath test is failing now for lack of this (I believe). ------------------------------------------------------- Date: 2000-Aug-23 12:52 By: fdrake Comment: Check it in. ------------------------------------------------------- Date: 2000-Aug-23 12:54 By: montanaro Comment: On the assumption that Tim's eyeballs are "good enough", I'm checking in test_posixpath.py, test_ntpath.py and test_dospath.py. Fred, all that's left for you to do is pronounce on the niggling little doc change. ------------------------------------------------------- Date: 2000-Aug-23 12:59 By: montanaro Comment: okay - it's all checked in. my apologies for the furor this caused... ------------------------------------------------------- Date: 2000-Aug-23 13:00 By: fdrake Comment: I just did; we must have been updating this at the same time. Go ahead and check in the documentation changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101257&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:40:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:40:08 -0700 Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test Message-ID: <200008231640.JAA26607@delerium.i.sourceforge.net> Patch #101257 has been updated. Project: Category: library Status: Open Summary: Update test cases for posixpath, ntpath, add dospath test Follow-Ups: Date: 2000-Aug-22 10:59 By: montanaro Comment: assigned to fred since it contains a (minor) doc change. ;-) Fred - it probably should go to Tim or Guido next. Note that ntpath and dospath are not documented if someone wants to take the time... ------------------------------------------------------- Date: 2000-Aug-23 11:54 By: jhylton Comment: Tim-- Can you check the validity of the dospath code? ------------------------------------------------------- Date: 2000-Aug-23 12:40 By: tim_one Comment: Actually not! I've never used DOS (DOS != Windows of any flavor), and "we" don't even build a DOS Python (I'm not sure anyone does anymore). By *eyeballing* the dospath tests, though, they certainly *ought* to work as advertised. Assigned back to Fred, since it was assigned to him before me, and it doesn't look like he got to his part yet. After that, just check it in! The std posixpath test is failing now for lack of this (I believe). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101257&group_id=5470 From noreply@sourceforge.net Wed Aug 23 17:52:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 09:52:11 -0700 Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test Message-ID: <200008231652.JAA27102@delerium.i.sourceforge.net> Patch #101257 has been updated. Project: Category: library Status: Accepted Summary: Update test cases for posixpath, ntpath, add dospath test Follow-Ups: Date: 2000-Aug-22 10:59 By: montanaro Comment: assigned to fred since it contains a (minor) doc change. ;-) Fred - it probably should go to Tim or Guido next. Note that ntpath and dospath are not documented if someone wants to take the time... ------------------------------------------------------- Date: 2000-Aug-23 11:54 By: jhylton Comment: Tim-- Can you check the validity of the dospath code? ------------------------------------------------------- Date: 2000-Aug-23 12:40 By: tim_one Comment: Actually not! I've never used DOS (DOS != Windows of any flavor), and "we" don't even build a DOS Python (I'm not sure anyone does anymore). By *eyeballing* the dospath tests, though, they certainly *ought* to work as advertised. Assigned back to Fred, since it was assigned to him before me, and it doesn't look like he got to his part yet. After that, just check it in! The std posixpath test is failing now for lack of this (I believe). ------------------------------------------------------- Date: 2000-Aug-23 12:52 By: fdrake Comment: Check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101257&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:32:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:32:52 -0700 Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display Message-ID: <200008231732.KAA06387@bush.i.sourceforge.net> Patch #100947 has been updated. Project: Category: library Status: Open Summary: increase control and default size of pdb traceback display Follow-Ups: Date: 2000-Aug-14 03:15 By: nowonder Comment: There is a detailed description in the patch. ------------------------------------------------------- Date: 2000-Aug-15 17:55 By: tim_one Comment: Reassigned to Guido in Jeremy's absence, cuz I never use pdb but know Guido has at least once . Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 19:36 By: gvanrossum Comment: I like the idea fine, but the command name "scaletb" sucks. Once a better name is coined Ken should get checkin permissions if he doesn't already have them, so he can check it in. (Isn't it ironic that Ken, who enjoys naming debates so much, came up with a sucky name? :-) Possibly a better name could include "control" (or an abbreviation) instead of "scale"? ------------------------------------------------------- Date: 2000-Aug-21 23:59 By: tim_one Comment: Ken, are you going to repsond to Guido's comments? And do you want developer privileges? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470 From noreply@sourceforge.net Wed Aug 23 19:39:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 11:39:52 -0700 Subject: [Patches] [Patch #100899] a smaller unicode name database Message-ID: <200008231839.LAA31418@delerium.i.sourceforge.net> Patch #100899 has been updated. Project: Category: None Status: Open Summary: a smaller unicode name database Follow-Ups: Date: 2000-Jul-15 18:43 By: effbot Comment: duh. it's too large for sourceforge. if you want to play with it, get it from: http://w1.132.telia.com/~u13208596/uninames-patch.txt ------------------------------------------------------- Date: 2000-Aug-03 14:59 By: lemburg Comment: How is the work on this patch coming along ? Will it be ready for 2.0 ? ------------------------------------------------------- Date: 2000-Aug-15 13:42 By: tim_one Comment: /F or MAL, what's going on with this? MAL, did you look at the patch? /F, do you feel it's done? ------------------------------------------------------- Date: 2000-Aug-23 14:39 By: tim_one Comment: Assigned back to /F because he agrees the ball bounced back into his court: [/F, in Python-Dev mail] mal has reviewed the patch, and is waiting for an update from me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100899&group_id=5470 From noreply@sourceforge.net Thu Aug 24 01:38:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 17:38:39 -0700 Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Message-ID: <200008240038.RAA21971@bush.i.sourceforge.net> Patch #100893 has been updated. Project: Category: core (C code) Status: Closed Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Follow-Ups: Date: 2000-Jul-15 08:24 By: twouters Comment: Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run. ------------------------------------------------------- Date: 2000-Jul-15 21:32 By: cgw Comment: I don't think it's really true that the cost of this patch is high. I did timing tests, on 3 different machines; my (admittedly somewhat unscientific) test was to run "python pystone.py" 100x and collect statistics on the results, for both the original and patched Python interpreters. Values cited are PyStones. Here are the results: ============================================= On an SGI IRIX64 6.5 IP27 built with native compiler MIPSpro Compilers: Version 7.2.1 Unpatched: N=100 mean=2638.05 std. dev.=42.8 Patched: N=100 mean=2656.19 std. dev.=14.8 Difference: +0.7% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=2171.77 std. dev.=8.69 Patched: N=100 mean=2192.73 std. dev.=9.80 Difference: +1% ============================================= On a SunOS 5.6 sun4u sparc Ultra-Enterprise built with native compiler WorkShop Compilers 4.2 Unpatched: N=100 mean=1962.32 std dev=29.79 Patched: N=100 mean=1913.84 std dev=8.705 Difference: -2.5% built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=1859.08 std dev=11.68 Patched: N=100 mean=1939.78 std dev=11.97 Difference: +4.3% ============================================= On Linux 2.2.16 SMP built with gcc version 2.95.2 19991024 (release) Unpatched: N=100 mean=4498.78 std dev=102.61 Patched: N=100 mean=4592.40 std dev=102.38 Difference: +2% I think that looking ahead in the instruction stream is not costly because the bytecode at instruction n+2 is probably already in the CPU's level 1 or level 2 cache; if not, "prefetching" this instruction does not have any adverse affects on performace, because then this instruction will be available when it is needed (which will usually be almost immediately). In many cases, actually, the code with my patch runs a bit faster. I've also reduced the amount of arithmetic required in the case of little-endian machines - rather than bit-shifting and adding to get a short out of two bytes, I simply use a pointer-cast. Anyhow, try the patch out, I think the speed difference is negligible. To answer your other points - yes, I think the 32K limit is a problem - I've seen cases where machine-generated files are longer than this. And I'm not too happy with the idea of replacing a 32K limit with a 64K limit. Finally, I don't see where I'm assuming that ints are always 32 bit - I assume that a long is at least 32 bits, but unless I'm missing something this code will work just fine on 64-bit machines. Feedback is of course always welcome.... ------------------------------------------------------- Date: 2000-Jul-16 05:16 By: twouters Comment: I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;) The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode. I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON. ------------------------------------------------------- Date: 2000-Jul-16 19:16 By: cgw Comment: It looks like I took out all the overflow checking, but in fact the code is safe. com_addbyte in compile.c checks that its (int) argument is in the range 0<=x<=255. The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is available. ------------------------------------------------------- Date: 2000-Jul-27 10:18 By: gvanrossum Comment: This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline, and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable). Pseudo-code: label: switch (opcode) { case LONG_ARG realopcode = NEXTOP(); oparg = oparg<<16 | NEXTARG(); goto label; ...other cases as before... } Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like: LONG_ARG ------------------------------------------------------- Date: 2000-Jul-28 01:50 By: tim_one Comment: Sorry, guys -- there was so much email today that I didn't even see this until now. Yes, I saw the timing results, and wasn't surprised. As the one one-time professional optimization guy hanging out on c.l.py, I get sucked into these things a lot. Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down. And ceval.c pushes current combos to their limits: Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result. On my combo, it appeared to yield a slight speedup. That doesn't mean it's hopeless, though! Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform. Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose. That's my real objection to the original patch: instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos. Optimizers get better over time, and architectures reward simpler code over time. Greg Ewing had another interesting suggestion on c.l.py today: don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte. The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf). BTW, you cannot assume that a short is 2 bytes! Python runs on machines where sizeof(short) == 8. ------------------------------------------------------- Date: 2000-Aug-02 17:57 By: cgw Comment: Here's a completely reworked version of the EXTENDED_ARG patch which inserts the EXTENDED_ARG bytecode before the opcode it modifies, rather than after it. This avoids adding extra glop to the critical section of instruction decoding. ------------------------------------------------------- Date: 2000-Aug-09 01:26 By: tim_one Comment: Changed status to Rejected, but left assigned to me (I'll Open it again when it's updated). As I said at the bottom of my last comment on this, you cannot assume sizeof(short)==2: please get rid of the new big-endian/little-endian trickery. The code is not portable as-is. Even on machines where sizeof(short) does equal 2, shorts in the opcode stream are not guaranteed to be naturally aligned, and trying to access them as if they were can lead to anything from a core dump to an expensive trap to the OS to fix up the unaligned read. And on the only machines where this gimmick could actually pay (a little-endian machine where sizeof(short)==2 *and* the HW doesn't penalize unnatural alignment), the compiler should be smart enough to optimize the old expression for us. ------------------------------------------------------- Date: 2000-Aug-09 07:36 By: gvanrossum Comment: I think that all Tim wants is that you undo the changes you made to the NEXTARG() macro. ------------------------------------------------------- Date: 2000-Aug-10 17:51 By: cgw Comment: Understood. I've now put the NEXTARG macro back to its original form; sorry for overlooking this on the previous pass. ------------------------------------------------------- Date: 2000-Aug-11 00:25 By: tim_one Comment: Changed to Open and assigned to Vladimir. Vlad, have any comments on this? Care to test it? I'm inclined to accept it now "by eyeball", because it does fix some bugs. ------------------------------------------------------- Date: 2000-Aug-12 12:54 By: marangoz Comment: Yes, comments: there are things I like and others I don't really like. The tactics here is to remove the 2-byte integral type limit and replace it with sizeof(int). On some systems, sizeof(int) == 8, so I don't see a reason for generating only one EXTENDED_ARG opcode if the arg exceeds 2 bytes. If the arg exceeds 4 bytes, let the code generate more 2-byte arg slices, i.e. several EXTENDED_ARG in a row. Costs nothing. Overall, we both converged on the same solution. Things I like: - the fix in node.h (short -> int) - the error check in com_backpatch Things I don't really like: - the removal of E_OVERFLOW and associated checks I'd suggest using int types in node.h (instead of unsigned int) and change the existing short checks with int checks (with INT_MAX) - the label "extended_arg" in ceval.c. (after the oparg fetch) It should be really be named "dispatch_opcode". I'd suggest integrating the com_oparg & ceval's case EXTENDED_ARG code that I've posted to python-dev and adjust the rest accordingly. http://www.python.org/pipermail/python-dev/2000-August/014604.html Overall, it looks okay. I'll test it when the things I don't really like are gone. (the Python code seems to be somewhat more complex than it should be, though...) Can we get another patch from the author? Otherwise I'll try to make some time to relay this. ------------------------------------------------------- Date: 2000-Aug-15 13:29 By: tim_one Comment: Charles, do you have anything to say to Vladimir's comments? I don't see a need to have an indefinitely-extensible extended opcode gimmick today. What you already did solves real problems now, and indeed the only real problems in this area we've ever seen. I want to get that into 2.0. That doesn't preclude Vlad extending it again later. But I agree that removing the overflow checks was a bad decision. If we ever *do* bump into a case where more than what you've done is needed, Python will silently go insane. So if you can fix that much, I'll accept the patch for 2.0 immediately after. Agree too that "dispatch_opcode" is a clearer name for the label than "extended_arg". ------------------------------------------------------- Date: 2000-Aug-15 16:45 By: cgw Comment: You know, I've been fooling around with this silly little patch for quite a while. And about 3 months ago I had developed a version where you could stack up the EXTENDED_ARG opcodes, and also where I had dealt with the "offset too big" problem in com_backpatch by inserting some EXTENDED_ARGS and then relocating the subsequent code, by walking through and fixing up offsets. It worked, but it was rather hairy and slow and I convinced myself that such a patch would simply *never*get accepted. So I simplified it down as much as possible to solve the actual problem that we were having here at FNAL. I didn't really decide to take out the overflow checks, it's just that my patch pre-dated their addition. I'm uploading a new version which restores the overflow checks and renames the label as per your wishes. ------------------------------------------------------- Date: 2000-Aug-15 22:49 By: tim_one Comment: Accepted and assigned to Fred Drake for checkin. Sorry again, Fred! I'll get a patch that works one of these days (the Cygwin stuff works fine, but I can't afford the download time!). And, Charles, thank you for patience and good humor during this long ordeal. It's appreciated! ------------------------------------------------------- Date: 2000-Aug-21 21:49 By: tim_one Comment: Yo! Fred! Please check this in or assign to someone else. ------------------------------------------------------- Date: 2000-Aug-22 02:06 By: fdrake Comment: Accepted, but no builds cleanly -- causes pgen to core dump! Perhaps there are conflicts with some of the other changes? Here's the error: cd Grammar ; make OPT="-g -O2" VERSION="2.0" \ prefix="/usr/local" exec_prefix="/usr/local" all ../Parser/pgen ../../Grammar/Grammar make[1]: *** [graminit.h] Segmentation fault make: *** [Grammar] Error 2 Charles, please update the patch and I'll apply it. ------------------------------------------------------- Date: 2000-Aug-23 10:02 By: cgw Comment: I think all that's needed is a "make clean" - as far as I can tell, the dependencies on files like node.h and opcode.h aren't spelled out in the Makefiles. I think I see what's going on here. If you never do a "make depend" then the .h dependencies never get incorporated into the Makefiles. The normal "./configure; make" sequence doesn't seem to run "make depend", and so most people probably don't ever do this, since it's not in the build instructions anywhere. If you still can't get this to compile after "make clean depend" give me a holler and I'll investigate. ------------------------------------------------------- Date: 2000-Aug-23 12:06 By: fdrake Comment: Reopened after making sure I did a clean before building. This patch seems mostly fine, but needs to address test_longexp, which suddenly no longer needs to expect a SyntaxError for the long expression. This should only be a matter of regenerating the output; if this is the expected behavior, just note it in a comment here rather than changing the patch, and I can regenerate before checking it in. Thanks for all the work on this! ------------------------------------------------------- Date: 2000-Aug-23 16:32 By: cgw Comment: I would suggest replacing text_longexp.py with the following: REPS = 65580 l = eval("[" + "2," * REPS + "]") print len(l) and regenerating the output (it should of course print 65580). Also here's a little documentation patch: *** libdis.tex 2000/08/11 22:15:52 1.20 --- libdis.tex 2000/08/23 20:31:07 *************** *** 513,515 **** --- 513,523 ---- \code{slice(TOS2, TOS1, TOS)} is pushed. See the \code{slice()}\bifuncindex{slice} built-in function. \end{opcodedesc} + + \begin{opcodedesc}{EXTENDED_ARG}{ext} + Prefixes any opcode which has an argument too big to fit into the + default two bytes. \var{ext} holds two additional bytes which taken + together with the subsequent opcode's argument comprise a four-byte + argument, \var {ext} being the two most-significant bytes. + \end {opcodedesc} + ------------------------------------------------------- Date: 2000-Aug-23 20:38 By: fdrake Comment: Thanks! This is now checked in, including the regression test and documentation updates. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470 From noreply@sourceforge.net Thu Aug 24 01:47:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 17:47:53 -0700 Subject: [Patches] [Patch #101257] Update test cases for posixpath, ntpath, add dospath test Message-ID: <200008240047.RAA22342@bush.i.sourceforge.net> Patch #101257 has been updated. Project: Category: library Status: Closed Summary: Update test cases for posixpath, ntpath, add dospath test Follow-Ups: Date: 2000-Aug-22 10:59 By: montanaro Comment: assigned to fred since it contains a (minor) doc change. ;-) Fred - it probably should go to Tim or Guido next. Note that ntpath and dospath are not documented if someone wants to take the time... ------------------------------------------------------- Date: 2000-Aug-23 11:54 By: jhylton Comment: Tim-- Can you check the validity of the dospath code? ------------------------------------------------------- Date: 2000-Aug-23 12:40 By: tim_one Comment: Actually not! I've never used DOS (DOS != Windows of any flavor), and "we" don't even build a DOS Python (I'm not sure anyone does anymore). By *eyeballing* the dospath tests, though, they certainly *ought* to work as advertised. Assigned back to Fred, since it was assigned to him before me, and it doesn't look like he got to his part yet. After that, just check it in! The std posixpath test is failing now for lack of this (I believe). ------------------------------------------------------- Date: 2000-Aug-23 12:52 By: fdrake Comment: Check it in. ------------------------------------------------------- Date: 2000-Aug-23 12:54 By: montanaro Comment: On the assumption that Tim's eyeballs are "good enough", I'm checking in test_posixpath.py, test_ntpath.py and test_dospath.py. Fred, all that's left for you to do is pronounce on the niggling little doc change. ------------------------------------------------------- Date: 2000-Aug-23 12:59 By: montanaro Comment: okay - it's all checked in. my apologies for the furor this caused... ------------------------------------------------------- Date: 2000-Aug-23 13:00 By: fdrake Comment: I just did; we must have been updating this at the same time. Go ahead and check in the documentation changes. ------------------------------------------------------- Date: 2000-Aug-23 20:47 By: fdrake Comment: This has been checked in, so I'm closing it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101257&group_id=5470 From noreply@sourceforge.net Thu Aug 24 01:53:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 17:53:21 -0700 Subject: [Patches] [Patch #101214] Improve exception message for PyErr_BadInternalCall() Message-ID: <200008240053.RAA22518@bush.i.sourceforge.net> Patch #101214 has been updated. Project: Category: core (C code) Status: Open Summary: Improve exception message for PyErr_BadInternalCall() Follow-Ups: Date: 2000-Aug-17 23:25 By: fdrake Comment: This patch uses a macro wrapper to provide the filename and line number of the call to PyErr_BadInternalCall(). This should be reasonable since the __FILE__ and __LINE__ macros are ANSI C (I think). There are 77 call sites for PyErr_BadInternalCall(), and this would make it a lot easier to get an initial foothold on errors generated through this function. ------------------------------------------------------- Date: 2000-Aug-18 07:15 By: marangoz Comment: OTOH, bad internal calls shouldn't happen, but I like this. You want to make my life easier as a developer, not as a user. +0, modulo the fact that you removed the original function from the API. External modules may fail. Let's keep the original function and its signature in the code. (this requires some preprocessor trickery). ------------------------------------------------------- Date: 2000-Aug-18 10:42 By: fdrake Comment: Add PyErr_BadInternalCall() entry point back for legacy compiled code, but continue to mask it for new code. ------------------------------------------------------- Date: 2000-Aug-19 13:13 By: marangoz Comment: Where's the legacy PyErr_BadInternalCall(void) *function* ? Try again :-) error.c: #undef PyErr_BadInternalCall void PyErr_BadInternalCall(void) { PyErr_SetString(PyExc_SystemError, "bad argument to internal function"); } void _PyErr_BadInternalCall(char *filename, int lineno) { PyErr_Format(PyExc_SystemError, "%s:%d: bad argument to internal function", filename, lineno); } ------------------------------------------------------- Date: 2000-Aug-19 13:37 By: fdrake Comment: Ok, here 'tis... forgot to regenerate the patch before uploading it last time. Sorry! ;-( ------------------------------------------------------- Date: 2000-Aug-20 00:24 By: tim_one Comment: Assigned to Vladimir since his is the natural next voice. ------------------------------------------------------- Date: 2000-Aug-23 20:53 By: fdrake Comment: Assigned to Jeremy since Vladimir is away travelling for a bit. Please review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101214&group_id=5470 From noreply@sourceforge.net Thu Aug 24 02:07:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 18:07:47 -0700 Subject: [Patches] [Patch #100837] urllib patch to simplify POST form query Message-ID: <200008240107.SAA23012@bush.i.sourceforge.net> Patch #100837 has been updated. Project: Category: library Status: Closed Summary: urllib patch to simplify POST form query Follow-Ups: Date: 2000-Jul-10 08:49 By: VizNut Comment: (SourceForce tossed my comment for the original patch, so here it is.) Current GET form query: filename, headers = urllib.urlretrieve( "%s?%s" % ( BASE_URL, urllib.urlencode( parms ) ), filename ) Desirable POST form query: filename, headers = urllib.urlretrieve( BASE_URL, filename, data=urllib.urlencode( parms ) ) Current POST form query: fp = urllib.urlopen( BASE_URL, urllib.urlencode( parms ) ) tfp = open(filename, 'wb') bs = 1024*8 block = fp.read(bs) while block: tfp.write(block) block = fp.read(bs) tfp.close() fp.close() The latter is required because there is no way to feed the data parameters for the POST query to urlretrieve. The chunked read is necessary because these forms sometimes generate datasets larger than virtual memory (as in this case). ------------------------------------------------------- Date: 2000-Jul-12 10:04 By: moshez Comment: This looks cool! I'm +1 on this. (I haven't tested this patch yet, so I'll need to. From a cursory glance at the implementation it looks quite straightforward) ------------------------------------------------------- Date: 2000-Aug-15 13:33 By: tim_one Comment: Reassigned to Fred because Jeremy's gone. Fred, know anything about this stuff? Review or assign to someone else, please. ------------------------------------------------------- Date: 2000-Aug-15 14:09 By: fdrake Comment: This patch requires documentation; please update to modify Doc/lib/liburllib.tex, or provide specific (unmarked) text in a comment. ------------------------------------------------------- Date: 2000-Aug-22 03:32 By: moshez Comment: Documentation updates summary: add the following paragraph (copied from urlopen's description) to urlretrieve's description: If the \var{url} uses the \file{http:} scheme identifier, the optional \var{data} argument may be given to specify a \code{POST} request (normally the request type is \code{GET}). The \var{data} argument must in standard \file{application/x-www-form-urlencoded} format; see the \function{urlencode()} function below. And add the same paragraph to URLopener's retrieve method. Additionally, of course, \optional{, data} should be added to the synopsis of these methods. ------------------------------------------------------- Date: 2000-Aug-23 21:07 By: fdrake Comment: Checked in both implementation and documentation portions; this is done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100837&group_id=5470 From noreply@sourceforge.net Thu Aug 24 03:12:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 19:12:40 -0700 Subject: [Patches] [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing Message-ID: <200008240212.TAA25221@bush.i.sourceforge.net> Patch #101272 has been updated. Project: Category: None Status: Open Summary: Allow bsddbmodule.c to compile with libdb 2.x w/o editing ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101272&group_id=5470 From noreply@sourceforge.net Thu Aug 24 03:20:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 19:20:31 -0700 Subject: [Patches] [Patch #101085] calendar.py extensions Message-ID: <200008240220.TAA25528@bush.i.sourceforge.net> Patch #101085 has been updated. Project: Category: Modules Status: Open Summary: calendar.py extensions Follow-Ups: Date: 2000-Aug-05 21:54 By: goodger Comment: (1) Allows any weekday to start a week, not just Monday as hardcoded. (2) Added functions which return week, month and year calendars as strings (e.g. prmonth() prints, month() returns string), so we aren't forced to play with stdout when we don't want to print. Had to modify some (manditory, therefore non-keyword) parameters in prweek(), prmonth() & prcal()'s signatures. (3) Removed "caching interface to _monthcalendar" as unnecessary complexity. ------------------------------------------------------- Date: 2000-Aug-15 15:05 By: tim_one Comment: Assigned to Skip because he's a Calendar kind of fellow. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 16:16 By: montanaro Comment: Looks reasonable with the following recommendations and questions: * the w (width) and l (length) keyword args to month and prmonth should probably be called something else (columnwidth and rowheight perhaps?). Should calendar/prcal have columnwidth, rowheight and gutterwidth optional arguments? * I think the month() function should include a trailing newline and that prmonth should call sys.stdout.write. Same for the calendar/prcal pair. * Should firstweekday accept string arguments as well so people don't have to map from days of the week to integers? What does this imply for locales? Can English just be assumed? ------------------------------------------------------- Date: 2000-Aug-17 16:21 By: montanaro Comment: Just occurred to me... Perhaps firstweekday() should reset to the default for the module (Monday) instead of the US convention (Sunday first). ------------------------------------------------------- Date: 2000-Aug-23 22:20 By: montanaro Comment: sent note to David asking about progress on an updated patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101085&group_id=5470 From noreply@sourceforge.net Thu Aug 24 03:21:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 19:21:07 -0700 Subject: [Patches] [Patch #101086] libcalendar.tex extensions (untested; don't have TeX) Message-ID: <200008240221.TAA25544@bush.i.sourceforge.net> Patch #101086 has been updated. Project: Category: documentation Status: Open Summary: libcalendar.tex extensions (untested; don't have TeX) Follow-Ups: Date: 2000-Aug-05 21:57 By: goodger Comment: I don't have TeX, and am not fluent, so I hacked the doc code. I haven't tested it and can't guarantee it is without error. I hope it doesn't cause you any trouble. Sorry! ------------------------------------------------------- Date: 2000-Aug-15 15:08 By: tim_one Comment: Assigned to Skip because it appears to be a companion to the calendar.py patch. Skip, if you like the latter patch, I guess this patch should get assigned to Fred next. ------------------------------------------------------- Date: 2000-Aug-17 16:19 By: montanaro Comment: Documentation of function signatures should match definition (e.g., w & l vs width & length) ------------------------------------------------------- Date: 2000-Aug-23 22:21 By: montanaro Comment: sent note to David asking about status of an updated patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101086&group_id=5470 From noreply@sourceforge.net Thu Aug 24 03:22:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 19:22:52 -0700 Subject: [Patches] [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing Message-ID: <200008240222.TAA25587@bush.i.sourceforge.net> Patch #101272 has been updated. Project: Category: Modules Status: Open Summary: Allow bsddbmodule.c to compile with libdb 2.x w/o editing Follow-Ups: Date: 2000-Aug-23 22:22 By: montanaro Comment: Eric's been doing lots w/ libdb stuff lately. I'll see if he want's to check this patch out... ;-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101272&group_id=5470 From esr@thyrsus.com Thu Aug 24 03:45:36 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 23 Aug 2000 22:45:36 -0400 Subject: [Patches] Re: [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing In-Reply-To: <200008240222.TAA25587@bush.i.sourceforge.net>; from noreply@sourceforge.net on Wed, Aug 23, 2000 at 07:22:52PM -0700 References: <200008240222.TAA25587@bush.i.sourceforge.net> Message-ID: <20000823224536.A950@thyrsus.com> noreply@sourceforge.net : > Comment: > Eric's been doing lots w/ libdb stuff lately. I'll see if > he want's to check this patch out... ;-) Actually I've done almost nothing -- people like you and amk keep getting in there ahead of me. -- Eric S. Raymond Freedom, morality, and the human dignity of the individual consists precisely in this; that he does good not because he is forced to do so, but because he freely conceives it, wants it, and loves it. -- Mikhail Bakunin From noreply@sourceforge.net Thu Aug 24 04:01:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 20:01:16 -0700 Subject: [Patches] [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing Message-ID: <200008240301.UAA16707@delerium.i.sourceforge.net> Patch #101272 has been updated. Project: Category: Modules Status: Open Summary: Allow bsddbmodule.c to compile with libdb 2.x w/o editing Follow-Ups: Date: 2000-Aug-23 22:22 By: montanaro Comment: Eric's been doing lots w/ libdb stuff lately. I'll see if he want's to check this patch out... ;-) ------------------------------------------------------- Date: 2000-Aug-23 23:01 By: fdrake Comment: Update patch to also determine whether the bsddb module should be built at all automatically (adding a stanza to Setup.config.in and a comment to Setup.in). This won't detect all cases automatically, but will catch it on platforms which have it installed as part of the base system (same as for the original patch). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101272&group_id=5470 From noreply@sourceforge.net Thu Aug 24 04:02:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 20:02:11 -0700 Subject: [Patches] [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing Message-ID: <200008240302.UAA16715@delerium.i.sourceforge.net> Patch #101272 has been updated. Project: Category: Modules Status: Open Summary: Allow bsddbmodule.c to compile with libdb 2.x w/o editing Follow-Ups: Date: 2000-Aug-23 22:22 By: montanaro Comment: Eric's been doing lots w/ libdb stuff lately. I'll see if he want's to check this patch out... ;-) ------------------------------------------------------- Date: 2000-Aug-23 23:01 By: fdrake Comment: Update patch to also determine whether the bsddb module should be built at all automatically (adding a stanza to Setup.config.in and a comment to Setup.in). This won't detect all cases automatically, but will catch it on platforms which have it installed as part of the base system (same as for the original patch). ------------------------------------------------------- Date: 2000-Aug-23 23:02 By: fdrake Comment: I'd better note that this still needs testing on a system that only offers BSD db 1.85. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101272&group_id=5470 From noreply@sourceforge.net Thu Aug 24 04:24:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 20:24:10 -0700 Subject: [Patches] [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing Message-ID: <200008240324.UAA27719@bush.i.sourceforge.net> Patch #101272 has been updated. Project: Category: Modules Status: Open Summary: Allow bsddbmodule.c to compile with libdb 2.x w/o editing Follow-Ups: Date: 2000-Aug-23 22:22 By: montanaro Comment: Eric's been doing lots w/ libdb stuff lately. I'll see if he want's to check this patch out... ;-) ------------------------------------------------------- Date: 2000-Aug-23 23:01 By: fdrake Comment: Update patch to also determine whether the bsddb module should be built at all automatically (adding a stanza to Setup.config.in and a comment to Setup.in). This won't detect all cases automatically, but will catch it on platforms which have it installed as part of the base system (same as for the original patch). ------------------------------------------------------- Date: 2000-Aug-23 23:02 By: fdrake Comment: I'd better note that this still needs testing on a system that only offers BSD db 1.85. ------------------------------------------------------- Date: 2000-Aug-23 23:24 By: montanaro Comment: I'm afraid that's beyond my feeble autoconf/configure skills. libdb.a is hardly installed in a standard location on all systems. The Setup.config.in line would be more involved than @USE_BSDDB_MODULE@bsddb bsddbmodule.c -ldb (though that would work on my Mandrake Linux system). I suspect many people still have to install libdb themselves, so it could wind up just about anywhere. You'd have to teach autoconf to reliably find libdb.a then add a line to Setup.config.in that has the correct -L flag. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101272&group_id=5470 From noreply@sourceforge.net Thu Aug 24 04:39:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 20:39:00 -0700 Subject: [Patches] [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing Message-ID: <200008240339.UAA18004@delerium.i.sourceforge.net> Patch #101272 has been updated. Project: Category: Modules Status: Open Summary: Allow bsddbmodule.c to compile with libdb 2.x w/o editing Follow-Ups: Date: 2000-Aug-23 22:22 By: montanaro Comment: Eric's been doing lots w/ libdb stuff lately. I'll see if he want's to check this patch out... ;-) ------------------------------------------------------- Date: 2000-Aug-23 23:01 By: fdrake Comment: Update patch to also determine whether the bsddb module should be built at all automatically (adding a stanza to Setup.config.in and a comment to Setup.in). This won't detect all cases automatically, but will catch it on platforms which have it installed as part of the base system (same as for the original patch). ------------------------------------------------------- Date: 2000-Aug-23 23:02 By: fdrake Comment: I'd better note that this still needs testing on a system that only offers BSD db 1.85. ------------------------------------------------------- Date: 2000-Aug-23 23:24 By: montanaro Comment: I'm afraid that's beyond my feeble autoconf/configure skills. libdb.a is hardly installed in a standard location on all systems. The Setup.config.in line would be more involved than @USE_BSDDB_MODULE@bsddb bsddbmodule.c -ldb (though that would work on my Mandrake Linux system). I suspect many people still have to install libdb themselves, so it could wind up just about anywhere. You'd have to teach autoconf to reliably find libdb.a then add a line to Setup.config.in that has the correct -L flag. ------------------------------------------------------- Date: 2000-Aug-23 23:39 By: fdrake Comment: This is sufficient for all cases that the header detection can deal with. We could (& perhaps should) add the necessary test to make sure -ldb works. For BSD db installs that aren't picked up this way, the stanza in Setup.in remains, and can be edited in Setup or provided in Setup.local. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101272&group_id=5470 From noreply@sourceforge.net Thu Aug 24 05:25:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 21:25:28 -0700 Subject: [Patches] [Patch #101064] [Moshe] Fixing bug 110832 -- urlparse.urljoin Message-ID: <200008240425.VAA19517@delerium.i.sourceforge.net> Patch #101064 has been updated. Project: Category: Modules Status: Rejected Summary: [Moshe] Fixing bug 110832 -- urlparse.urljoin Follow-Ups: Date: 2000-Aug-03 15:06 By: twouters Comment: Moshe's patch to fix bug #110832. ------------------------------------------------------- Date: 2000-Aug-13 04:33 By: moshez Comment: Jeremy, I'm not sure what the right thing *is* -- but this patch certainly solves the bug. So, either the bug is false (so throw the bug and this patch away), or the bug is legit, in which case, please eyeball+test and check in. ------------------------------------------------------- Date: 2000-Aug-15 15:04 By: tim_one Comment: Reassigned to Fred in Jeremy's absence. Fred, I'm being unfair! Sorry about that. I've just been reassigning everything with "url" in the name from Jeremy to you. If you can think of someone better, please be my guest. ------------------------------------------------------- Date: 2000-Aug-24 00:25 By: fdrake Comment: Bug #110832 declared "Not a bug" -- it conflicts with specific recommendations in RFC 1808. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101064&group_id=5470 From noreply@sourceforge.net Thu Aug 24 09:27:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 01:27:27 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008240827.BAA05055@bush.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 20:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 21:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-16 06:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-16 06:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 07:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 09:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 09:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-22 01:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- Date: 2000-Aug-22 04:41 By: moshez Comment: Actually, it's now waiting for someone's pronouncement -- Guido had a problem with .get() and __getitem__ not being equivalent (the first does an implicit .value). Ping and I thought it best that way, but if the BDFL has strong feelings otherwise, he should pronounce. Assigned to him for final verdict. ------------------------------------------------------- Date: 2000-Aug-22 20:46 By: ping Comment: On Fri, 18 Aug 2000, Guido van Rossum wrote: > If I understand the discussion below correctly, to get the > value for 'foo' you must use > > x['foo'].value > > but now you can also use > > x.get('foo') This is true. > ??? That's inconsistent compared to how these two behave for regular > dictionaries! I mulled this over a while when doing the patch. Initially, i did make form.get(x) behave exactly like form[x], and proceeded to try to make the FieldStorage object behave as much like a dictionary as possible (since the docs say it can be "accessed like a dictionary"). FormContentDict and its descendants clearly behave like a dictionary since they are derived from UserDict. But as i investigated FieldStorage further, i found that it actually lacks lots of dictionary behaviour: no update(), no clear(), no copy(), no items(), no values(). The only dictionary-like semantics we really care about are [key], keys(), and has_key(). Implementing items() and values() would require an uncertain choice, since the FieldStorage represents a multimap: do multi-valued fields appear as multiple key-value pairs with the same key, or a single pair with a list for its value? In the end, i decided to abandon true dictionary-like behaviour, because the thing being represented is a bit too much more than a dictionary. By far the most common use of the FieldStorage (and even the entire cgi module) is just to decode simple strings from single-valued form fields, and the interface should do its best to facilitate that common use. I decided it was okay to break consistency with regular dictionaries (a) as long as the behaviour is clearly documented and (b) since it doesn't fully satisfy one's expectations of a dictionary anyway. Moshe's response drove home the point when he demonstrated that the advantage of get() -- to provide a default when a value is missing -- is overwhelmed by the awkwardness of the .value interface. If get() returns a MiniFieldStorage, then to default the "spam" field to "eggs" i have to say field = form.get("spam", "eggs") if type(field) is type(""): process(field) else: process(field.value) or field = form.get("spam", None) if field is None: process("eggs") else: process(field.value) or field = form.get("spam", cgi.MiniFieldStorage("spam", "eggs")) process(field.value) which are hardly any better than if form.has_key("spam"): process(form["spam"].value) else: process("eggs") at all! If get() returns a string, then i can just say process(form.get("spam", "eggs")) and i can be on my way. I have personally stayed away from FieldStorage because it's so annoying to use; having to look up the "value" attribute on every form field makes programs verbose and awkward. This gets worse when a field has multple values. In fact, the usage example provided in Doc/lib/libcgi.tex is a perfect demonstration: username = form["username"] if type(username) is type([]): usernames = "" for item in username: if username: usernames = usernames + "," + item.value else: usernames = item.value else: usernames = username.value The above can be shortened somewhat with map(), but with the new get() method, this can simply be written in the obvious way: value = form.get("username", "") if type(value) is type([]): usernames = ",".join(value) else: usernames = value (The latter is what you would do with a FormContentDict, which is why i find it so vastly more convenient than the FieldStorage. It's slightly better, though: it also painlessly handles the case where the "username" field is not present.) As mentioned earlier, i'm more concerned about the default setting for keep_blank_values. The message i wrote providing a complete explanation of this issue is included below so you don't have to search through old e-mail to find it. -- ?!ng -------- the headers of the original message -------- >From ping@lfw.org Tue Aug 22 12:18:57 2000 Date: Wed, 16 Aug 2000 02:31:48 -0700 (PDT) From: Ka-Ping Yee To: Moshe Zadka , bwarsaw@beopen.com, tpeters@beopen.com Subject: Re: [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict -------- the message body, with some edits -------- Hi, guys. This patch includes a "fix" to make cgi.parse_qsl honour its "keep_blank_values" argument. This fix might require a bit more discussion since it could break compatibility, so i thought i would air it for your consideration. BACKGROUND ---------- cgi.FieldStorage(), cgi.parse(), cgi.parse_qs(), and cgi.parse_qsl() all accept an optional "keep_blank_values" argument which is supposed to indicate whether form fields with empty strings as values should be included in the result. In reality, only cgi.parse_qs() honours this flag (cgi.parse() is okay because it uses cgi.parse_qs()). cgi.parse_qsl() totally ignores it, and always includes all values including empty ones. cgi.FieldStorage(), which uses cgi.parse_qsl(), similarly does not honour the "keep_blank_values" flag. The patch contains a fix to make cgi.parse_qsl() honour this flag. FOR --- It's clear that this was the intent of the "keep_blank_values" argument. The doc string for parse_qsl says: """Parse a query given as a string argument. Arguments: qs: URL-encoded query string to be parsed keep_blank_values: flag indicating whether blank values in URL encoded queries should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. Returns a list, as God intended. """ Its current disregard for "keep_blank_values" clearly contradicts this doc string. The doc string for FieldStorage.__init__ says: """Constructor. Read multipart/* until last part. Arguments, all optional: fp : file pointer; default: sys.stdin (not used when the request method is GET) headers : header dictionary-like object; default: taken from environ as per CGI spec outerboundary : terminating multipart boundary (for internal use only) environ : environment dictionary; default: os.environ keep_blank_values: flag indicating whether blank values in URL encoded forms should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. """ ...and the current behaviour of FieldStorage.__init__ contradicts what it says here about "keep_blank_values". AGAINST ------- Existing code which uses FieldStorage and relies on its current behaviour could break. If a form field is left blank by the user and the form is submitted, that key will not appear in the FieldStorage -- and an attempt to index it with form[key] will produce a KeyError where previously it yielded a MiniFieldStorage containing an empty string. The existing TeX documentation for the cgi module does not mention empty values or the keep_blank_values argument at all, so to those who have only read the library reference manual, this could be a surprise. OPTIONS ------- The reason this never showed up before is that there have never been *any* tests for FieldStorage in test_cgi.py! Naughty, naughty. One easy way to maintain compatibility is to change FieldStorage so that the default value for keep_blank_values is 1 (previously this was 0 but the FieldStorage *acted* as though it were 1). ------------------------------------------------------- Date: 2000-Aug-23 16:35 By: jhylton Comment: Since we are in feature freeze, let's not worry about whether we should have a get method or not. Please limit this patch to bug fixes and re-submit. I'll be happy to accept. Let's do a more thorough job of revising this module for 2.1. It looks amazingly complicated to me. ------------------------------------------------------- Date: 2000-Aug-24 08:27 By: ping Comment: Hi, Jeremy. I actually think the motivations for these changes are pretty clear. They directly address two things: 1. The doc strings say keep_blank_values is supposed to control whether blank values are kept. This currently doesn't work at all. 2. The TeX documentation says the FieldStorage object is supposed to behave like a dictionary. Dictionaries are expected to provide a .get() method, but the FieldStorage doesn't. Both of these things are basically bugs. The only decisions that remain have to do with backward compatibility when we fix #1 -- this is easily addressed by defaulting keep_blank_values to 1 -- and with determining the most effective way to implement .get() when we fix #2. The implementation of .get() in this patch greatly simplifies most CGI scripts. As shown in the examples in my previous comment, it can reduce four or five lines of mucking with the .value attribute to a single call. -- ?!ng ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Thu Aug 24 12:37:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 04:37:27 -0700 Subject: [Patches] [Patch #100899] a smaller unicode name database Message-ID: <200008241137.EAA11379@bush.i.sourceforge.net> Patch #100899 has been updated. Project: Category: None Status: Open Summary: a smaller unicode name database Follow-Ups: Date: 2000-Jul-15 22:43 By: effbot Comment: duh. it's too large for sourceforge. if you want to play with it, get it from: http://w1.132.telia.com/~u13208596/uninames-patch.txt ------------------------------------------------------- Date: 2000-Aug-03 18:59 By: lemburg Comment: How is the work on this patch coming along ? Will it be ready for 2.0 ? ------------------------------------------------------- Date: 2000-Aug-15 17:42 By: tim_one Comment: /F or MAL, what's going on with this? MAL, did you look at the patch? /F, do you feel it's done? ------------------------------------------------------- Date: 2000-Aug-23 18:39 By: tim_one Comment: Assigned back to /F because he agrees the ball bounced back into his court: [/F, in Python-Dev mail] mal has reviewed the patch, and is waiting for an update from me. ------------------------------------------------------- Date: 2000-Aug-24 11:37 By: lemburg Comment: I'd rather see this patch postponed. Reason: We're not in a hury here -- better get this done right than to quickly throw together a set of patches without some more extensive testing. Comment for future reference: --------------------- Note that I would also like to unify the different Unicode databases (ctype DBs, Unicode DB and Unicode name DB) into one single unicodedb access module which will be written in Python. The sibling C modules can then be loaded dynamically and in a lazy fashion. This will result in an implementation which should be much easier to maintain than the current (2.0) setup. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100899&group_id=5470 From tg@melaten.rwth-aachen.de Wed Aug 23 13:23:04 2000 From: tg@melaten.rwth-aachen.de (Thomas Gellekum) Date: 23 Aug 2000 14:23:04 +0200 Subject: [Patches] Patches to python-1.6b1 Message-ID: --=-=-= Moin, I have a couple of diffs for 1.6b1, mostly for FreeBSD. 1. configure.in: some cleanup for FreeBSD. This gets rid of version numbers and figures out old (a.out) and newer (ELF) systems, similar to NetBSD. 2. Lib/tempfile.py: add '/var/tmp' to the attempdirs for 4.4BSD-based systems. 3. Lib/posixfile.py: add support for FreeBSD-[45]. 4. Lib/test/test_fcntl.py: add support for FreeBSD-[45]. 5. Makefile.in: our (FreeBSD's) security officer doesn't like group-writable directories and sent a patch; `curses' was missing from LIBSUBDIRS; don't install *.orig BTW, I tried using this patch manager thing on sourceforge, but only got an error message back. Not that I mind, I prefer an e-mail address anyway. ;-) tg --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=configure.in.diff Content-Description: configure.in.diff --- configure.in.orig Thu May 11 20:41:32 2000 +++ configure.in Wed Aug 23 17:50:44 2000 @@ -509,8 +509,7 @@ Linux*) LDSHARED="gcc -shared";; dgux*) LDSHARED="ld -G";; BSD/OS*/4*) LDSHARED="gcc -shared";; - FreeBSD*/[[34]]*) LDSHARED="gcc -shared";; - FreeBSD*|OpenBSD*) LDSHARED="ld -Bshareable";; + OpenBSD*) LDSHARED="ld -Bshareable";; NetBSD*) if [[ "`$CC -dM -E - References: <200008240827.BAA05055@bush.i.sourceforge.net> Message-ID: <200008241336.IAA01629@cj20424-a.reston1.va.home.com> > Date: 2000-Aug-24 08:27 > By: ping > > Comment: > Hi, Jeremy. > > I actually think the motivations for these changes are pretty clear. > They directly address two things: > > 1. The doc strings say keep_blank_values is supposed to control > whether blank values are kept. This currently doesn't work at all. > > 2. The TeX documentation says the FieldStorage object is supposed > to behave like a dictionary. Dictionaries are expected to provide a > .get() method, but the FieldStorage doesn't. > > Both of these things are basically bugs. The only decisions that > remain have to do with backward compatibility when we fix #1 -- this > is easily addressed by defaulting keep_blank_values to 1 -- and with > determining the most effective way to implement .get() when we fix > #2. > > The implementation of .get() in this patch greatly simplifies most > CGI scripts. As shown in the examples in my previous comment, it > can reduce four or five lines of mucking with the .value attribute > to a single call. Ping, It may be me, but I'm getting annoyed by this. For any object that implements a partial mapping protocol, any mapping methods that it implement should behave according to the mapping protocol, and be consistent with the others. So it's fine to leave e.e. items() out, but it's not okay to implement items() as an alias for has_key(). Adding the functionality you want is great, but it shouldn't be called get(). Call it getvalue() and I'm happy. The words "behave like a dictionary" have such a vague meaning that lacking a get() method can't be seen as a violation. However having a get() method that does something different *is* a violation! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From noreply@sourceforge.net Thu Aug 24 13:57:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 05:57:10 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008241257.FAA04198@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 20:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 21:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-16 06:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-16 06:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 07:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 09:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 09:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-22 01:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- Date: 2000-Aug-22 04:41 By: moshez Comment: Actually, it's now waiting for someone's pronouncement -- Guido had a problem with .get() and __getitem__ not being equivalent (the first does an implicit .value). Ping and I thought it best that way, but if the BDFL has strong feelings otherwise, he should pronounce. Assigned to him for final verdict. ------------------------------------------------------- Date: 2000-Aug-22 20:46 By: ping Comment: On Fri, 18 Aug 2000, Guido van Rossum wrote: > If I understand the discussion below correctly, to get the > value for 'foo' you must use > > x['foo'].value > > but now you can also use > > x.get('foo') This is true. > ??? That's inconsistent compared to how these two behave for regular > dictionaries! I mulled this over a while when doing the patch. Initially, i did make form.get(x) behave exactly like form[x], and proceeded to try to make the FieldStorage object behave as much like a dictionary as possible (since the docs say it can be "accessed like a dictionary"). FormContentDict and its descendants clearly behave like a dictionary since they are derived from UserDict. But as i investigated FieldStorage further, i found that it actually lacks lots of dictionary behaviour: no update(), no clear(), no copy(), no items(), no values(). The only dictionary-like semantics we really care about are [key], keys(), and has_key(). Implementing items() and values() would require an uncertain choice, since the FieldStorage represents a multimap: do multi-valued fields appear as multiple key-value pairs with the same key, or a single pair with a list for its value? In the end, i decided to abandon true dictionary-like behaviour, because the thing being represented is a bit too much more than a dictionary. By far the most common use of the FieldStorage (and even the entire cgi module) is just to decode simple strings from single-valued form fields, and the interface should do its best to facilitate that common use. I decided it was okay to break consistency with regular dictionaries (a) as long as the behaviour is clearly documented and (b) since it doesn't fully satisfy one's expectations of a dictionary anyway. Moshe's response drove home the point when he demonstrated that the advantage of get() -- to provide a default when a value is missing -- is overwhelmed by the awkwardness of the .value interface. If get() returns a MiniFieldStorage, then to default the "spam" field to "eggs" i have to say field = form.get("spam", "eggs") if type(field) is type(""): process(field) else: process(field.value) or field = form.get("spam", None) if field is None: process("eggs") else: process(field.value) or field = form.get("spam", cgi.MiniFieldStorage("spam", "eggs")) process(field.value) which are hardly any better than if form.has_key("spam"): process(form["spam"].value) else: process("eggs") at all! If get() returns a string, then i can just say process(form.get("spam", "eggs")) and i can be on my way. I have personally stayed away from FieldStorage because it's so annoying to use; having to look up the "value" attribute on every form field makes programs verbose and awkward. This gets worse when a field has multple values. In fact, the usage example provided in Doc/lib/libcgi.tex is a perfect demonstration: username = form["username"] if type(username) is type([]): usernames = "" for item in username: if username: usernames = usernames + "," + item.value else: usernames = item.value else: usernames = username.value The above can be shortened somewhat with map(), but with the new get() method, this can simply be written in the obvious way: value = form.get("username", "") if type(value) is type([]): usernames = ",".join(value) else: usernames = value (The latter is what you would do with a FormContentDict, which is why i find it so vastly more convenient than the FieldStorage. It's slightly better, though: it also painlessly handles the case where the "username" field is not present.) As mentioned earlier, i'm more concerned about the default setting for keep_blank_values. The message i wrote providing a complete explanation of this issue is included below so you don't have to search through old e-mail to find it. -- ?!ng -------- the headers of the original message -------- >From ping@lfw.org Tue Aug 22 12:18:57 2000 Date: Wed, 16 Aug 2000 02:31:48 -0700 (PDT) From: Ka-Ping Yee To: Moshe Zadka , bwarsaw@beopen.com, tpeters@beopen.com Subject: Re: [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict -------- the message body, with some edits -------- Hi, guys. This patch includes a "fix" to make cgi.parse_qsl honour its "keep_blank_values" argument. This fix might require a bit more discussion since it could break compatibility, so i thought i would air it for your consideration. BACKGROUND ---------- cgi.FieldStorage(), cgi.parse(), cgi.parse_qs(), and cgi.parse_qsl() all accept an optional "keep_blank_values" argument which is supposed to indicate whether form fields with empty strings as values should be included in the result. In reality, only cgi.parse_qs() honours this flag (cgi.parse() is okay because it uses cgi.parse_qs()). cgi.parse_qsl() totally ignores it, and always includes all values including empty ones. cgi.FieldStorage(), which uses cgi.parse_qsl(), similarly does not honour the "keep_blank_values" flag. The patch contains a fix to make cgi.parse_qsl() honour this flag. FOR --- It's clear that this was the intent of the "keep_blank_values" argument. The doc string for parse_qsl says: """Parse a query given as a string argument. Arguments: qs: URL-encoded query string to be parsed keep_blank_values: flag indicating whether blank values in URL encoded queries should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. Returns a list, as God intended. """ Its current disregard for "keep_blank_values" clearly contradicts this doc string. The doc string for FieldStorage.__init__ says: """Constructor. Read multipart/* until last part. Arguments, all optional: fp : file pointer; default: sys.stdin (not used when the request method is GET) headers : header dictionary-like object; default: taken from environ as per CGI spec outerboundary : terminating multipart boundary (for internal use only) environ : environment dictionary; default: os.environ keep_blank_values: flag indicating whether blank values in URL encoded forms should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. """ ...and the current behaviour of FieldStorage.__init__ contradicts what it says here about "keep_blank_values". AGAINST ------- Existing code which uses FieldStorage and relies on its current behaviour could break. If a form field is left blank by the user and the form is submitted, that key will not appear in the FieldStorage -- and an attempt to index it with form[key] will produce a KeyError where previously it yielded a MiniFieldStorage containing an empty string. The existing TeX documentation for the cgi module does not mention empty values or the keep_blank_values argument at all, so to those who have only read the library reference manual, this could be a surprise. OPTIONS ------- The reason this never showed up before is that there have never been *any* tests for FieldStorage in test_cgi.py! Naughty, naughty. One easy way to maintain compatibility is to change FieldStorage so that the default value for keep_blank_values is 1 (previously this was 0 but the FieldStorage *acted* as though it were 1). ------------------------------------------------------- Date: 2000-Aug-23 16:35 By: jhylton Comment: Since we are in feature freeze, let's not worry about whether we should have a get method or not. Please limit this patch to bug fixes and re-submit. I'll be happy to accept. Let's do a more thorough job of revising this module for 2.1. It looks amazingly complicated to me. ------------------------------------------------------- Date: 2000-Aug-24 08:27 By: ping Comment: Hi, Jeremy. I actually think the motivations for these changes are pretty clear. They directly address two things: 1. The doc strings say keep_blank_values is supposed to control whether blank values are kept. This currently doesn't work at all. 2. The TeX documentation says the FieldStorage object is supposed to behave like a dictionary. Dictionaries are expected to provide a .get() method, but the FieldStorage doesn't. Both of these things are basically bugs. The only decisions that remain have to do with backward compatibility when we fix #1 -- this is easily addressed by defaulting keep_blank_values to 1 -- and with determining the most effective way to implement .get() when we fix #2. The implementation of .get() in this patch greatly simplifies most CGI scripts. As shown in the examples in my previous comment, it can reduce four or five lines of mucking with the .value attribute to a single call. -- ?!ng ------------------------------------------------------- Date: 2000-Aug-24 12:57 By: moshez Comment: Guido: Adding the functionality you want is great, but it shouldn't be called get(). Call it getvalue() and I'm happy. The words "behave like a dictionary" have such a vague meaning that lacking a get() method can't be seen as a violation. However having a get() method that does something different *is* a violation! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Thu Aug 24 13:58:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 05:58:27 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008241258.FAA04315@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 20:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 21:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-16 06:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-16 06:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 07:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 09:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 09:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-22 01:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- Date: 2000-Aug-22 04:41 By: moshez Comment: Actually, it's now waiting for someone's pronouncement -- Guido had a problem with .get() and __getitem__ not being equivalent (the first does an implicit .value). Ping and I thought it best that way, but if the BDFL has strong feelings otherwise, he should pronounce. Assigned to him for final verdict. ------------------------------------------------------- Date: 2000-Aug-22 20:46 By: ping Comment: On Fri, 18 Aug 2000, Guido van Rossum wrote: > If I understand the discussion below correctly, to get the > value for 'foo' you must use > > x['foo'].value > > but now you can also use > > x.get('foo') This is true. > ??? That's inconsistent compared to how these two behave for regular > dictionaries! I mulled this over a while when doing the patch. Initially, i did make form.get(x) behave exactly like form[x], and proceeded to try to make the FieldStorage object behave as much like a dictionary as possible (since the docs say it can be "accessed like a dictionary"). FormContentDict and its descendants clearly behave like a dictionary since they are derived from UserDict. But as i investigated FieldStorage further, i found that it actually lacks lots of dictionary behaviour: no update(), no clear(), no copy(), no items(), no values(). The only dictionary-like semantics we really care about are [key], keys(), and has_key(). Implementing items() and values() would require an uncertain choice, since the FieldStorage represents a multimap: do multi-valued fields appear as multiple key-value pairs with the same key, or a single pair with a list for its value? In the end, i decided to abandon true dictionary-like behaviour, because the thing being represented is a bit too much more than a dictionary. By far the most common use of the FieldStorage (and even the entire cgi module) is just to decode simple strings from single-valued form fields, and the interface should do its best to facilitate that common use. I decided it was okay to break consistency with regular dictionaries (a) as long as the behaviour is clearly documented and (b) since it doesn't fully satisfy one's expectations of a dictionary anyway. Moshe's response drove home the point when he demonstrated that the advantage of get() -- to provide a default when a value is missing -- is overwhelmed by the awkwardness of the .value interface. If get() returns a MiniFieldStorage, then to default the "spam" field to "eggs" i have to say field = form.get("spam", "eggs") if type(field) is type(""): process(field) else: process(field.value) or field = form.get("spam", None) if field is None: process("eggs") else: process(field.value) or field = form.get("spam", cgi.MiniFieldStorage("spam", "eggs")) process(field.value) which are hardly any better than if form.has_key("spam"): process(form["spam"].value) else: process("eggs") at all! If get() returns a string, then i can just say process(form.get("spam", "eggs")) and i can be on my way. I have personally stayed away from FieldStorage because it's so annoying to use; having to look up the "value" attribute on every form field makes programs verbose and awkward. This gets worse when a field has multple values. In fact, the usage example provided in Doc/lib/libcgi.tex is a perfect demonstration: username = form["username"] if type(username) is type([]): usernames = "" for item in username: if username: usernames = usernames + "," + item.value else: usernames = item.value else: usernames = username.value The above can be shortened somewhat with map(), but with the new get() method, this can simply be written in the obvious way: value = form.get("username", "") if type(value) is type([]): usernames = ",".join(value) else: usernames = value (The latter is what you would do with a FormContentDict, which is why i find it so vastly more convenient than the FieldStorage. It's slightly better, though: it also painlessly handles the case where the "username" field is not present.) As mentioned earlier, i'm more concerned about the default setting for keep_blank_values. The message i wrote providing a complete explanation of this issue is included below so you don't have to search through old e-mail to find it. -- ?!ng -------- the headers of the original message -------- >From ping@lfw.org Tue Aug 22 12:18:57 2000 Date: Wed, 16 Aug 2000 02:31:48 -0700 (PDT) From: Ka-Ping Yee To: Moshe Zadka , bwarsaw@beopen.com, tpeters@beopen.com Subject: Re: [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict -------- the message body, with some edits -------- Hi, guys. This patch includes a "fix" to make cgi.parse_qsl honour its "keep_blank_values" argument. This fix might require a bit more discussion since it could break compatibility, so i thought i would air it for your consideration. BACKGROUND ---------- cgi.FieldStorage(), cgi.parse(), cgi.parse_qs(), and cgi.parse_qsl() all accept an optional "keep_blank_values" argument which is supposed to indicate whether form fields with empty strings as values should be included in the result. In reality, only cgi.parse_qs() honours this flag (cgi.parse() is okay because it uses cgi.parse_qs()). cgi.parse_qsl() totally ignores it, and always includes all values including empty ones. cgi.FieldStorage(), which uses cgi.parse_qsl(), similarly does not honour the "keep_blank_values" flag. The patch contains a fix to make cgi.parse_qsl() honour this flag. FOR --- It's clear that this was the intent of the "keep_blank_values" argument. The doc string for parse_qsl says: """Parse a query given as a string argument. Arguments: qs: URL-encoded query string to be parsed keep_blank_values: flag indicating whether blank values in URL encoded queries should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. Returns a list, as God intended. """ Its current disregard for "keep_blank_values" clearly contradicts this doc string. The doc string for FieldStorage.__init__ says: """Constructor. Read multipart/* until last part. Arguments, all optional: fp : file pointer; default: sys.stdin (not used when the request method is GET) headers : header dictionary-like object; default: taken from environ as per CGI spec outerboundary : terminating multipart boundary (for internal use only) environ : environment dictionary; default: os.environ keep_blank_values: flag indicating whether blank values in URL encoded forms should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. """ ...and the current behaviour of FieldStorage.__init__ contradicts what it says here about "keep_blank_values". AGAINST ------- Existing code which uses FieldStorage and relies on its current behaviour could break. If a form field is left blank by the user and the form is submitted, that key will not appear in the FieldStorage -- and an attempt to index it with form[key] will produce a KeyError where previously it yielded a MiniFieldStorage containing an empty string. The existing TeX documentation for the cgi module does not mention empty values or the keep_blank_values argument at all, so to those who have only read the library reference manual, this could be a surprise. OPTIONS ------- The reason this never showed up before is that there have never been *any* tests for FieldStorage in test_cgi.py! Naughty, naughty. One easy way to maintain compatibility is to change FieldStorage so that the default value for keep_blank_values is 1 (previously this was 0 but the FieldStorage *acted* as though it were 1). ------------------------------------------------------- Date: 2000-Aug-23 16:35 By: jhylton Comment: Since we are in feature freeze, let's not worry about whether we should have a get method or not. Please limit this patch to bug fixes and re-submit. I'll be happy to accept. Let's do a more thorough job of revising this module for 2.1. It looks amazingly complicated to me. ------------------------------------------------------- Date: 2000-Aug-24 08:27 By: ping Comment: Hi, Jeremy. I actually think the motivations for these changes are pretty clear. They directly address two things: 1. The doc strings say keep_blank_values is supposed to control whether blank values are kept. This currently doesn't work at all. 2. The TeX documentation says the FieldStorage object is supposed to behave like a dictionary. Dictionaries are expected to provide a .get() method, but the FieldStorage doesn't. Both of these things are basically bugs. The only decisions that remain have to do with backward compatibility when we fix #1 -- this is easily addressed by defaulting keep_blank_values to 1 -- and with determining the most effective way to implement .get() when we fix #2. The implementation of .get() in this patch greatly simplifies most CGI scripts. As shown in the examples in my previous comment, it can reduce four or five lines of mucking with the .value attribute to a single call. -- ?!ng ------------------------------------------------------- Date: 2000-Aug-24 12:57 By: moshez Comment: Guido: Adding the functionality you want is great, but it shouldn't be called get(). Call it getvalue() and I'm happy. The words "behave like a dictionary" have such a vague meaning that lacking a get() method can't be seen as a violation. However having a get() method that does something different *is* a violation! ------------------------------------------------------- Date: 2000-Aug-24 12:58 By: moshez Comment: OK, that seems fine, but in this case, FieldStorage shouldn't have a "get", only "getvalue". ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Thu Aug 24 15:20:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 07:20:01 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008241420.HAA17337@bush.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Open Summary: Issue a warning if Setup.in is newer than Setup ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 24 15:52:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 07:52:00 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008241452.HAA18516@bush.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 20:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 21:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-16 06:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-16 06:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 07:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 09:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 09:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-22 01:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- Date: 2000-Aug-22 04:41 By: moshez Comment: Actually, it's now waiting for someone's pronouncement -- Guido had a problem with .get() and __getitem__ not being equivalent (the first does an implicit .value). Ping and I thought it best that way, but if the BDFL has strong feelings otherwise, he should pronounce. Assigned to him for final verdict. ------------------------------------------------------- Date: 2000-Aug-22 20:46 By: ping Comment: On Fri, 18 Aug 2000, Guido van Rossum wrote: > If I understand the discussion below correctly, to get the > value for 'foo' you must use > > x['foo'].value > > but now you can also use > > x.get('foo') This is true. > ??? That's inconsistent compared to how these two behave for regular > dictionaries! I mulled this over a while when doing the patch. Initially, i did make form.get(x) behave exactly like form[x], and proceeded to try to make the FieldStorage object behave as much like a dictionary as possible (since the docs say it can be "accessed like a dictionary"). FormContentDict and its descendants clearly behave like a dictionary since they are derived from UserDict. But as i investigated FieldStorage further, i found that it actually lacks lots of dictionary behaviour: no update(), no clear(), no copy(), no items(), no values(). The only dictionary-like semantics we really care about are [key], keys(), and has_key(). Implementing items() and values() would require an uncertain choice, since the FieldStorage represents a multimap: do multi-valued fields appear as multiple key-value pairs with the same key, or a single pair with a list for its value? In the end, i decided to abandon true dictionary-like behaviour, because the thing being represented is a bit too much more than a dictionary. By far the most common use of the FieldStorage (and even the entire cgi module) is just to decode simple strings from single-valued form fields, and the interface should do its best to facilitate that common use. I decided it was okay to break consistency with regular dictionaries (a) as long as the behaviour is clearly documented and (b) since it doesn't fully satisfy one's expectations of a dictionary anyway. Moshe's response drove home the point when he demonstrated that the advantage of get() -- to provide a default when a value is missing -- is overwhelmed by the awkwardness of the .value interface. If get() returns a MiniFieldStorage, then to default the "spam" field to "eggs" i have to say field = form.get("spam", "eggs") if type(field) is type(""): process(field) else: process(field.value) or field = form.get("spam", None) if field is None: process("eggs") else: process(field.value) or field = form.get("spam", cgi.MiniFieldStorage("spam", "eggs")) process(field.value) which are hardly any better than if form.has_key("spam"): process(form["spam"].value) else: process("eggs") at all! If get() returns a string, then i can just say process(form.get("spam", "eggs")) and i can be on my way. I have personally stayed away from FieldStorage because it's so annoying to use; having to look up the "value" attribute on every form field makes programs verbose and awkward. This gets worse when a field has multple values. In fact, the usage example provided in Doc/lib/libcgi.tex is a perfect demonstration: username = form["username"] if type(username) is type([]): usernames = "" for item in username: if username: usernames = usernames + "," + item.value else: usernames = item.value else: usernames = username.value The above can be shortened somewhat with map(), but with the new get() method, this can simply be written in the obvious way: value = form.get("username", "") if type(value) is type([]): usernames = ",".join(value) else: usernames = value (The latter is what you would do with a FormContentDict, which is why i find it so vastly more convenient than the FieldStorage. It's slightly better, though: it also painlessly handles the case where the "username" field is not present.) As mentioned earlier, i'm more concerned about the default setting for keep_blank_values. The message i wrote providing a complete explanation of this issue is included below so you don't have to search through old e-mail to find it. -- ?!ng -------- the headers of the original message -------- >From ping@lfw.org Tue Aug 22 12:18:57 2000 Date: Wed, 16 Aug 2000 02:31:48 -0700 (PDT) From: Ka-Ping Yee To: Moshe Zadka , bwarsaw@beopen.com, tpeters@beopen.com Subject: Re: [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict -------- the message body, with some edits -------- Hi, guys. This patch includes a "fix" to make cgi.parse_qsl honour its "keep_blank_values" argument. This fix might require a bit more discussion since it could break compatibility, so i thought i would air it for your consideration. BACKGROUND ---------- cgi.FieldStorage(), cgi.parse(), cgi.parse_qs(), and cgi.parse_qsl() all accept an optional "keep_blank_values" argument which is supposed to indicate whether form fields with empty strings as values should be included in the result. In reality, only cgi.parse_qs() honours this flag (cgi.parse() is okay because it uses cgi.parse_qs()). cgi.parse_qsl() totally ignores it, and always includes all values including empty ones. cgi.FieldStorage(), which uses cgi.parse_qsl(), similarly does not honour the "keep_blank_values" flag. The patch contains a fix to make cgi.parse_qsl() honour this flag. FOR --- It's clear that this was the intent of the "keep_blank_values" argument. The doc string for parse_qsl says: """Parse a query given as a string argument. Arguments: qs: URL-encoded query string to be parsed keep_blank_values: flag indicating whether blank values in URL encoded queries should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. Returns a list, as God intended. """ Its current disregard for "keep_blank_values" clearly contradicts this doc string. The doc string for FieldStorage.__init__ says: """Constructor. Read multipart/* until last part. Arguments, all optional: fp : file pointer; default: sys.stdin (not used when the request method is GET) headers : header dictionary-like object; default: taken from environ as per CGI spec outerboundary : terminating multipart boundary (for internal use only) environ : environment dictionary; default: os.environ keep_blank_values: flag indicating whether blank values in URL encoded forms should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. """ ...and the current behaviour of FieldStorage.__init__ contradicts what it says here about "keep_blank_values". AGAINST ------- Existing code which uses FieldStorage and relies on its current behaviour could break. If a form field is left blank by the user and the form is submitted, that key will not appear in the FieldStorage -- and an attempt to index it with form[key] will produce a KeyError where previously it yielded a MiniFieldStorage containing an empty string. The existing TeX documentation for the cgi module does not mention empty values or the keep_blank_values argument at all, so to those who have only read the library reference manual, this could be a surprise. OPTIONS ------- The reason this never showed up before is that there have never been *any* tests for FieldStorage in test_cgi.py! Naughty, naughty. One easy way to maintain compatibility is to change FieldStorage so that the default value for keep_blank_values is 1 (previously this was 0 but the FieldStorage *acted* as though it were 1). ------------------------------------------------------- Date: 2000-Aug-23 16:35 By: jhylton Comment: Since we are in feature freeze, let's not worry about whether we should have a get method or not. Please limit this patch to bug fixes and re-submit. I'll be happy to accept. Let's do a more thorough job of revising this module for 2.1. It looks amazingly complicated to me. ------------------------------------------------------- Date: 2000-Aug-24 08:27 By: ping Comment: Hi, Jeremy. I actually think the motivations for these changes are pretty clear. They directly address two things: 1. The doc strings say keep_blank_values is supposed to control whether blank values are kept. This currently doesn't work at all. 2. The TeX documentation says the FieldStorage object is supposed to behave like a dictionary. Dictionaries are expected to provide a .get() method, but the FieldStorage doesn't. Both of these things are basically bugs. The only decisions that remain have to do with backward compatibility when we fix #1 -- this is easily addressed by defaulting keep_blank_values to 1 -- and with determining the most effective way to implement .get() when we fix #2. The implementation of .get() in this patch greatly simplifies most CGI scripts. As shown in the examples in my previous comment, it can reduce four or five lines of mucking with the .value attribute to a single call. -- ?!ng ------------------------------------------------------- Date: 2000-Aug-24 12:57 By: moshez Comment: Guido: Adding the functionality you want is great, but it shouldn't be called get(). Call it getvalue() and I'm happy. The words "behave like a dictionary" have such a vague meaning that lacking a get() method can't be seen as a violation. However having a get() method that does something different *is* a violation! ------------------------------------------------------- Date: 2000-Aug-24 12:58 By: moshez Comment: OK, that seems fine, but in this case, FieldStorage shouldn't have a "get", only "getvalue". ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Thu Aug 24 15:59:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 07:59:19 -0700 Subject: [Patches] [Patch #101187] Patch for ftplib to support REST Message-ID: <200008241459.HAA18734@bush.i.sourceforge.net> Patch #101187 has been updated. Project: Category: Modules Status: Open Summary: Patch for ftplib to support REST Follow-Ups: Date: 2000-Aug-15 22:34 By: tim_one Comment: Assigned to Barry for an opinion. This came in after feature freeze, but it's arguably more of a bugfix than a new feature. If you're capable of making that decision with more confidence than me, please Postpone it or assign it to a competent (not me) reviewer for 2.0. ------------------------------------------------------- Date: 2000-Aug-22 07:09 By: moshez Comment: This seems great, and I'm very +1, except for one thing: the ``self.sendcmd("REST %.0f" % rest)'' thing: wouldn't it be better to self.sendcmd("REST %d" % int(rest))? Other then that, it seems to do nothing when the rest argument is not given, so it can't hurt too much. Oh, and of course, this needs doc patches. ------------------------------------------------------- Date: 2000-Aug-22 15:33 By: none Comment: I realized some problem yesterday ... ftp-daemons which do not support REST throw a 502 exception ------------------------------------------------------- Date: 2000-Aug-22 16:05 By: preisl Comment: Ok, forget my last commet (yep, it was me, who forgot to login) ... I think it's ok that the ftplib throws the exception, since the user knows, that he mustn't use the rest parameter then. ------------------------------------------------------- Date: 2000-Aug-24 14:59 By: moshez Comment: OK, here's a stab at what's needed for documentation changes: Add to the prototype of the "ntransfercmd()" and "transfercmd" an \optional{, rest} and to the description a paragraph: If the \var{rest} parameter is given, it should be an integer, specifying how many initial bytes of the file the tranfer command should ignore. If the FTP server does not support the \code{REST} command, and the \var{rest} argument is used, an exception will be raised. Programs might want to deal with it by initiating a transfer without \var{rest}, and ignore the first \var{rest} bytes. (Of course, this option is much more costly in terms of time and network resources used.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101187&group_id=5470 From noreply@sourceforge.net Thu Aug 24 16:05:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 08:05:12 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008241505.IAA19044@bush.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Open Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 10:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 11:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 24 16:13:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 08:13:30 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008241513.IAA09348@delerium.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Open Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 10:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 11:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 11:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 24 16:17:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 08:17:12 -0700 Subject: [Patches] [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing Message-ID: <200008241517.IAA19446@bush.i.sourceforge.net> Patch #101272 has been updated. Project: Category: Modules Status: Open Summary: Allow bsddbmodule.c to compile with libdb 2.x w/o editing Follow-Ups: Date: 2000-Aug-23 22:22 By: montanaro Comment: Eric's been doing lots w/ libdb stuff lately. I'll see if he want's to check this patch out... ;-) ------------------------------------------------------- Date: 2000-Aug-23 23:01 By: fdrake Comment: Update patch to also determine whether the bsddb module should be built at all automatically (adding a stanza to Setup.config.in and a comment to Setup.in). This won't detect all cases automatically, but will catch it on platforms which have it installed as part of the base system (same as for the original patch). ------------------------------------------------------- Date: 2000-Aug-23 23:02 By: fdrake Comment: I'd better note that this still needs testing on a system that only offers BSD db 1.85. ------------------------------------------------------- Date: 2000-Aug-23 23:24 By: montanaro Comment: I'm afraid that's beyond my feeble autoconf/configure skills. libdb.a is hardly installed in a standard location on all systems. The Setup.config.in line would be more involved than @USE_BSDDB_MODULE@bsddb bsddbmodule.c -ldb (though that would work on my Mandrake Linux system). I suspect many people still have to install libdb themselves, so it could wind up just about anywhere. You'd have to teach autoconf to reliably find libdb.a then add a line to Setup.config.in that has the correct -L flag. ------------------------------------------------------- Date: 2000-Aug-23 23:39 By: fdrake Comment: This is sufficient for all cases that the header detection can deal with. We could (& perhaps should) add the necessary test to make sure -ldb works. For BSD db installs that aren't picked up this way, the stanza in Setup.in remains, and can be edited in Setup or provided in Setup.local. ------------------------------------------------------- Date: 2000-Aug-24 11:17 By: montanaro Comment: Okay, this patch goes a bit farther. Here's a quick summary: 1. It adds a line to Modules/Setup.config.in for the bsddb module, prefixed with USE_BSDDB_MODULE. 2. Configure gains a --with-libdb flag. If either --with-libdb is added to the command line or db.h is found, the bsddb module will be enabled. Of course, running configure using --without-libdb will disable it. 3. There's a comment in Setup.in about the new way of enabling the bsddb module, but the old commented out lines are still there. 4. If db_185.h is found, it's included instead of db.h. Both #includes are protected by their relevant HAVE_* defines in Modules/bsddbmodule.c (or should I let the db.h include fail?). 5. No attempt is made to search for libdb.h. It's assumed that if users install it in some odd location they will run configure with the --libdir and/or --includedir flags. Still needs testing on a 1.85/1.86 libdb. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101272&group_id=5470 From noreply@sourceforge.net Thu Aug 24 16:19:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 08:19:06 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008241519.IAA19488@bush.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Open Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 10:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 11:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 11:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- Date: 2000-Aug-24 11:19 By: montanaro Comment: try "man 1 test". -nt is actually an argument to the test command. Bash's builtin test command does support -nt. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 24 16:21:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 08:21:51 -0700 Subject: [Patches] [Patch #101277] Catch errors from during dictionary lookup. Message-ID: <200008241521.IAA09583@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors from during dictionary lookup. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Thu Aug 24 16:32:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 08:32:28 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008241532.IAA09998@delerium.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Open Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 16:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 17:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 17:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- Date: 2000-Aug-24 17:19 By: montanaro Comment: try "man 1 test". -nt is actually an argument to the test command. Bash's builtin test command does support -nt. ------------------------------------------------------- Date: 2000-Aug-24 17:32 By: twouters Comment: BSDI 'test' does not support -nt. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 24 16:53:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 08:53:07 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008241553.IAA10778@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 11:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Thu Aug 24 16:54:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 08:54:19 -0700 Subject: [Patches] [Patch #101278] Enable --program-suffix option in configure for Cygwin et. a Message-ID: <200008241554.IAA10884@delerium.i.sourceforge.net> Patch #101278 has been updated. Project: Category: Build Status: Open Summary: Enable --program-suffix option in configure for Cygwin et. a ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101278&group_id=5470 From noreply@sourceforge.net Thu Aug 24 17:00:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 09:00:58 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008241600.JAA11105@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 15:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 16:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Thu Aug 24 16:44:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 08:44:34 -0700 Subject: [Patches] [Patch #101277] Catch errors from during dictionary lookup. Message-ID: <200008241544.IAA20408@bush.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors from during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 11:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Thu Aug 24 15:23:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 07:23:06 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008241423.HAA17427@bush.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Open Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 10:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 24 17:33:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 09:33:05 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008241633.JAA12363@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 11:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 12:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 12:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Thu Aug 24 17:51:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 09:51:38 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008241651.JAA13041@delerium.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Open Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 10:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 11:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 11:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- Date: 2000-Aug-24 11:19 By: montanaro Comment: try "man 1 test". -nt is actually an argument to the test command. Bash's builtin test command does support -nt. ------------------------------------------------------- Date: 2000-Aug-24 11:32 By: twouters Comment: BSDI 'test' does not support -nt. ------------------------------------------------------- Date: 2000-Aug-24 12:51 By: montanaro Comment: In light of Thomas's comment about BSDI's test command, I recommend this patch be postponed until 2.1. It's minor enough. Still, we do need to prod people into comparing Setup.in with preexisting Setup files, otherwise we're going to get a lot of "not-a-bugs" once the software is made widely available. find(1) has a -newer predicate. Is it safe enough to assume it's universally available on systems that can build with Python's Makefile? if [ "`find . -name Setup.in -newer Setup`" = "./Setup.in" ] then echo 'compare Setup and Setup.in for changes!' fi ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 24 18:01:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 10:01:34 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008241701.KAA23361@bush.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 15:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 16:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 16:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 17:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Thu Aug 24 18:03:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 10:03:24 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008241703.KAA23401@bush.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Postponed Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 10:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 11:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 11:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- Date: 2000-Aug-24 11:19 By: montanaro Comment: try "man 1 test". -nt is actually an argument to the test command. Bash's builtin test command does support -nt. ------------------------------------------------------- Date: 2000-Aug-24 11:32 By: twouters Comment: BSDI 'test' does not support -nt. ------------------------------------------------------- Date: 2000-Aug-24 12:51 By: montanaro Comment: In light of Thomas's comment about BSDI's test command, I recommend this patch be postponed until 2.1. It's minor enough. Still, we do need to prod people into comparing Setup.in with preexisting Setup files, otherwise we're going to get a lot of "not-a-bugs" once the software is made widely available. find(1) has a -newer predicate. Is it safe enough to assume it's universally available on systems that can build with Python's Makefile? if [ "`find . -name Setup.in -newer Setup`" = "./Setup.in" ] then echo 'compare Setup and Setup.in for changes!' fi ------------------------------------------------------- Date: 2000-Aug-24 13:03 By: fdrake Comment: Postponed for Python 2.1; assigned to the release manager to re-open after 2.0 is released. The use of find is more difficult; the whole thing must be inside a test that makes sure Setup already exists. Also, the test should be something closer to (untested): [ "`find $(srcdir) -name Setup.in -newer Setup`" = "$(srcdir)/Setup.in" ] ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 24 18:55:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 10:55:29 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008241755.KAA15564@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 11:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 12:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 12:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 13:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 13:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Thu Aug 24 19:02:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 11:02:46 -0700 Subject: [Patches] [Patch #101226] make threading fork-safe Message-ID: <200008241802.LAA25802@bush.i.sourceforge.net> Patch #101226 has been updated. Project: Category: core (C code) Status: Accepted Summary: make threading fork-safe Follow-Ups: Date: 2000-Aug-19 00:46 By: cgw Comment: See http://www.lambdacs.com/newsgroup/FAQ.html#Q120 and "man pthread_atfork" for background. I don't use a pthread_atfork handler here - the explicit approach is more portable. However calling fork() from C extensions could still cause trouble. This patch causes the child to create a new interpreter lock after doing a fork. It would be nice to deallocate the old lock with PyThread_free_lock, but this does some unwanted error-checking in addition to deallocating the lock. So I waste a little memory instead. To really do this cleanly one could add a new PyThread_reset_lock function to all the thread_*.h files, and use that instead. ------------------------------------------------------- Date: 2000-Aug-19 21:51 By: tim_one Comment: Assigned to me. I'll discuss it with Guido too. So far 2e've gotten 3 reports from people who don't see failures in assorted test cases anymore, and no reports of remaining failures. ------------------------------------------------------- Date: 2000-Aug-24 14:02 By: tim_one Comment: Accepted, and assigned to Jeremy for checkin. We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm. Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101226&group_id=5470 From noreply@sourceforge.net Thu Aug 24 19:19:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 11:19:17 -0700 Subject: [Patches] [Patch #101226] make threading fork-safe Message-ID: <200008241819.LAA26440@bush.i.sourceforge.net> Patch #101226 has been updated. Project: Category: core (C code) Status: Accepted Summary: make threading fork-safe Follow-Ups: Date: 2000-Aug-19 00:46 By: cgw Comment: See http://www.lambdacs.com/newsgroup/FAQ.html#Q120 and "man pthread_atfork" for background. I don't use a pthread_atfork handler here - the explicit approach is more portable. However calling fork() from C extensions could still cause trouble. This patch causes the child to create a new interpreter lock after doing a fork. It would be nice to deallocate the old lock with PyThread_free_lock, but this does some unwanted error-checking in addition to deallocating the lock. So I waste a little memory instead. To really do this cleanly one could add a new PyThread_reset_lock function to all the thread_*.h files, and use that instead. ------------------------------------------------------- Date: 2000-Aug-19 21:51 By: tim_one Comment: Assigned to me. I'll discuss it with Guido too. So far 2e've gotten 3 reports from people who don't see failures in assorted test cases anymore, and no reports of remaining failures. ------------------------------------------------------- Date: 2000-Aug-24 14:02 By: tim_one Comment: Accepted, and assigned to Jeremy for checkin. We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm. Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows. ------------------------------------------------------- Date: 2000-Aug-24 14:19 By: tim_one Comment: Accepted, and assigned to Jeremy for checkin. We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm. Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101226&group_id=5470 From noreply@sourceforge.net Thu Aug 24 19:11:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 11:11:53 -0700 Subject: [Patches] [Patch #101207] BeOS: installing of linker script Message-ID: <200008241811.LAA26191@bush.i.sourceforge.net> Patch #101207 has been updated. Project: Category: Build Status: Closed Summary: BeOS: installing of linker script Follow-Ups: Date: 2000-Aug-17 08:23 By: RLiebscher Comment: distutils uses the linker command found in config/Makefile. If BeOS uses a seperate linker script then this needs also to be installed. This patch changes Makefile.in to copy the BeOS directory in the python directory. Another solution would be to install the scripts right in the config directory as it is done for AIX. ------------------------------------------------------- Date: 2000-Aug-17 18:24 By: fdrake Comment: Please change this to work the same way as for AIX. The Distutils code may need to be adjusted to be able to locate the linkmodule script; please contribute a patch for that as well or post a bug report for distutils, so that Greg Ward can fix it. Thanks! ------------------------------------------------------- Date: 2000-Aug-24 14:11 By: fdrake Comment: Adjusted the location to match that used on other platforms, and add the "echo" statements to make it behave similarly to the AIX equivalent section. Checked in as Makefile.in revision 1.97. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101207&group_id=5470 From noreply@sourceforge.net Thu Aug 24 21:12:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 13:12:17 -0700 Subject: [Patches] [Patch #100699] Augmented Assignment, the Python Way (huge) Message-ID: <200008242012.NAA30823@bush.i.sourceforge.net> Patch #100699 has been updated. Project: Category: core (C code) Status: Closed Summary: Augmented Assignment, the Python Way (huge) Follow-Ups: Date: 2000-Jul-01 02:49 By: twouters Comment: This patch adds augmented assignment (+=, **=, etc) to Python, in a manner which seems consistent with Guido and Tim's wishes (for as far as I know them.) Guido has already stated this patch will not make it to Python 2.0, so the first to read this should probably set the state to 'postponed'. I'll try and keep this patch up to date none the less, for peer (or rather parent ;) reviewal. The patch adds everything in one smack: Syntax, a new type of bytecode (2-argument), 9 new bytecodes, 13 new API calls, 11 new PyNumber_Methods members, 2 new PySequence_Methods members, and support for the new functionality in builtin types and supplied Python classes. Oh, and a test suite. None the less, it isn't that intrusive a patch, and the simplicity of the implementation still boggles me. For more information, see http://www.xs4all.nl/~thomas/python/ Comments greatly appreciated! Contact me on thomas@xs4all.net (I'm not on python-dev) ------------------------------------------------------- Date: 2000-Jul-01 03:10 By: gvanrossum Comment: Cool! We'll look at this after 2.0 is released... ------------------------------------------------------- Date: 2000-Jul-13 22:53 By: jhylton Comment: This patch needs to be postponed until the PEP is written. ------------------------------------------------------- Date: 2000-Jul-25 15:37 By: gvanrossum Comment: Not ready to be checked in, but Thomas is working on it! This will be in 2.0 after all... ------------------------------------------------------- Date: 2000-Aug-06 14:33 By: twouters Comment: New version of the patch, that eliminates the need for 2-argument opcodes and the GETSET_* opcodes. Instead, INPLACE_* opcodes are used, that mirror the BINARY_* opcodes, and two new 'utility' opcodes: ROT_FOUR and DUP_TOPX (duplicates the top items on the stack.) The PEP documenting this implementation will follow soon. ------------------------------------------------------- Date: 2000-Aug-21 05:42 By: gvanrossum Comment: BDFL pronouncement: please use __iadd__, __imul__ etc. ------------------------------------------------------- Date: 2000-Aug-22 18:26 By: twouters Comment: Up to date version that incorporates the BDFL-Pronouncement to use __iadd__ rather than __add_ab__. Also made PyNumber_InPlacePower() a three-argument function (since normal Power() is one, and we can't change this functions' prototype later, if we would want to.) The three argument InPlacePower() does the normal batch of coercions, so it's not terribly likely to remain an 'in-place' operation :-S I'm working on docs, but on my laptop, not incorporated in this patch. Also, the testcase needs to be expanded a bit, and probably incorporated with the test_class testcase I added last week. ------------------------------------------------------- Date: 2000-Aug-23 17:42 By: gvanrossum Comment: Accepted. Please check it in. Then work on the docs. Please send us the docs even if you don't get to finish them!!! ------------------------------------------------------- Date: 2000-Aug-24 22:12 By: twouters Comment: This patch is being checked in right now. However, the patch as found here is not the same as the one being checked in: Guido suggested a better way to do the PyNumber_InPlace*() API functions, which also removes the biggest remaining issue from the PEP, and the patch going in implements that suggestion. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100699&group_id=5470 From noreply@sourceforge.net Thu Aug 24 21:10:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 13:10:37 -0700 Subject: [Patches] [Patch #100852] Add poll() to select module Message-ID: <200008242010.NAA30802@bush.i.sourceforge.net> Patch #100852 has been updated. Project: Category: Modules Status: Accepted Summary: Add poll() to select module Follow-Ups: Date: 2000-Jul-11 11:25 By: akuchling Comment: Derived from Sam Rushing's pollmodule.c that forms part of Medusa. Once I get a second opinion about the patch, I'll check it in. ------------------------------------------------------- Date: 2000-Jul-21 13:33 By: akuchling Comment: Updated version of the patch, which adds poll() to the select module. .register() and .unregister() add/remove fds, and .poll() performs the system call. Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored. Open question: should there be a function or attribute to get the list of registered fds? Still to do: write documentation, add the test case. ------------------------------------------------------- Date: 2000-Jul-25 00:54 By: akuchling Comment: Assigned to Jeremy for review; feel free to bounce it to someone else. ------------------------------------------------------- Date: 2000-Jul-25 17:25 By: akuchling Comment: Update patch to latest version, which adds poll() to the select() module. ------------------------------------------------------- Date: 2000-Jul-25 20:30 By: jhylton Comment: Several style nits changed, mostly to do with whitespace. Substantive changes: 1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens 2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND One more Open Issue: I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions: - interface to register many fds at once - keep the list of fds in sorted order - use a dict to store fds and generate fdarry lazily - keep track of allocated length and used length for ufds, so that fewer reallocs are required Each of these suggestions has some added complexity, so I'm not sure that I like any of them. ------------------------------------------------------- Date: 2000-Jul-25 20:41 By: akuchling Comment: I wondered about the linear search, too; it means balancing efficiency versus the lines of code to write this one object? IMHO implementing both #1 and #3 would be good; allow passing an arbitrary # of fds to register (and unregister?), store them in a dict, and then lazily generate the ufd array when needed. Or is there some built-in more suited than a dict for this? Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors. ------------------------------------------------------- Date: 2000-Jul-25 21:40 By: jhylton Comment: I think a dict is the right data structure, but I don't think it should be exposed directly. If it is not exposed, then the ufd array need only be generated for poll calls after a register or unregister. If there are multiple polls without a change, the same array can be re-used. ------------------------------------------------------- Date: 2000-Aug-13 04:13 By: akuchling Comment: Latest version, which stores an underlying dict as suggested in jhylton's previous comment. p.unregister() raises KeyError if you unregister a fd that wasn't registered in the first place; seem reasonable? It does to me... The code should now be completed; the only remaining task is to write docstrings and finish the documentation patch. ------------------------------------------------------- Date: 2000-Aug-15 17:36 By: tim_one Comment: Tickling you as part of 2.0 nagging. Please leave a note saying when you intend to "write docstrings and finish the documentation". ------------------------------------------------------- Date: 2000-Aug-16 00:57 By: akuchling Comment: Revised version -- documentation & docstrings completed, and there's a test script (not part of patch). Ready to check in once someone gives the patch a quick once-over and sanity check. ------------------------------------------------------- Date: 2000-Aug-16 02:38 By: tim_one Comment: Assigned to Barry for a quick once-over and sanity check, as he's looking at the socket code and "select" also begins with an "s", while the "p" in "poll" doesn't show up in "Cravin' Dogs" at all! A natural fit. ------------------------------------------------------- Date: 2000-Aug-24 20:10 By: jhylton Comment: Suggested revisions, including regression test. Defer to Andrew on whether to apply these changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 From noreply@sourceforge.net Thu Aug 24 22:27:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 14:27:43 -0700 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <200008242127.OAA23515@delerium.i.sourceforge.net> Patch #101137 has been updated. Project: Category: Modules Status: Postponed Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2000-Aug-09 21:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 22:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway . ------------------------------------------------------- Date: 2000-Aug-24 21:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Thu Aug 24 22:31:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 14:31:23 -0700 Subject: [Patches] [Patch #101278] Enable --program-suffix option in configure for Cygwin et. a Message-ID: <200008242131.OAA23670@delerium.i.sourceforge.net> Patch #101278 has been updated. Project: Category: Build Status: Open Summary: Enable --program-suffix option in configure for Cygwin et. a ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101278&group_id=5470 From noreply@sourceforge.net Thu Aug 24 22:49:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 14:49:37 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008242149.OAA24426@delerium.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Postponed Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 16:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 17:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 17:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- Date: 2000-Aug-24 17:19 By: montanaro Comment: try "man 1 test". -nt is actually an argument to the test command. Bash's builtin test command does support -nt. ------------------------------------------------------- Date: 2000-Aug-24 17:32 By: twouters Comment: BSDI 'test' does not support -nt. ------------------------------------------------------- Date: 2000-Aug-24 18:51 By: montanaro Comment: In light of Thomas's comment about BSDI's test command, I recommend this patch be postponed until 2.1. It's minor enough. Still, we do need to prod people into comparing Setup.in with preexisting Setup files, otherwise we're going to get a lot of "not-a-bugs" once the software is made widely available. find(1) has a -newer predicate. Is it safe enough to assume it's universally available on systems that can build with Python's Makefile? if [ "`find . -name Setup.in -newer Setup`" = "./Setup.in" ] then echo 'compare Setup and Setup.in for changes!' fi ------------------------------------------------------- Date: 2000-Aug-24 19:03 By: fdrake Comment: Postponed for Python 2.1; assigned to the release manager to re-open after 2.0 is released. The use of find is more difficult; the whole thing must be inside a test that makes sure Setup already exists. Also, the test should be something closer to (untested): [ "`find $(srcdir) -name Setup.in -newer Setup`" = "$(srcdir)/Setup.in" ] ------------------------------------------------------- Date: 2000-Aug-24 23:49 By: twouters Comment: Eep, don't use find. Find has more platform-specific issues than has 'test'! (Don't get me started on BSDI find, please ;) However, I'm getting the feeling this is re-inventing the wheel. 'make' was intended for this kind of thing! And it already does the modified-time check and such: if Setup.in isn't newer than the existing Setup, the body of the rule shouldn't get called. Isn't it enough to test whether there already exists a Setup, and produce a warning if so ? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 24 22:56:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 14:56:43 -0700 Subject: [Patches] [Patch #101284] dis.py does not know DUP_TOPX Message-ID: <200008242156.OAA02665@bush.i.sourceforge.net> Patch #101284 has been updated. Project: Category: library Status: Open Summary: dis.py does not know DUP_TOPX ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101284&group_id=5470 From noreply@sourceforge.net Thu Aug 24 22:58:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 14:58:33 -0700 Subject: [Patches] [Patch #101214] Improve exception message for PyErr_BadInternalCall() Message-ID: <200008242158.OAA24661@delerium.i.sourceforge.net> Patch #101214 has been updated. Project: Category: core (C code) Status: Accepted Summary: Improve exception message for PyErr_BadInternalCall() Follow-Ups: Date: 2000-Aug-18 03:25 By: fdrake Comment: This patch uses a macro wrapper to provide the filename and line number of the call to PyErr_BadInternalCall(). This should be reasonable since the __FILE__ and __LINE__ macros are ANSI C (I think). There are 77 call sites for PyErr_BadInternalCall(), and this would make it a lot easier to get an initial foothold on errors generated through this function. ------------------------------------------------------- Date: 2000-Aug-18 11:15 By: marangoz Comment: OTOH, bad internal calls shouldn't happen, but I like this. You want to make my life easier as a developer, not as a user. +0, modulo the fact that you removed the original function from the API. External modules may fail. Let's keep the original function and its signature in the code. (this requires some preprocessor trickery). ------------------------------------------------------- Date: 2000-Aug-18 14:42 By: fdrake Comment: Add PyErr_BadInternalCall() entry point back for legacy compiled code, but continue to mask it for new code. ------------------------------------------------------- Date: 2000-Aug-19 17:13 By: marangoz Comment: Where's the legacy PyErr_BadInternalCall(void) *function* ? Try again :-) error.c: #undef PyErr_BadInternalCall void PyErr_BadInternalCall(void) { PyErr_SetString(PyExc_SystemError, "bad argument to internal function"); } void _PyErr_BadInternalCall(char *filename, int lineno) { PyErr_Format(PyExc_SystemError, "%s:%d: bad argument to internal function", filename, lineno); } ------------------------------------------------------- Date: 2000-Aug-19 17:37 By: fdrake Comment: Ok, here 'tis... forgot to regenerate the patch before uploading it last time. Sorry! ;-( ------------------------------------------------------- Date: 2000-Aug-20 04:24 By: tim_one Comment: Assigned to Vladimir since his is the natural next voice. ------------------------------------------------------- Date: 2000-Aug-24 00:53 By: fdrake Comment: Assigned to Jeremy since Vladimir is away travelling for a bit. Please review. ------------------------------------------------------- Date: 2000-Aug-24 21:58 By: jhylton Comment: Looks good ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101214&group_id=5470 From noreply@sourceforge.net Thu Aug 24 22:58:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 14:58:50 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008242158.OAA24757@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 15:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 16:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 16:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 17:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 17:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Thu Aug 24 23:00:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 15:00:15 -0700 Subject: [Patches] [Patch #101284] dis.py does not know DUP_TOPX Message-ID: <200008242200.PAA24796@delerium.i.sourceforge.net> Patch #101284 has been updated. Project: Category: library Status: Accepted Summary: dis.py does not know DUP_TOPX ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101284&group_id=5470 From noreply@sourceforge.net Thu Aug 24 23:02:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 15:02:13 -0700 Subject: [Patches] [Patch #101211] list comprehensions: require initial for clause Message-ID: <200008242202.PAA24828@delerium.i.sourceforge.net> Patch #101211 has been updated. Project: Category: Parser/Compiler Status: Closed Summary: list comprehensions: require initial for clause Follow-Ups: Date: 2000-Aug-17 15:55 By: montanaro Comment: Description of the patch in the patch itself. ------------------------------------------------------- Date: 2000-Aug-21 20:03 By: tim_one Comment: Skip, did you and/or Ping track down the problem you thought there might be with this? Or am I misremembering email? (Ironic note: we moved to the SF patch manager so discussions wouldn't get lost!) ------------------------------------------------------- Date: 2000-Aug-21 21:14 By: montanaro Comment: Yes, Ping found and fixed the problem. The patch that I submitted should do the right thing. I'm reassigning it to Guido for his pronouncement. I believe it's ready to go. (I am still pretty unclear on the sequence of events that are required to take a patch from idea to cvs checkin...) ------------------------------------------------------- Date: 2000-Aug-21 21:24 By: gvanrossum Comment: Thanks! To both of you. Also for the doc additions. Skip, please check it in and then set the status to Closed. When you submit a patch (or update one), it's best to leave it unassigned or assign it to the release manager (today still Tim, after tomorrow Jeremy). If it *needs* BDFL pronouncement, the release manager will assign it to me with appropriate comments. Note: the patch part for graminit.c failed -- you may want to run pgen again before you check it in. ------------------------------------------------------- Date: 2000-Aug-21 21:29 By: tim_one Comment: Thanks, Skip! Have you read http://python.sourceforge.net/sf-faq.html#a1 ? If there's something about the patch process that wasn't answered there, let me know. I must say that, from my POV as "interim release manager" the past couple weeks, few people are playing along with the intent -- it's like nothing *moves* unless I step in to kick, prod or harass. You assigning this to the person *you* believe should take the next step is exactly how it's supposed to work. Thanks for taking the initiative! ------------------------------------------------------- Date: 2000-Aug-21 21:37 By: tim_one Comment: Assigned back to Skip since Guido Pronounced. Please feel free to check it in and Close it after addressing his comments. ------------------------------------------------------- Date: 2000-Aug-21 21:39 By: tim_one Comment: AHA! A SourceForge insecurity: I'm deducing from the log that Guido changed the status to Accepted when he wrote his last comment, but I was writing a comment at the same time but without changing the status, and a submitted after he did. So ended up undoing his status change without knowing it! Changed Status back to Accepted. ------------------------------------------------------- Date: 2000-Aug-21 22:52 By: montanaro Comment: changes have been checked in. Lib/test/test_parser.py breaks, but I forwarded a context diff to Fred Drake, who's been working on that module. ------------------------------------------------------- Date: 2000-Aug-21 23:03 By: montanaro Comment: forgot to reassign to Fred for documentation checks... ------------------------------------------------------- Date: 2000-Aug-23 12:58 By: fdrake Comment: The parser module has been with a different patch, so test_parser passes once again. The first hunk of the ref5.tex patch maintains the existing use of double quotes to mark keywords ("if"); this should be changed to use \keyword (\keyword{if}). Please make this change and check it in without another round of review. ------------------------------------------------------- Date: 2000-Aug-24 18:02 By: montanaro Comment: sorry for the delay. i've only been paying attention to "open" patches. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101211&group_id=5470 From noreply@sourceforge.net Thu Aug 24 23:15:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 15:15:40 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008242215.PAA25348@delerium.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Postponed Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 10:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 11:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 11:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- Date: 2000-Aug-24 11:19 By: montanaro Comment: try "man 1 test". -nt is actually an argument to the test command. Bash's builtin test command does support -nt. ------------------------------------------------------- Date: 2000-Aug-24 11:32 By: twouters Comment: BSDI 'test' does not support -nt. ------------------------------------------------------- Date: 2000-Aug-24 12:51 By: montanaro Comment: In light of Thomas's comment about BSDI's test command, I recommend this patch be postponed until 2.1. It's minor enough. Still, we do need to prod people into comparing Setup.in with preexisting Setup files, otherwise we're going to get a lot of "not-a-bugs" once the software is made widely available. find(1) has a -newer predicate. Is it safe enough to assume it's universally available on systems that can build with Python's Makefile? if [ "`find . -name Setup.in -newer Setup`" = "./Setup.in" ] then echo 'compare Setup and Setup.in for changes!' fi ------------------------------------------------------- Date: 2000-Aug-24 13:03 By: fdrake Comment: Postponed for Python 2.1; assigned to the release manager to re-open after 2.0 is released. The use of find is more difficult; the whole thing must be inside a test that makes sure Setup already exists. Also, the test should be something closer to (untested): [ "`find $(srcdir) -name Setup.in -newer Setup`" = "$(srcdir)/Setup.in" ] ------------------------------------------------------- Date: 2000-Aug-24 17:49 By: twouters Comment: Eep, don't use find. Find has more platform-specific issues than has 'test'! (Don't get me started on BSDI find, please ;) However, I'm getting the feeling this is re-inventing the wheel. 'make' was intended for this kind of thing! And it already does the modified-time check and such: if Setup.in isn't newer than the existing Setup, the body of the rule shouldn't get called. Isn't it enough to test whether there already exists a Setup, and produce a warning if so ? ------------------------------------------------------- Date: 2000-Aug-24 18:15 By: montanaro Comment: doh! I think Thomas is onto something... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 24 23:03:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 15:03:54 -0700 Subject: [Patches] [Patch #101284] dis.py does not know DUP_TOPX Message-ID: <200008242203.PAA24951@delerium.i.sourceforge.net> Patch #101284 has been updated. Project: Category: library Status: Accepted Summary: dis.py does not know DUP_TOPX Follow-Ups: Date: 2000-Aug-24 22:03 By: jhylton Comment: DUP_TOPX is part of the augmented assignment patch; make sure dis knows about all the new opcodes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101284&group_id=5470 From noreply@sourceforge.net Thu Aug 24 23:49:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 15:49:07 -0700 Subject: [Patches] [Patch #101284] dis.py does not know DUP_TOPX Message-ID: <200008242249.PAA26603@delerium.i.sourceforge.net> Patch #101284 has been updated. Project: Category: library Status: Closed Summary: dis.py does not know DUP_TOPX Follow-Ups: Date: 2000-Aug-25 00:03 By: jhylton Comment: DUP_TOPX is part of the augmented assignment patch; make sure dis knows about all the new opcodes. ------------------------------------------------------- Date: 2000-Aug-25 00:24 By: loewis Comment: Doing [x for x in dis.opname if x[0]=='<'] reveals that only ROT_FOUR was still missing; the update patch fixes that as well. ------------------------------------------------------- Date: 2000-Aug-25 00:49 By: twouters Comment: Damn, I was sure I fixed this. Having the entire augassign patch lying around for months aparently made me drop some stiches left and right. Fixed. Thanx for the reminder. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101284&group_id=5470 From noreply@sourceforge.net Thu Aug 24 23:39:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 15:39:31 -0700 Subject: [Patches] [Patch #101214] Improve exception message for PyErr_BadInternalCall() Message-ID: <200008242239.PAA26234@delerium.i.sourceforge.net> Patch #101214 has been updated. Project: Category: core (C code) Status: Closed Summary: Improve exception message for PyErr_BadInternalCall() Follow-Ups: Date: 2000-Aug-17 23:25 By: fdrake Comment: This patch uses a macro wrapper to provide the filename and line number of the call to PyErr_BadInternalCall(). This should be reasonable since the __FILE__ and __LINE__ macros are ANSI C (I think). There are 77 call sites for PyErr_BadInternalCall(), and this would make it a lot easier to get an initial foothold on errors generated through this function. ------------------------------------------------------- Date: 2000-Aug-18 07:15 By: marangoz Comment: OTOH, bad internal calls shouldn't happen, but I like this. You want to make my life easier as a developer, not as a user. +0, modulo the fact that you removed the original function from the API. External modules may fail. Let's keep the original function and its signature in the code. (this requires some preprocessor trickery). ------------------------------------------------------- Date: 2000-Aug-18 10:42 By: fdrake Comment: Add PyErr_BadInternalCall() entry point back for legacy compiled code, but continue to mask it for new code. ------------------------------------------------------- Date: 2000-Aug-19 13:13 By: marangoz Comment: Where's the legacy PyErr_BadInternalCall(void) *function* ? Try again :-) error.c: #undef PyErr_BadInternalCall void PyErr_BadInternalCall(void) { PyErr_SetString(PyExc_SystemError, "bad argument to internal function"); } void _PyErr_BadInternalCall(char *filename, int lineno) { PyErr_Format(PyExc_SystemError, "%s:%d: bad argument to internal function", filename, lineno); } ------------------------------------------------------- Date: 2000-Aug-19 13:37 By: fdrake Comment: Ok, here 'tis... forgot to regenerate the patch before uploading it last time. Sorry! ;-( ------------------------------------------------------- Date: 2000-Aug-20 00:24 By: tim_one Comment: Assigned to Vladimir since his is the natural next voice. ------------------------------------------------------- Date: 2000-Aug-23 20:53 By: fdrake Comment: Assigned to Jeremy since Vladimir is away travelling for a bit. Please review. ------------------------------------------------------- Date: 2000-Aug-24 17:58 By: jhylton Comment: Looks good ------------------------------------------------------- Date: 2000-Aug-24 18:39 By: fdrake Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101214&group_id=5470 From noreply@sourceforge.net Fri Aug 25 00:33:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 16:33:29 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008242333.QAA05955@bush.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Open Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 20:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 21:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-16 06:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-16 06:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 07:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 09:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 09:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-22 01:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- Date: 2000-Aug-22 04:41 By: moshez Comment: Actually, it's now waiting for someone's pronouncement -- Guido had a problem with .get() and __getitem__ not being equivalent (the first does an implicit .value). Ping and I thought it best that way, but if the BDFL has strong feelings otherwise, he should pronounce. Assigned to him for final verdict. ------------------------------------------------------- Date: 2000-Aug-22 20:46 By: ping Comment: On Fri, 18 Aug 2000, Guido van Rossum wrote: > If I understand the discussion below correctly, to get the > value for 'foo' you must use > > x['foo'].value > > but now you can also use > > x.get('foo') This is true. > ??? That's inconsistent compared to how these two behave for regular > dictionaries! I mulled this over a while when doing the patch. Initially, i did make form.get(x) behave exactly like form[x], and proceeded to try to make the FieldStorage object behave as much like a dictionary as possible (since the docs say it can be "accessed like a dictionary"). FormContentDict and its descendants clearly behave like a dictionary since they are derived from UserDict. But as i investigated FieldStorage further, i found that it actually lacks lots of dictionary behaviour: no update(), no clear(), no copy(), no items(), no values(). The only dictionary-like semantics we really care about are [key], keys(), and has_key(). Implementing items() and values() would require an uncertain choice, since the FieldStorage represents a multimap: do multi-valued fields appear as multiple key-value pairs with the same key, or a single pair with a list for its value? In the end, i decided to abandon true dictionary-like behaviour, because the thing being represented is a bit too much more than a dictionary. By far the most common use of the FieldStorage (and even the entire cgi module) is just to decode simple strings from single-valued form fields, and the interface should do its best to facilitate that common use. I decided it was okay to break consistency with regular dictionaries (a) as long as the behaviour is clearly documented and (b) since it doesn't fully satisfy one's expectations of a dictionary anyway. Moshe's response drove home the point when he demonstrated that the advantage of get() -- to provide a default when a value is missing -- is overwhelmed by the awkwardness of the .value interface. If get() returns a MiniFieldStorage, then to default the "spam" field to "eggs" i have to say field = form.get("spam", "eggs") if type(field) is type(""): process(field) else: process(field.value) or field = form.get("spam", None) if field is None: process("eggs") else: process(field.value) or field = form.get("spam", cgi.MiniFieldStorage("spam", "eggs")) process(field.value) which are hardly any better than if form.has_key("spam"): process(form["spam"].value) else: process("eggs") at all! If get() returns a string, then i can just say process(form.get("spam", "eggs")) and i can be on my way. I have personally stayed away from FieldStorage because it's so annoying to use; having to look up the "value" attribute on every form field makes programs verbose and awkward. This gets worse when a field has multple values. In fact, the usage example provided in Doc/lib/libcgi.tex is a perfect demonstration: username = form["username"] if type(username) is type([]): usernames = "" for item in username: if username: usernames = usernames + "," + item.value else: usernames = item.value else: usernames = username.value The above can be shortened somewhat with map(), but with the new get() method, this can simply be written in the obvious way: value = form.get("username", "") if type(value) is type([]): usernames = ",".join(value) else: usernames = value (The latter is what you would do with a FormContentDict, which is why i find it so vastly more convenient than the FieldStorage. It's slightly better, though: it also painlessly handles the case where the "username" field is not present.) As mentioned earlier, i'm more concerned about the default setting for keep_blank_values. The message i wrote providing a complete explanation of this issue is included below so you don't have to search through old e-mail to find it. -- ?!ng -------- the headers of the original message -------- >From ping@lfw.org Tue Aug 22 12:18:57 2000 Date: Wed, 16 Aug 2000 02:31:48 -0700 (PDT) From: Ka-Ping Yee To: Moshe Zadka , bwarsaw@beopen.com, tpeters@beopen.com Subject: Re: [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict -------- the message body, with some edits -------- Hi, guys. This patch includes a "fix" to make cgi.parse_qsl honour its "keep_blank_values" argument. This fix might require a bit more discussion since it could break compatibility, so i thought i would air it for your consideration. BACKGROUND ---------- cgi.FieldStorage(), cgi.parse(), cgi.parse_qs(), and cgi.parse_qsl() all accept an optional "keep_blank_values" argument which is supposed to indicate whether form fields with empty strings as values should be included in the result. In reality, only cgi.parse_qs() honours this flag (cgi.parse() is okay because it uses cgi.parse_qs()). cgi.parse_qsl() totally ignores it, and always includes all values including empty ones. cgi.FieldStorage(), which uses cgi.parse_qsl(), similarly does not honour the "keep_blank_values" flag. The patch contains a fix to make cgi.parse_qsl() honour this flag. FOR --- It's clear that this was the intent of the "keep_blank_values" argument. The doc string for parse_qsl says: """Parse a query given as a string argument. Arguments: qs: URL-encoded query string to be parsed keep_blank_values: flag indicating whether blank values in URL encoded queries should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. Returns a list, as God intended. """ Its current disregard for "keep_blank_values" clearly contradicts this doc string. The doc string for FieldStorage.__init__ says: """Constructor. Read multipart/* until last part. Arguments, all optional: fp : file pointer; default: sys.stdin (not used when the request method is GET) headers : header dictionary-like object; default: taken from environ as per CGI spec outerboundary : terminating multipart boundary (for internal use only) environ : environment dictionary; default: os.environ keep_blank_values: flag indicating whether blank values in URL encoded forms should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. """ ...and the current behaviour of FieldStorage.__init__ contradicts what it says here about "keep_blank_values". AGAINST ------- Existing code which uses FieldStorage and relies on its current behaviour could break. If a form field is left blank by the user and the form is submitted, that key will not appear in the FieldStorage -- and an attempt to index it with form[key] will produce a KeyError where previously it yielded a MiniFieldStorage containing an empty string. The existing TeX documentation for the cgi module does not mention empty values or the keep_blank_values argument at all, so to those who have only read the library reference manual, this could be a surprise. OPTIONS ------- The reason this never showed up before is that there have never been *any* tests for FieldStorage in test_cgi.py! Naughty, naughty. One easy way to maintain compatibility is to change FieldStorage so that the default value for keep_blank_values is 1 (previously this was 0 but the FieldStorage *acted* as though it were 1). ------------------------------------------------------- Date: 2000-Aug-23 16:35 By: jhylton Comment: Since we are in feature freeze, let's not worry about whether we should have a get method or not. Please limit this patch to bug fixes and re-submit. I'll be happy to accept. Let's do a more thorough job of revising this module for 2.1. It looks amazingly complicated to me. ------------------------------------------------------- Date: 2000-Aug-24 08:27 By: ping Comment: Hi, Jeremy. I actually think the motivations for these changes are pretty clear. They directly address two things: 1. The doc strings say keep_blank_values is supposed to control whether blank values are kept. This currently doesn't work at all. 2. The TeX documentation says the FieldStorage object is supposed to behave like a dictionary. Dictionaries are expected to provide a .get() method, but the FieldStorage doesn't. Both of these things are basically bugs. The only decisions that remain have to do with backward compatibility when we fix #1 -- this is easily addressed by defaulting keep_blank_values to 1 -- and with determining the most effective way to implement .get() when we fix #2. The implementation of .get() in this patch greatly simplifies most CGI scripts. As shown in the examples in my previous comment, it can reduce four or five lines of mucking with the .value attribute to a single call. -- ?!ng ------------------------------------------------------- Date: 2000-Aug-24 12:57 By: moshez Comment: Guido: Adding the functionality you want is great, but it shouldn't be called get(). Call it getvalue() and I'm happy. The words "behave like a dictionary" have such a vague meaning that lacking a get() method can't be seen as a violation. However having a get() method that does something different *is* a violation! ------------------------------------------------------- Date: 2000-Aug-24 12:58 By: moshez Comment: OK, that seems fine, but in this case, FieldStorage shouldn't have a "get", only "getvalue". ------------------------------------------------------- Date: 2000-Aug-24 23:33 By: ping Comment: Agreed. I have removed get() and replaced it with getvalue(). The documentation and test have been updated accordingly. Also, i discovered that the compatibility issue about keep_blank_values is a red herring. In fact, keep_blank_values *did* previously work as documented in Python 1.5.2 -- it looks like it got *broken* by some patch in between then and now. This patch fixes the breakage. That resolves all the issues, so i think this is ready to go. Jeremy? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From ping@lfw.org Fri Aug 25 00:34:51 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 24 Aug 2000 19:34:51 -0400 (EDT) Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict In-Reply-To: <200008241336.IAA01629@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 24 Aug 2000, Guido van Rossum wrote: > > It may be me, but I'm getting annoyed by this. For any object that > implements a partial mapping protocol, any mapping methods that it > implement should behave according to the mapping protocol, and be > consistent with the others. I apologize. You're totally right -- i've renamed the get() method to getvalue(). Don't know why i didn't see previously that it should be done this way. I'm sorry for the annoyance. I've updated the patch. -- ?!ng From jeremy@beopen.com Fri Aug 25 00:56:04 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 24 Aug 2000 19:56:04 -0400 (EDT) Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict In-Reply-To: References: <200008241336.IAA01629@cj20424-a.reston1.va.home.com> Message-ID: <14757.46612.421234.942465@bitdiddle.concentric.net> I'd be happiest if we limited the changes to the cgi module to bug fixes. We are in feature freeze now, which means that features -- even ones that make CGI scripting easier -- should be postponed. Jeremy From noreply@sourceforge.net Fri Aug 25 02:49:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 18:49:53 -0700 Subject: [Patches] [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing Message-ID: <200008250149.SAA10697@bush.i.sourceforge.net> Patch #101272 has been updated. Project: Category: Modules Status: Open Summary: Allow bsddbmodule.c to compile with libdb 2.x w/o editing Follow-Ups: Date: 2000-Aug-23 19:22 By: montanaro Comment: Eric's been doing lots w/ libdb stuff lately. I'll see if he want's to check this patch out... ;-) ------------------------------------------------------- Date: 2000-Aug-23 20:01 By: fdrake Comment: Update patch to also determine whether the bsddb module should be built at all automatically (adding a stanza to Setup.config.in and a comment to Setup.in). This won't detect all cases automatically, but will catch it on platforms which have it installed as part of the base system (same as for the original patch). ------------------------------------------------------- Date: 2000-Aug-23 20:02 By: fdrake Comment: I'd better note that this still needs testing on a system that only offers BSD db 1.85. ------------------------------------------------------- Date: 2000-Aug-23 20:24 By: montanaro Comment: I'm afraid that's beyond my feeble autoconf/configure skills. libdb.a is hardly installed in a standard location on all systems. The Setup.config.in line would be more involved than @USE_BSDDB_MODULE@bsddb bsddbmodule.c -ldb (though that would work on my Mandrake Linux system). I suspect many people still have to install libdb themselves, so it could wind up just about anywhere. You'd have to teach autoconf to reliably find libdb.a then add a line to Setup.config.in that has the correct -L flag. ------------------------------------------------------- Date: 2000-Aug-23 20:39 By: fdrake Comment: This is sufficient for all cases that the header detection can deal with. We could (& perhaps should) add the necessary test to make sure -ldb works. For BSD db installs that aren't picked up this way, the stanza in Setup.in remains, and can be edited in Setup or provided in Setup.local. ------------------------------------------------------- Date: 2000-Aug-24 08:17 By: montanaro Comment: Okay, this patch goes a bit farther. Here's a quick summary: 1. It adds a line to Modules/Setup.config.in for the bsddb module, prefixed with USE_BSDDB_MODULE. 2. Configure gains a --with-libdb flag. If either --with-libdb is added to the command line or db.h is found, the bsddb module will be enabled. Of course, running configure using --without-libdb will disable it. 3. There's a comment in Setup.in about the new way of enabling the bsddb module, but the old commented out lines are still there. 4. If db_185.h is found, it's included instead of db.h. Both #includes are protected by their relevant HAVE_* defines in Modules/bsddbmodule.c (or should I let the db.h include fail?). 5. No attempt is made to search for libdb.h. It's assumed that if users install it in some odd location they will run configure with the --libdir and/or --includedir flags. Still needs testing on a 1.85/1.86 libdb. ------------------------------------------------------- Date: 2000-Aug-24 18:49 By: montanaro Comment: A new version of the patch to keep pace with other changes to the configure.in file ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101272&group_id=5470 From noreply@sourceforge.net Fri Aug 25 03:04:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 19:04:58 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008250204.TAA00787@delerium.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Open Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 07:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 08:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 08:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- Date: 2000-Aug-24 08:19 By: montanaro Comment: try "man 1 test". -nt is actually an argument to the test command. Bash's builtin test command does support -nt. ------------------------------------------------------- Date: 2000-Aug-24 08:32 By: twouters Comment: BSDI 'test' does not support -nt. ------------------------------------------------------- Date: 2000-Aug-24 09:51 By: montanaro Comment: In light of Thomas's comment about BSDI's test command, I recommend this patch be postponed until 2.1. It's minor enough. Still, we do need to prod people into comparing Setup.in with preexisting Setup files, otherwise we're going to get a lot of "not-a-bugs" once the software is made widely available. find(1) has a -newer predicate. Is it safe enough to assume it's universally available on systems that can build with Python's Makefile? if [ "`find . -name Setup.in -newer Setup`" = "./Setup.in" ] then echo 'compare Setup and Setup.in for changes!' fi ------------------------------------------------------- Date: 2000-Aug-24 10:03 By: fdrake Comment: Postponed for Python 2.1; assigned to the release manager to re-open after 2.0 is released. The use of find is more difficult; the whole thing must be inside a test that makes sure Setup already exists. Also, the test should be something closer to (untested): [ "`find $(srcdir) -name Setup.in -newer Setup`" = "$(srcdir)/Setup.in" ] ------------------------------------------------------- Date: 2000-Aug-24 14:49 By: twouters Comment: Eep, don't use find. Find has more platform-specific issues than has 'test'! (Don't get me started on BSDI find, please ;) However, I'm getting the feeling this is re-inventing the wheel. 'make' was intended for this kind of thing! And it already does the modified-time check and such: if Setup.in isn't newer than the existing Setup, the body of the rule shouldn't get called. Isn't it enough to test whether there already exists a Setup, and produce a warning if so ? ------------------------------------------------------- Date: 2000-Aug-24 15:15 By: montanaro Comment: doh! I think Thomas is onto something... ------------------------------------------------------- Date: 2000-Aug-24 19:04 By: montanaro Comment: Thomas was correct. I reworked the patch and sent a copy to Fred. I think this patch will ward off a lot of spurious "2.0 won't build" messages in c.l.py and should - for that reason alone - be added to 2.0. People are going to try building 2.0 with 1.5 Setup files. Socket at least won't build without some Setup file tweaks. I'm reopening it and assigning it back to Fred. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Fri Aug 25 04:06:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 20:06:14 -0700 Subject: [Patches] [Patch #101226] make threading fork-safe Message-ID: <200008250306.UAA13329@bush.i.sourceforge.net> Patch #101226 has been updated. Project: Category: core (C code) Status: Open Summary: make threading fork-safe Follow-Ups: Date: 2000-Aug-18 21:46 By: cgw Comment: See http://www.lambdacs.com/newsgroup/FAQ.html#Q120 and "man pthread_atfork" for background. I don't use a pthread_atfork handler here - the explicit approach is more portable. However calling fork() from C extensions could still cause trouble. This patch causes the child to create a new interpreter lock after doing a fork. It would be nice to deallocate the old lock with PyThread_free_lock, but this does some unwanted error-checking in addition to deallocating the lock. So I waste a little memory instead. To really do this cleanly one could add a new PyThread_reset_lock function to all the thread_*.h files, and use that instead. ------------------------------------------------------- Date: 2000-Aug-19 18:51 By: tim_one Comment: Assigned to me. I'll discuss it with Guido too. So far 2e've gotten 3 reports from people who don't see failures in assorted test cases anymore, and no reports of remaining failures. ------------------------------------------------------- Date: 2000-Aug-24 11:02 By: tim_one Comment: Accepted, and assigned to Jeremy for checkin. We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm. Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows. ------------------------------------------------------- Date: 2000-Aug-24 11:19 By: tim_one Comment: Accepted, and assigned to Jeremy for checkin. We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm. Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows. ------------------------------------------------------- Date: 2000-Aug-24 20:06 By: gvanrossum Comment: Don't check this in yet! Tim & I had a brainwave. We can share a single mutex for all locks and grab it around a fork, and the lock reinitialization won't be needed. (We think.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101226&group_id=5470 From noreply@sourceforge.net Fri Aug 25 05:09:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 21:09:29 -0700 Subject: [Patches] [Patch #101226] make threading fork-safe Message-ID: <200008250409.VAA15371@bush.i.sourceforge.net> Patch #101226 has been updated. Project: Category: core (C code) Status: Open Summary: make threading fork-safe Follow-Ups: Date: 2000-Aug-18 21:46 By: cgw Comment: See http://www.lambdacs.com/newsgroup/FAQ.html#Q120 and "man pthread_atfork" for background. I don't use a pthread_atfork handler here - the explicit approach is more portable. However calling fork() from C extensions could still cause trouble. This patch causes the child to create a new interpreter lock after doing a fork. It would be nice to deallocate the old lock with PyThread_free_lock, but this does some unwanted error-checking in addition to deallocating the lock. So I waste a little memory instead. To really do this cleanly one could add a new PyThread_reset_lock function to all the thread_*.h files, and use that instead. ------------------------------------------------------- Date: 2000-Aug-19 18:51 By: tim_one Comment: Assigned to me. I'll discuss it with Guido too. So far 2e've gotten 3 reports from people who don't see failures in assorted test cases anymore, and no reports of remaining failures. ------------------------------------------------------- Date: 2000-Aug-24 11:02 By: tim_one Comment: Accepted, and assigned to Jeremy for checkin. We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm. Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows. ------------------------------------------------------- Date: 2000-Aug-24 11:19 By: tim_one Comment: Accepted, and assigned to Jeremy for checkin. We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm. Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows. ------------------------------------------------------- Date: 2000-Aug-24 20:06 By: gvanrossum Comment: Don't check this in yet! Tim & I had a brainwave. We can share a single mutex for all locks and grab it around a fork, and the lock reinitialization won't be needed. (We think.) ------------------------------------------------------- Date: 2000-Aug-24 21:09 By: tim_one Comment: Now that I've had a chance to drive recklessly, suck down a Coke, and chain-smoke two butts in peace , I'm certain that the "one mutex" idea will work, and satisfied that the extra contention it may cause is pthread's own damn fault for presuming to kill threads in the child while they're in an unknown state. Full mutex ahead! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101226&group_id=5470 From noreply@sourceforge.net Fri Aug 25 08:54:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 00:54:09 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008250754.AAA22287@bush.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Fri Aug 25 09:21:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 01:21:26 -0700 Subject: [Patches] [Patch #101295] New tool msgfmt.py Message-ID: <200008250821.BAA12794@delerium.i.sourceforge.net> Patch #101295 has been updated. Project: Category: demos and tools Status: Open Summary: New tool msgfmt.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101295&group_id=5470 From noreply@sourceforge.net Fri Aug 25 13:29:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 05:29:28 -0700 Subject: [Patches] [Patch #101295] New tool msgfmt.py Message-ID: <200008251229.FAA31635@bush.i.sourceforge.net> Patch #101295 has been updated. Project: Category: demos and tools Status: Open Summary: New tool msgfmt.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101295&group_id=5470 From noreply@sourceforge.net Fri Aug 25 13:49:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 05:49:38 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008251249.FAA32265@bush.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- Date: 2000-Aug-25 05:49 By: fdrake Comment: Performance has *not* been checked -- there's no need to do that until the patch *works*. I understand the performance issue here; Guido and I have turnned this one around a few times and it's just plain hard to get right. One thing to recall is that the current implementation is broken as well; try the test case Jeremy submitted when he filed the bug report. (Keep in mind that I'm calling this patch "NOT READY" still -- I have no intention of checking this in as it stands.) Clearing exceptions in the comparison is clearly a bad thing, but they're getting raised in a chunk of code that simply doesn't allow raising exceptions. This is not well explained in the comments; I'll try to improve them. One issue with the problem is that and exception in the comparison can cause us not to find the entry we're looking for; during C-level exception handling, we're still trying to propogate another exception as well. Even if the general solution proves too slow for use with the module dictionaries (which will require testing to determine), I have some ideas about what it would take to make those fast anyway. I'll describe those later on python-dev. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Fri Aug 25 14:07:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 06:07:48 -0700 Subject: [Patches] [Patch #101298] Enable Py_DEBUG via configure Message-ID: <200008251307.GAA00457@bush.i.sourceforge.net> Patch #101298 has been updated. Project: Category: Build Status: Open Summary: Enable Py_DEBUG via configure Follow-Ups: Date: 2000-Aug-25 06:07 By: montanaro Comment: Assigned to Thomas so he doesn't need to keep editing config.h manually. ;-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101298&group_id=5470 From noreply@sourceforge.net Fri Aug 25 14:06:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 06:06:08 -0700 Subject: [Patches] [Patch #101298] Enable Py_DEBUG via configure Message-ID: <200008251306.GAA00332@bush.i.sourceforge.net> Patch #101298 has been updated. Project: Category: Build Status: Open Summary: Enable Py_DEBUG via configure ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101298&group_id=5470 From Moshe Zadka Fri Aug 25 14:15:46 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 25 Aug 2000 16:15:46 +0300 (IDT) Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict In-Reply-To: <14757.46612.421234.942465@bitdiddle.concentric.net> Message-ID: On Thu, 24 Aug 2000, Jeremy Hylton wrote: > I'd be happiest if we limited the changes to the cgi module to bug > fixes. We are in feature freeze now, which means that features -- > even ones that make CGI scripting easier -- should be postponed. The patch was in before the feature freeze.... -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From jeremy@beopen.com Fri Aug 25 14:53:54 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 25 Aug 2000 09:53:54 -0400 (EDT) Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict In-Reply-To: References: <14757.46612.421234.942465@bitdiddle.concentric.net> Message-ID: <14758.31346.254541.53822@bitdiddle.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> On Thu, 24 Aug 2000, Jeremy Hylton wrote: >> I'd be happiest if we limited the changes to the cgi module to >> bug fixes. We are in feature freeze now, which means that >> features -- even ones that make CGI scripting easier -- should be >> postponed. MZ> The patch was in before the feature freeze.... But it wasn't accepted... Jeremy From noreply@sourceforge.net Fri Aug 25 14:57:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 06:57:04 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008251357.GAA24080@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Accepted Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 13:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 14:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-15 23:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-15 23:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 00:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 02:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 02:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-21 18:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- Date: 2000-Aug-21 21:41 By: moshez Comment: Actually, it's now waiting for someone's pronouncement -- Guido had a problem with .get() and __getitem__ not being equivalent (the first does an implicit .value). Ping and I thought it best that way, but if the BDFL has strong feelings otherwise, he should pronounce. Assigned to him for final verdict. ------------------------------------------------------- Date: 2000-Aug-22 13:46 By: ping Comment: On Fri, 18 Aug 2000, Guido van Rossum wrote: > If I understand the discussion below correctly, to get the > value for 'foo' you must use > > x['foo'].value > > but now you can also use > > x.get('foo') This is true. > ??? That's inconsistent compared to how these two behave for regular > dictionaries! I mulled this over a while when doing the patch. Initially, i did make form.get(x) behave exactly like form[x], and proceeded to try to make the FieldStorage object behave as much like a dictionary as possible (since the docs say it can be "accessed like a dictionary"). FormContentDict and its descendants clearly behave like a dictionary since they are derived from UserDict. But as i investigated FieldStorage further, i found that it actually lacks lots of dictionary behaviour: no update(), no clear(), no copy(), no items(), no values(). The only dictionary-like semantics we really care about are [key], keys(), and has_key(). Implementing items() and values() would require an uncertain choice, since the FieldStorage represents a multimap: do multi-valued fields appear as multiple key-value pairs with the same key, or a single pair with a list for its value? In the end, i decided to abandon true dictionary-like behaviour, because the thing being represented is a bit too much more than a dictionary. By far the most common use of the FieldStorage (and even the entire cgi module) is just to decode simple strings from single-valued form fields, and the interface should do its best to facilitate that common use. I decided it was okay to break consistency with regular dictionaries (a) as long as the behaviour is clearly documented and (b) since it doesn't fully satisfy one's expectations of a dictionary anyway. Moshe's response drove home the point when he demonstrated that the advantage of get() -- to provide a default when a value is missing -- is overwhelmed by the awkwardness of the .value interface. If get() returns a MiniFieldStorage, then to default the "spam" field to "eggs" i have to say field = form.get("spam", "eggs") if type(field) is type(""): process(field) else: process(field.value) or field = form.get("spam", None) if field is None: process("eggs") else: process(field.value) or field = form.get("spam", cgi.MiniFieldStorage("spam", "eggs")) process(field.value) which are hardly any better than if form.has_key("spam"): process(form["spam"].value) else: process("eggs") at all! If get() returns a string, then i can just say process(form.get("spam", "eggs")) and i can be on my way. I have personally stayed away from FieldStorage because it's so annoying to use; having to look up the "value" attribute on every form field makes programs verbose and awkward. This gets worse when a field has multple values. In fact, the usage example provided in Doc/lib/libcgi.tex is a perfect demonstration: username = form["username"] if type(username) is type([]): usernames = "" for item in username: if username: usernames = usernames + "," + item.value else: usernames = item.value else: usernames = username.value The above can be shortened somewhat with map(), but with the new get() method, this can simply be written in the obvious way: value = form.get("username", "") if type(value) is type([]): usernames = ",".join(value) else: usernames = value (The latter is what you would do with a FormContentDict, which is why i find it so vastly more convenient than the FieldStorage. It's slightly better, though: it also painlessly handles the case where the "username" field is not present.) As mentioned earlier, i'm more concerned about the default setting for keep_blank_values. The message i wrote providing a complete explanation of this issue is included below so you don't have to search through old e-mail to find it. -- ?!ng -------- the headers of the original message -------- >From ping@lfw.org Tue Aug 22 12:18:57 2000 Date: Wed, 16 Aug 2000 02:31:48 -0700 (PDT) From: Ka-Ping Yee To: Moshe Zadka , bwarsaw@beopen.com, tpeters@beopen.com Subject: Re: [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict -------- the message body, with some edits -------- Hi, guys. This patch includes a "fix" to make cgi.parse_qsl honour its "keep_blank_values" argument. This fix might require a bit more discussion since it could break compatibility, so i thought i would air it for your consideration. BACKGROUND ---------- cgi.FieldStorage(), cgi.parse(), cgi.parse_qs(), and cgi.parse_qsl() all accept an optional "keep_blank_values" argument which is supposed to indicate whether form fields with empty strings as values should be included in the result. In reality, only cgi.parse_qs() honours this flag (cgi.parse() is okay because it uses cgi.parse_qs()). cgi.parse_qsl() totally ignores it, and always includes all values including empty ones. cgi.FieldStorage(), which uses cgi.parse_qsl(), similarly does not honour the "keep_blank_values" flag. The patch contains a fix to make cgi.parse_qsl() honour this flag. FOR --- It's clear that this was the intent of the "keep_blank_values" argument. The doc string for parse_qsl says: """Parse a query given as a string argument. Arguments: qs: URL-encoded query string to be parsed keep_blank_values: flag indicating whether blank values in URL encoded queries should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. Returns a list, as God intended. """ Its current disregard for "keep_blank_values" clearly contradicts this doc string. The doc string for FieldStorage.__init__ says: """Constructor. Read multipart/* until last part. Arguments, all optional: fp : file pointer; default: sys.stdin (not used when the request method is GET) headers : header dictionary-like object; default: taken from environ as per CGI spec outerboundary : terminating multipart boundary (for internal use only) environ : environment dictionary; default: os.environ keep_blank_values: flag indicating whether blank values in URL encoded forms should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. """ ...and the current behaviour of FieldStorage.__init__ contradicts what it says here about "keep_blank_values". AGAINST ------- Existing code which uses FieldStorage and relies on its current behaviour could break. If a form field is left blank by the user and the form is submitted, that key will not appear in the FieldStorage -- and an attempt to index it with form[key] will produce a KeyError where previously it yielded a MiniFieldStorage containing an empty string. The existing TeX documentation for the cgi module does not mention empty values or the keep_blank_values argument at all, so to those who have only read the library reference manual, this could be a surprise. OPTIONS ------- The reason this never showed up before is that there have never been *any* tests for FieldStorage in test_cgi.py! Naughty, naughty. One easy way to maintain compatibility is to change FieldStorage so that the default value for keep_blank_values is 1 (previously this was 0 but the FieldStorage *acted* as though it were 1). ------------------------------------------------------- Date: 2000-Aug-23 09:35 By: jhylton Comment: Since we are in feature freeze, let's not worry about whether we should have a get method or not. Please limit this patch to bug fixes and re-submit. I'll be happy to accept. Let's do a more thorough job of revising this module for 2.1. It looks amazingly complicated to me. ------------------------------------------------------- Date: 2000-Aug-24 01:27 By: ping Comment: Hi, Jeremy. I actually think the motivations for these changes are pretty clear. They directly address two things: 1. The doc strings say keep_blank_values is supposed to control whether blank values are kept. This currently doesn't work at all. 2. The TeX documentation says the FieldStorage object is supposed to behave like a dictionary. Dictionaries are expected to provide a .get() method, but the FieldStorage doesn't. Both of these things are basically bugs. The only decisions that remain have to do with backward compatibility when we fix #1 -- this is easily addressed by defaulting keep_blank_values to 1 -- and with determining the most effective way to implement .get() when we fix #2. The implementation of .get() in this patch greatly simplifies most CGI scripts. As shown in the examples in my previous comment, it can reduce four or five lines of mucking with the .value attribute to a single call. -- ?!ng ------------------------------------------------------- Date: 2000-Aug-24 05:57 By: moshez Comment: Guido: Adding the functionality you want is great, but it shouldn't be called get(). Call it getvalue() and I'm happy. The words "behave like a dictionary" have such a vague meaning that lacking a get() method can't be seen as a violation. However having a get() method that does something different *is* a violation! ------------------------------------------------------- Date: 2000-Aug-24 05:58 By: moshez Comment: OK, that seems fine, but in this case, FieldStorage shouldn't have a "get", only "getvalue". ------------------------------------------------------- Date: 2000-Aug-24 16:33 By: ping Comment: Agreed. I have removed get() and replaced it with getvalue(). The documentation and test have been updated accordingly. Also, i discovered that the compatibility issue about keep_blank_values is a red herring. In fact, keep_blank_values *did* previously work as documented in Python 1.5.2 -- it looks like it got *broken* by some patch in between then and now. This patch fixes the breakage. That resolves all the issues, so i think this is ready to go. Jeremy? ------------------------------------------------------- Date: 2000-Aug-25 06:57 By: jhylton Comment: Looks like a thorough job. Go for it! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:11:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:11:48 -0700 Subject: [Patches] [Patch #100852] Add poll() to select module Message-ID: <200008251411.HAA02815@bush.i.sourceforge.net> Patch #100852 has been updated. Project: Category: Modules Status: Closed Summary: Add poll() to select module Follow-Ups: Date: 2000-Jul-11 04:25 By: akuchling Comment: Derived from Sam Rushing's pollmodule.c that forms part of Medusa. Once I get a second opinion about the patch, I'll check it in. ------------------------------------------------------- Date: 2000-Jul-21 06:33 By: akuchling Comment: Updated version of the patch, which adds poll() to the select module. .register() and .unregister() add/remove fds, and .poll() performs the system call. Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored. Open question: should there be a function or attribute to get the list of registered fds? Still to do: write documentation, add the test case. ------------------------------------------------------- Date: 2000-Jul-24 17:54 By: akuchling Comment: Assigned to Jeremy for review; feel free to bounce it to someone else. ------------------------------------------------------- Date: 2000-Jul-25 10:25 By: akuchling Comment: Update patch to latest version, which adds poll() to the select() module. ------------------------------------------------------- Date: 2000-Jul-25 13:30 By: jhylton Comment: Several style nits changed, mostly to do with whitespace. Substantive changes: 1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens 2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND One more Open Issue: I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions: - interface to register many fds at once - keep the list of fds in sorted order - use a dict to store fds and generate fdarry lazily - keep track of allocated length and used length for ufds, so that fewer reallocs are required Each of these suggestions has some added complexity, so I'm not sure that I like any of them. ------------------------------------------------------- Date: 2000-Jul-25 13:41 By: akuchling Comment: I wondered about the linear search, too; it means balancing efficiency versus the lines of code to write this one object? IMHO implementing both #1 and #3 would be good; allow passing an arbitrary # of fds to register (and unregister?), store them in a dict, and then lazily generate the ufd array when needed. Or is there some built-in more suited than a dict for this? Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors. ------------------------------------------------------- Date: 2000-Jul-25 14:40 By: jhylton Comment: I think a dict is the right data structure, but I don't think it should be exposed directly. If it is not exposed, then the ufd array need only be generated for poll calls after a register or unregister. If there are multiple polls without a change, the same array can be re-used. ------------------------------------------------------- Date: 2000-Aug-12 21:13 By: akuchling Comment: Latest version, which stores an underlying dict as suggested in jhylton's previous comment. p.unregister() raises KeyError if you unregister a fd that wasn't registered in the first place; seem reasonable? It does to me... The code should now be completed; the only remaining task is to write docstrings and finish the documentation patch. ------------------------------------------------------- Date: 2000-Aug-15 10:36 By: tim_one Comment: Tickling you as part of 2.0 nagging. Please leave a note saying when you intend to "write docstrings and finish the documentation". ------------------------------------------------------- Date: 2000-Aug-15 17:57 By: akuchling Comment: Revised version -- documentation & docstrings completed, and there's a test script (not part of patch). Ready to check in once someone gives the patch a quick once-over and sanity check. ------------------------------------------------------- Date: 2000-Aug-15 19:38 By: tim_one Comment: Assigned to Barry for a quick once-over and sanity check, as he's looking at the socket code and "select" also begins with an "s", while the "p" in "poll" doesn't show up in "Cravin' Dogs" at all! A natural fit. ------------------------------------------------------- Date: 2000-Aug-24 13:10 By: jhylton Comment: Suggested revisions, including regression test. Defer to Andrew on whether to apply these changes. ------------------------------------------------------- Date: 2000-Aug-25 07:11 By: akuchling Comment: Patch checked in to CVS tree, with test suite and a few modifications from jhylton, further modified by akuchling. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:12:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:12:13 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008251412.HAA02825@bush.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- Date: 2000-Aug-25 05:49 By: fdrake Comment: Performance has *not* been checked -- there's no need to do that until the patch *works*. I understand the performance issue here; Guido and I have turnned this one around a few times and it's just plain hard to get right. One thing to recall is that the current implementation is broken as well; try the test case Jeremy submitted when he filed the bug report. (Keep in mind that I'm calling this patch "NOT READY" still -- I have no intention of checking this in as it stands.) Clearing exceptions in the comparison is clearly a bad thing, but they're getting raised in a chunk of code that simply doesn't allow raising exceptions. This is not well explained in the comments; I'll try to improve them. One issue with the problem is that and exception in the comparison can cause us not to find the entry we're looking for; during C-level exception handling, we're still trying to propogate another exception as well. Even if the general solution proves too slow for use with the module dictionaries (which will require testing to determine), I have some ideas about what it would take to make those fast anyway. I'll describe those later on python-dev. ------------------------------------------------------- Date: 2000-Aug-25 07:12 By: lemburg Comment: Ok. Sorry if that last message sounded a bit like FUD. This needs to be fixed, but I do think that we should get some more feedback and ideas into this... so let's head for python-dev :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From guido@beopen.com Fri Aug 25 16:30:32 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 25 Aug 2000 10:30:32 -0500 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict In-Reply-To: Your message of "Fri, 25 Aug 2000 09:53:54 -0400." <14758.31346.254541.53822@bitdiddle.concentric.net> References: <14757.46612.421234.942465@bitdiddle.concentric.net> <14758.31346.254541.53822@bitdiddle.concentric.net> Message-ID: <200008251530.KAA19975@cj20424-a.reston1.va.home.com> > >>>>> "MZ" == Moshe Zadka writes: > > MZ> On Thu, 24 Aug 2000, Jeremy Hylton wrote: > >> I'd be happiest if we limited the changes to the cgi module to > >> bug fixes. We are in feature freeze now, which means that > >> features -- even ones that make CGI scripting easier -- should be > >> postponed. > > MZ> The patch was in before the feature freeze.... > > But it wasn't accepted... > > Jeremy Let's stop the bickering. Here's a BDFL pronouncement. Jeremy, please check in the parts that you believe are bugfixes. Moshe or Ping, once Jeremy has done that, please prepare a new patch that adds the features you want added. We'll discuss those after 2.0 is released. My feeling is that cgi.py needs a more major overhaul than the addition of a method or two. Perhaps it's time for a new module, leaner meaner and not backwards compatible. cgilib.py anyone? --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From jeremy@beopen.com Fri Aug 25 15:38:26 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 25 Aug 2000 10:38:26 -0400 (EDT) Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict In-Reply-To: <200008251530.KAA19975@cj20424-a.reston1.va.home.com> References: <14757.46612.421234.942465@bitdiddle.concentric.net> <14758.31346.254541.53822@bitdiddle.concentric.net> <200008251530.KAA19975@cj20424-a.reston1.va.home.com> Message-ID: <14758.34018.194609.35045@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> >>>>> "MZ" == Moshe Zadka writes: MZ> On Thu, 24 Aug 2000, Jeremy Hylton wrote: >> >> I'd be happiest if we limited the changes to the cgi module to >> >> bug fixes. We are in feature freeze now, which means that >> >> features -- even ones that make CGI scripting easier -- should >> >> be postponed. MZ> The patch was in before the feature freeze.... >> But it wasn't accepted... >> Jeremy GvR> Let's stop the bickering. Here's a BDFL pronouncement. GvR> Jeremy, please check in the parts that you believe are GvR> bugfixes. Moshe or Ping, once Jeremy has done that, please GvR> prepare a new patch that adds the features you want added. GvR> We'll discuss those after 2.0 is released. My feeling is that GvR> cgi.py needs a more major overhaul than the addition of a GvR> method or two. Perhaps it's time for a new module, leaner GvR> meaner and not backwards compatible. cgilib.py anyone? Heh... Ping assigned the patch to me for review and I thought it was acceptable as it stands -- bug fixes and new features. It seems isolated enough to allow it through despite a feature freeze. Jeremy From guido@beopen.com Fri Aug 25 16:38:58 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 25 Aug 2000 10:38:58 -0500 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict In-Reply-To: Your message of "Fri, 25 Aug 2000 10:30:32 EST." <200008251530.KAA19975@cj20424-a.reston1.va.home.com> References: <14757.46612.421234.942465@bitdiddle.concentric.net> <14758.31346.254541.53822@bitdiddle.concentric.net> <200008251530.KAA19975@cj20424-a.reston1.va.home.com> Message-ID: <200008251538.KAA20253@cj20424-a.reston1.va.home.com> Actually, I see that Jeremy now has approved the patch as it stands. So whoever gets to it first please check it in and close the patch! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From noreply@sourceforge.net Fri Aug 25 17:21:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 09:21:42 -0700 Subject: [Patches] [Patch #101299] add missing test for strings in file_writelines Message-ID: <200008251621.JAA07704@bush.i.sourceforge.net> Patch #101299 has been updated. Project: Category: core (C code) Status: Open Summary: add missing test for strings in file_writelines ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101299&group_id=5470 From noreply@sourceforge.net Fri Aug 25 17:23:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 09:23:32 -0700 Subject: [Patches] [Patch #101299] add missing test for strings in file_writelines Message-ID: <200008251623.JAA07783@bush.i.sourceforge.net> Patch #101299 has been updated. Project: Category: core (C code) Status: Open Summary: add missing test for strings in file_writelines Follow-Ups: Date: 2000-Aug-25 09:23 By: jhylton Comment: This is a partial fix for Bug #111860. It looks like version 2.72 introduced the bug, because it does not check the type of the list elements in every code branch. This adds the PyString_Check to the branch where it was missing. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101299&group_id=5470 From noreply@sourceforge.net Fri Aug 25 22:38:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 14:38:15 -0700 Subject: [Patches] [Patch #101298] Enable Py_DEBUG via configure Message-ID: <200008252138.OAA08982@delerium.i.sourceforge.net> Patch #101298 has been updated. Project: Category: Build Status: Open Summary: Enable Py_DEBUG via configure Follow-Ups: Date: 2000-Aug-25 06:07 By: montanaro Comment: Assigned to Thomas so he doesn't need to keep editing config.h manually. ;-) ------------------------------------------------------- Date: 2000-Aug-25 14:38 By: twouters Comment: Looks fine to me, though I would expand the 'help' message for this option a bit. State that it is for 'extensive debugging of the Python interpreter' or some such. And as far as I'm concerned, it's accepted. Oh, wait, not quite accepted: don't edit config.h.in manually. Edit acconfig.h to add a specific comment to a #define (just add the #define and the comment to that file) and then 'autoheader' will create config.h.in just like 'autoconf' creates configure from configure.in. (If the define is not present in acconfig.h, but is set in configure.in, a generic comment is used instead.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101298&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:15:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:15:48 -0700 Subject: [Patches] [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict Message-ID: <200008252215.PAA10315@delerium.i.sourceforge.net> Patch #101120 has been updated. Project: Category: library Status: Closed Summary: add .get() to cgi.FieldStorage and cgi.FormContentDict Follow-Ups: Date: 2000-Aug-08 13:28 By: ping Comment: This actually adds all of the auxiliary dictionary methods to FormContentDict (e.g. copy, update) since it makes FormContentDict derive from UserDict. __version__ has been incremented to 2.3. ------------------------------------------------------- Date: 2000-Aug-15 14:38 By: tim_one Comment: Ping, if you don't make this a full patch (i.e., including doc changes, and tests if at all possible) Soon, I have to Postpone it. Also please it assign it to someone capable of reviewing it (not me -- don't know anything about cgi). ------------------------------------------------------- Date: 2000-Aug-15 23:36 By: tim_one Comment: Assigned to Barry (sorry, Barry!) for sanity-checking. Ping pointed out in email that the module in question already documents that it "acts like a dict", and all the patch does is make that true in more cases. Looks benign to me, but I've never used the module, so it could stand a quick scan from someone who isn't a total idiot. Jeremy is probably the most natural choice for looking at this, but he won't be useful to us again until just a few days before 2.0b1 is scheduled to ship. Don't want to wait that long. ------------------------------------------------------- Date: 2000-Aug-15 23:41 By: tim_one Comment: Reassigned to Moshe, cuz Ping said he volunteered. Way to go, Moshe! If this release ever goes it, you'll be the only reason it does . ------------------------------------------------------- Date: 2000-Aug-16 00:28 By: moshez Comment: OK, I gave it a short run around and it looked quite all right. I do have on qualm, Ping: it's a bit awkward to use .get() like that, because you still have to check whether to use .value or not. Here's an example of what I mean (I hope if I surround it with PRE tags it will be protected): 
print cgi.FieldStorage().get("hello", 
             cgi.MiniFieldStorage("hello", "world)).value
Because otherwise .get() doesn't buy you much. However, other then that it's great -- accept that there still aren't docos and test cases. (So I've kept this "Open") ------------------------------------------------------- Date: 2000-Aug-16 02:16 By: ping Comment: Okay, here's the new patch. There is quite a bit more now: 1. Fixed parse_qsl to honour the keep_blank_values argument. Previously FieldStorage() would contain empty fields despite keep_blank_values being zero, contrary to intent. Now empty fields will not be present unless keep_blank_values is supplied. This could break code that expects fields to always be present, but it is also more in keeping with the way keep_blank_values was supposed to work. (If compatibility is enough of a concern, we can default keep_blank_values to 1 to maintain the old behaviour.) 2. New get() method on FieldStorage looks up the string value in the 'value' attribute. When a multiple values are present, it looks up the 'value' attribute within each MiniFieldStorage and produces a list of strings. 3. FormContentDict is derived from UserDict (same as the original patch). 4. More tests: new tests for FieldStorage, since there were none before, and tests for the get() method. 5. Documentation updates: describe the get() method, the keep_blank_values option, and simplify the examples with the convenient use of the get() method. Fix a little formatting. Standardize the capitalization of "Content-Type". Reword the descriptions of parse_multipart and parse_header to make them more comprehensible. Phew. ------------------------------------------------------- Date: 2000-Aug-16 02:35 By: moshez Comment: OK, this one looks fine to me! I didn't test it again, though (I assume Ping did) -- but the API seems much improved. I've even had a look over the documentation and it looks great! ------------------------------------------------------- Date: 2000-Aug-21 18:54 By: tim_one Comment: Ping, are you going to check this in? If not, please assign it to someone else for checkin. ------------------------------------------------------- Date: 2000-Aug-21 21:41 By: moshez Comment: Actually, it's now waiting for someone's pronouncement -- Guido had a problem with .get() and __getitem__ not being equivalent (the first does an implicit .value). Ping and I thought it best that way, but if the BDFL has strong feelings otherwise, he should pronounce. Assigned to him for final verdict. ------------------------------------------------------- Date: 2000-Aug-22 13:46 By: ping Comment: On Fri, 18 Aug 2000, Guido van Rossum wrote: > If I understand the discussion below correctly, to get the > value for 'foo' you must use > > x['foo'].value > > but now you can also use > > x.get('foo') This is true. > ??? That's inconsistent compared to how these two behave for regular > dictionaries! I mulled this over a while when doing the patch. Initially, i did make form.get(x) behave exactly like form[x], and proceeded to try to make the FieldStorage object behave as much like a dictionary as possible (since the docs say it can be "accessed like a dictionary"). FormContentDict and its descendants clearly behave like a dictionary since they are derived from UserDict. But as i investigated FieldStorage further, i found that it actually lacks lots of dictionary behaviour: no update(), no clear(), no copy(), no items(), no values(). The only dictionary-like semantics we really care about are [key], keys(), and has_key(). Implementing items() and values() would require an uncertain choice, since the FieldStorage represents a multimap: do multi-valued fields appear as multiple key-value pairs with the same key, or a single pair with a list for its value? In the end, i decided to abandon true dictionary-like behaviour, because the thing being represented is a bit too much more than a dictionary. By far the most common use of the FieldStorage (and even the entire cgi module) is just to decode simple strings from single-valued form fields, and the interface should do its best to facilitate that common use. I decided it was okay to break consistency with regular dictionaries (a) as long as the behaviour is clearly documented and (b) since it doesn't fully satisfy one's expectations of a dictionary anyway. Moshe's response drove home the point when he demonstrated that the advantage of get() -- to provide a default when a value is missing -- is overwhelmed by the awkwardness of the .value interface. If get() returns a MiniFieldStorage, then to default the "spam" field to "eggs" i have to say field = form.get("spam", "eggs") if type(field) is type(""): process(field) else: process(field.value) or field = form.get("spam", None) if field is None: process("eggs") else: process(field.value) or field = form.get("spam", cgi.MiniFieldStorage("spam", "eggs")) process(field.value) which are hardly any better than if form.has_key("spam"): process(form["spam"].value) else: process("eggs") at all! If get() returns a string, then i can just say process(form.get("spam", "eggs")) and i can be on my way. I have personally stayed away from FieldStorage because it's so annoying to use; having to look up the "value" attribute on every form field makes programs verbose and awkward. This gets worse when a field has multple values. In fact, the usage example provided in Doc/lib/libcgi.tex is a perfect demonstration: username = form["username"] if type(username) is type([]): usernames = "" for item in username: if username: usernames = usernames + "," + item.value else: usernames = item.value else: usernames = username.value The above can be shortened somewhat with map(), but with the new get() method, this can simply be written in the obvious way: value = form.get("username", "") if type(value) is type([]): usernames = ",".join(value) else: usernames = value (The latter is what you would do with a FormContentDict, which is why i find it so vastly more convenient than the FieldStorage. It's slightly better, though: it also painlessly handles the case where the "username" field is not present.) As mentioned earlier, i'm more concerned about the default setting for keep_blank_values. The message i wrote providing a complete explanation of this issue is included below so you don't have to search through old e-mail to find it. -- ?!ng -------- the headers of the original message -------- >From ping@lfw.org Tue Aug 22 12:18:57 2000 Date: Wed, 16 Aug 2000 02:31:48 -0700 (PDT) From: Ka-Ping Yee To: Moshe Zadka , bwarsaw@beopen.com, tpeters@beopen.com Subject: Re: [Patch #101120] add .get() to cgi.FieldStorage and cgi.FormContentDict -------- the message body, with some edits -------- Hi, guys. This patch includes a "fix" to make cgi.parse_qsl honour its "keep_blank_values" argument. This fix might require a bit more discussion since it could break compatibility, so i thought i would air it for your consideration. BACKGROUND ---------- cgi.FieldStorage(), cgi.parse(), cgi.parse_qs(), and cgi.parse_qsl() all accept an optional "keep_blank_values" argument which is supposed to indicate whether form fields with empty strings as values should be included in the result. In reality, only cgi.parse_qs() honours this flag (cgi.parse() is okay because it uses cgi.parse_qs()). cgi.parse_qsl() totally ignores it, and always includes all values including empty ones. cgi.FieldStorage(), which uses cgi.parse_qsl(), similarly does not honour the "keep_blank_values" flag. The patch contains a fix to make cgi.parse_qsl() honour this flag. FOR --- It's clear that this was the intent of the "keep_blank_values" argument. The doc string for parse_qsl says: """Parse a query given as a string argument. Arguments: qs: URL-encoded query string to be parsed keep_blank_values: flag indicating whether blank values in URL encoded queries should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. Returns a list, as God intended. """ Its current disregard for "keep_blank_values" clearly contradicts this doc string. The doc string for FieldStorage.__init__ says: """Constructor. Read multipart/* until last part. Arguments, all optional: fp : file pointer; default: sys.stdin (not used when the request method is GET) headers : header dictionary-like object; default: taken from environ as per CGI spec outerboundary : terminating multipart boundary (for internal use only) environ : environment dictionary; default: os.environ keep_blank_values: flag indicating whether blank values in URL encoded forms should be treated as blank strings.­­ A true value indicates that blanks should be retained as­ blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. strict_parsing: flag indicating what to do with parsing errors. If false (the default), errors are silently ignored. If true, errors raise a ValueError exception. """ ...and the current behaviour of FieldStorage.__init__ contradicts what it says here about "keep_blank_values". AGAINST ------- Existing code which uses FieldStorage and relies on its current behaviour could break. If a form field is left blank by the user and the form is submitted, that key will not appear in the FieldStorage -- and an attempt to index it with form[key] will produce a KeyError where previously it yielded a MiniFieldStorage containing an empty string. The existing TeX documentation for the cgi module does not mention empty values or the keep_blank_values argument at all, so to those who have only read the library reference manual, this could be a surprise. OPTIONS ------- The reason this never showed up before is that there have never been *any* tests for FieldStorage in test_cgi.py! Naughty, naughty. One easy way to maintain compatibility is to change FieldStorage so that the default value for keep_blank_values is 1 (previously this was 0 but the FieldStorage *acted* as though it were 1). ------------------------------------------------------- Date: 2000-Aug-23 09:35 By: jhylton Comment: Since we are in feature freeze, let's not worry about whether we should have a get method or not. Please limit this patch to bug fixes and re-submit. I'll be happy to accept. Let's do a more thorough job of revising this module for 2.1. It looks amazingly complicated to me. ------------------------------------------------------- Date: 2000-Aug-24 01:27 By: ping Comment: Hi, Jeremy. I actually think the motivations for these changes are pretty clear. They directly address two things: 1. The doc strings say keep_blank_values is supposed to control whether blank values are kept. This currently doesn't work at all. 2. The TeX documentation says the FieldStorage object is supposed to behave like a dictionary. Dictionaries are expected to provide a .get() method, but the FieldStorage doesn't. Both of these things are basically bugs. The only decisions that remain have to do with backward compatibility when we fix #1 -- this is easily addressed by defaulting keep_blank_values to 1 -- and with determining the most effective way to implement .get() when we fix #2. The implementation of .get() in this patch greatly simplifies most CGI scripts. As shown in the examples in my previous comment, it can reduce four or five lines of mucking with the .value attribute to a single call. -- ?!ng ------------------------------------------------------- Date: 2000-Aug-24 05:57 By: moshez Comment: Guido: Adding the functionality you want is great, but it shouldn't be called get(). Call it getvalue() and I'm happy. The words "behave like a dictionary" have such a vague meaning that lacking a get() method can't be seen as a violation. However having a get() method that does something different *is* a violation! ------------------------------------------------------- Date: 2000-Aug-24 05:58 By: moshez Comment: OK, that seems fine, but in this case, FieldStorage shouldn't have a "get", only "getvalue". ------------------------------------------------------- Date: 2000-Aug-24 16:33 By: ping Comment: Agreed. I have removed get() and replaced it with getvalue(). The documentation and test have been updated accordingly. Also, i discovered that the compatibility issue about keep_blank_values is a red herring. In fact, keep_blank_values *did* previously work as documented in Python 1.5.2 -- it looks like it got *broken* by some patch in between then and now. This patch fixes the breakage. That resolves all the issues, so i think this is ready to go. Jeremy? ------------------------------------------------------- Date: 2000-Aug-25 06:57 By: jhylton Comment: Looks like a thorough job. Go for it! ------------------------------------------------------- Date: 2000-Aug-25 15:15 By: jhylton Comment: Apparently checked in my moshe ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101120&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:35:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:35:42 -0700 Subject: [Patches] [Patch #101298] Enable Py_DEBUG via configure Message-ID: <200008252235.PAA11112@delerium.i.sourceforge.net> Patch #101298 has been updated. Project: Category: Build Status: Open Summary: Enable Py_DEBUG via configure Follow-Ups: Date: 2000-Aug-25 06:07 By: montanaro Comment: Assigned to Thomas so he doesn't need to keep editing config.h manually. ;-) ------------------------------------------------------- Date: 2000-Aug-25 14:38 By: twouters Comment: Looks fine to me, though I would expand the 'help' message for this option a bit. State that it is for 'extensive debugging of the Python interpreter' or some such. And as far as I'm concerned, it's accepted. Oh, wait, not quite accepted: don't edit config.h.in manually. Edit acconfig.h to add a specific comment to a #define (just add the #define and the comment to that file) and then 'autoheader' will create config.h.in just like 'autoconf' creates configure from configure.in. (If the define is not present in acconfig.h, but is set in configure.in, a generic comment is used instead.) ------------------------------------------------------- Date: 2000-Aug-25 15:35 By: montanaro Comment: I've never used autoheader before. Simpleminded usage: autoheader acconfig.h > config.h.in fails with % autoheader acconfig.h error: AC_CONFIG_HEADER not found in acconfig.h  Trying it with no args yields % autoheader /usr/bin/autoheader: Symbol `WITH_LIBDB' is not covered\ by /usr/share/autoconf/acconfig.h ./acconfig.h Of course, there is no autoheader man page or info file on my system. What's the magic incantation? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101298&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:53:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:53:25 -0700 Subject: [Patches] [Patch #101299] add missing test for strings in file_writelines Message-ID: <200008252253.PAA22094@bush.i.sourceforge.net> Patch #101299 has been updated. Project: Category: core (C code) Status: Closed Summary: add missing test for strings in file_writelines Follow-Ups: Date: 2000-Aug-25 09:23 By: jhylton Comment: This is a partial fix for Bug #111860. It looks like version 2.72 introduced the bug, because it does not check the type of the list elements in every code branch. This adds the PyString_Check to the branch where it was missing. ------------------------------------------------------- Date: 2000-Aug-25 15:53 By: lemburg Comment: I just checked in a fix for the bug and the test script provided by Jeremy Hilton. This patch is now obsolete... closing it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101299&group_id=5470 From noreply@sourceforge.net Sat Aug 26 06:25:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 22:25:16 -0700 Subject: [Patches] [Patch #101309] Specialization of dictionaries for strings. Message-ID: <200008260525.WAA01701@bush.i.sourceforge.net> Patch #101309 has been updated. Project: Category: core (C code) Status: Open Summary: Specialization of dictionaries for strings. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 From noreply@sourceforge.net Sat Aug 26 06:26:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 22:26:29 -0700 Subject: [Patches] [Patch #101309] Specialization of dictionaries for strings. Message-ID: <200008260526.WAA01708@bush.i.sourceforge.net> Patch #101309 has been updated. Project: Category: core (C code) Status: Open Summary: Specialization of dictionaries for strings. Follow-Ups: Date: 2000-Aug-25 22:26 By: fdrake Comment: This patch introduces some changes to the builtin dictionary type. These changes create a specialization of the type to better support efficient use of dictionaries as a runtime implementation detail. This patch causes all newly created dictionaries to be specialized for string keys; dictionaries are converted (trivially) to handle arbitrary keys as needed. If a non-string is used as a key (even if only doing a lookup and it fails), the dictionary is converted to a normal dictionary. To achieve faster performance, a specialized version of the lookdict() function is used. The specialized implementation can assume two things that the "normal" implementation cannot: - that all comparisons are always done using the PyString_Type.tp_compare function, avoiding some of the overhead of calling PyObject_Compare() and dereferencing the comparison function repeatedly, and - that the comparison function never raises an exception, since two strings can always be compared without an error. Some debugging code added to dictobject.c shows that most dictionaries created during the regression test are never converted to "normal" dictionaries, but always only use strings as keys: created 115874 string dicts converted 2658 to normal dicts 2.29% conversion rate Additional performance tests should be made. I expect that a patch such as this is most valuable if additional code is needed to robustify lookdict() to properly deal with exceptions from user-defined comparison functions (tp_compare handlers of __cmp__() functions in Python code). The patch duplicates the logic of the lookdict() function, which makes maintenance more tedious. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 From noreply@sourceforge.net Sat Aug 26 06:51:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 22:51:03 -0700 Subject: [Patches] [Patch #101310] update help for cmd.py library module Message-ID: <200008260551.WAA25261@delerium.i.sourceforge.net> Patch #101310 has been updated. Project: Category: library Status: Open Summary: update help for cmd.py library module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101310&group_id=5470 From noreply@sourceforge.net Sat Aug 26 11:33:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 03:33:28 -0700 Subject: [Patches] [Patch #101312] gettext: Bi-endianness, catalog information, Unicode Message-ID: <200008261033.DAA10583@bush.i.sourceforge.net> Patch #101312 has been updated. Project: Category: library Status: Open Summary: gettext: Bi-endianness, catalog information, Unicode ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101312&group_id=5470 From noreply@sourceforge.net Sat Aug 26 11:35:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 03:35:16 -0700 Subject: [Patches] [Patch #101313] New builtin function doc Message-ID: <200008261035.DAA10606@bush.i.sourceforge.net> Patch #101313 has been updated. Project: Category: library Status: Open Summary: New builtin function doc ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101313&group_id=5470 From noreply@sourceforge.net Sat Aug 26 12:00:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 04:00:15 -0700 Subject: [Patches] [Patch #101298] Enable Py_DEBUG via configure Message-ID: <200008261100.EAA11394@bush.i.sourceforge.net> Patch #101298 has been updated. Project: Category: Build Status: Open Summary: Enable Py_DEBUG via configure Follow-Ups: Date: 2000-Aug-25 06:07 By: montanaro Comment: Assigned to Thomas so he doesn't need to keep editing config.h manually. ;-) ------------------------------------------------------- Date: 2000-Aug-25 14:38 By: twouters Comment: Looks fine to me, though I would expand the 'help' message for this option a bit. State that it is for 'extensive debugging of the Python interpreter' or some such. And as far as I'm concerned, it's accepted. Oh, wait, not quite accepted: don't edit config.h.in manually. Edit acconfig.h to add a specific comment to a #define (just add the #define and the comment to that file) and then 'autoheader' will create config.h.in just like 'autoconf' creates configure from configure.in. (If the define is not present in acconfig.h, but is set in configure.in, a generic comment is used instead.) ------------------------------------------------------- Date: 2000-Aug-25 15:35 By: montanaro Comment: I've never used autoheader before. Simpleminded usage: autoheader acconfig.h > config.h.in fails with % autoheader acconfig.h error: AC_CONFIG_HEADER not found in acconfig.h  Trying it with no args yields % autoheader /usr/bin/autoheader: Symbol `WITH_LIBDB' is not covered\ by /usr/share/autoconf/acconfig.h ./acconfig.h Of course, there is no autoheader man page or info file on my system. What's the magic incantation? ------------------------------------------------------- Date: 2000-Aug-26 04:00 By: twouters Comment: You don't need to redirect the output of 'autoheader' (or 'autoconf' for that matter!) but you *are* apparently missing something important from acconfig.h. This is probably related to the other patches you have lying around :) If you *do* pass an argument to autoheader, the argument should be the configure.in file, not the acconfig.h file. The config.h.in file is generated from configure.in (by looking at what defines it sets) with help from acconfig.h. My earlier statement that 'a generic comment will be used if a #define is missing from acconfig.h' was probably a bit misleading, though: it's not that simple. Autoheader uses *two* acconfig.h files: a system-wide one, and the local one. The system-wide one contains the #defines & comments for the most common checks, but if you set one in configure.in which isn't in the global acconfig.h yet, you have to add it to the local acconfig.h yourself. In addition to the two acconfig.h files, autoheader also tries to figure out what #defines you set and auto-generates comments for those: the defines set by AC_CHECK_LIB(S), AC_CHECK_HEADERS, etc, are added automatically, unless they already exist in acconfig.h (in which case, the comment in acconfig.h is used instead of the generated one.) The error you get, about WITH_LIBDB, probably means you need to add WITH_LIBDB to acconfig.h. Oh, and no, there isn't a manpage for autoheader and autoconf, because it's GNU, and documentation on GNU software is primarily 'info'. You have to be lucky to get manpages :-S And 'info autoheader' won't work, because it's a command and not a package: you need to use 'info autoconf', and then look for autoheader (using 's'). That said, do you want me to grab your patch, fix it up and commit it, or do you want to give it a shot yourself ? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101298&group_id=5470 From noreply@sourceforge.net Sat Aug 26 16:21:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 08:21:50 -0700 Subject: [Patches] [Patch #101315] "import mod.submod as s" per Guido's wishes. Message-ID: <200008261521.IAA19463@bush.i.sourceforge.net> Patch #101315 has been updated. Project: Category: core (C code) Status: Open Summary: "import mod.submod as s" per Guido's wishes. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101315&group_id=5470 From strongbox@hotpop.com Sat Aug 26 10:27:43 2000 From: strongbox@hotpop.com (strongbox@hotpop.com) Date: Sat, 26 Aug 2000 09:27:43 Subject: [Patches] AD:Family Reunion T Shirts & More Message-ID: <808.653128.857153@kkiplmailer.com> Message sent by: Kuppler Graphics, 32 West Main Street, Maple Shade, New Jersey, 08052, 1-800-810-4330. This list will NOT be sold. All addresses are automatically added to our remove list. Hello. My name is Bill from Kuppler Graphics. We do screenprinting on T Shirts, Sweatshirts, Jackets, Hats, Tote Bags and more! Do you or someone you know have a Family Reunion coming up? Kuppler Graphics would like to provide you with some great looking T Shirts for your Reunion. Kuppler Graphics can also provide you with custom T's and promotional items such as imprinted magnets, keychains, pens, mugs, hats, etc. for your business or any fundraising activity (church, school, business etc.) We also can provide you with quality embroidery. We are a family owned company with over 15 years of experience. All work is done at this location. No middle man. Our prices are great! Please call toll free 1-800-810-4330 if the reply to email is down for a quote or to discuss your screenprinting needs Bill Kuppler Graphics From noreply@sourceforge.net Sat Aug 26 18:22:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 10:22:43 -0700 Subject: [Patches] [Patch #101298] Enable Py_DEBUG via configure Message-ID: <200008261722.KAA23513@bush.i.sourceforge.net> Patch #101298 has been updated. Project: Category: Build Status: Open Summary: Enable Py_DEBUG via configure Follow-Ups: Date: 2000-Aug-25 06:07 By: montanaro Comment: Assigned to Thomas so he doesn't need to keep editing config.h manually. ;-) ------------------------------------------------------- Date: 2000-Aug-25 14:38 By: twouters Comment: Looks fine to me, though I would expand the 'help' message for this option a bit. State that it is for 'extensive debugging of the Python interpreter' or some such. And as far as I'm concerned, it's accepted. Oh, wait, not quite accepted: don't edit config.h.in manually. Edit acconfig.h to add a specific comment to a #define (just add the #define and the comment to that file) and then 'autoheader' will create config.h.in just like 'autoconf' creates configure from configure.in. (If the define is not present in acconfig.h, but is set in configure.in, a generic comment is used instead.) ------------------------------------------------------- Date: 2000-Aug-25 15:35 By: montanaro Comment: I've never used autoheader before. Simpleminded usage: autoheader acconfig.h > config.h.in fails with % autoheader acconfig.h error: AC_CONFIG_HEADER not found in acconfig.h  Trying it with no args yields % autoheader /usr/bin/autoheader: Symbol `WITH_LIBDB' is not covered\ by /usr/share/autoconf/acconfig.h ./acconfig.h Of course, there is no autoheader man page or info file on my system. What's the magic incantation? ------------------------------------------------------- Date: 2000-Aug-26 04:00 By: twouters Comment: You don't need to redirect the output of 'autoheader' (or 'autoconf' for that matter!) but you *are* apparently missing something important from acconfig.h. This is probably related to the other patches you have lying around :) If you *do* pass an argument to autoheader, the argument should be the configure.in file, not the acconfig.h file. The config.h.in file is generated from configure.in (by looking at what defines it sets) with help from acconfig.h. My earlier statement that 'a generic comment will be used if a #define is missing from acconfig.h' was probably a bit misleading, though: it's not that simple. Autoheader uses *two* acconfig.h files: a system-wide one, and the local one. The system-wide one contains the #defines & comments for the most common checks, but if you set one in configure.in which isn't in the global acconfig.h yet, you have to add it to the local acconfig.h yourself. In addition to the two acconfig.h files, autoheader also tries to figure out what #defines you set and auto-generates comments for those: the defines set by AC_CHECK_LIB(S), AC_CHECK_HEADERS, etc, are added automatically, unless they already exist in acconfig.h (in which case, the comment in acconfig.h is used instead of the generated one.) The error you get, about WITH_LIBDB, probably means you need to add WITH_LIBDB to acconfig.h. Oh, and no, there isn't a manpage for autoheader and autoconf, because it's GNU, and documentation on GNU software is primarily 'info'. You have to be lucky to get manpages :-S And 'info autoheader' won't work, because it's a command and not a package: you need to use 'info autoconf', and then look for autoheader (using 's'). That said, do you want me to grab your patch, fix it up and commit it, or do you want to give it a shot yourself ? ------------------------------------------------------- Date: 2000-Aug-26 10:22 By: montanaro Comment: Here's an updated version that includes acconfig.h. config.h.in was generated by autoheader. You should be able to apply this patch but will probably get some offset warnings from patch because I snipped out a couple other changes. Diffs for configure aren't included here. I will generate a proper configure file when checking this in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101298&group_id=5470 From noreply@sourceforge.net Sat Aug 26 18:23:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 10:23:38 -0700 Subject: [Patches] [Patch #101298] Enable Py_DEBUG via configure Message-ID: <200008261723.KAA23619@bush.i.sourceforge.net> Patch #101298 has been updated. Project: Category: Build Status: Open Summary: Enable Py_DEBUG via configure Follow-Ups: Date: 2000-Aug-25 06:07 By: montanaro Comment: Assigned to Thomas so he doesn't need to keep editing config.h manually. ;-) ------------------------------------------------------- Date: 2000-Aug-25 14:38 By: twouters Comment: Looks fine to me, though I would expand the 'help' message for this option a bit. State that it is for 'extensive debugging of the Python interpreter' or some such. And as far as I'm concerned, it's accepted. Oh, wait, not quite accepted: don't edit config.h.in manually. Edit acconfig.h to add a specific comment to a #define (just add the #define and the comment to that file) and then 'autoheader' will create config.h.in just like 'autoconf' creates configure from configure.in. (If the define is not present in acconfig.h, but is set in configure.in, a generic comment is used instead.) ------------------------------------------------------- Date: 2000-Aug-25 15:35 By: montanaro Comment: I've never used autoheader before. Simpleminded usage: autoheader acconfig.h > config.h.in fails with % autoheader acconfig.h error: AC_CONFIG_HEADER not found in acconfig.h  Trying it with no args yields % autoheader /usr/bin/autoheader: Symbol `WITH_LIBDB' is not covered\ by /usr/share/autoconf/acconfig.h ./acconfig.h Of course, there is no autoheader man page or info file on my system. What's the magic incantation? ------------------------------------------------------- Date: 2000-Aug-26 04:00 By: twouters Comment: You don't need to redirect the output of 'autoheader' (or 'autoconf' for that matter!) but you *are* apparently missing something important from acconfig.h. This is probably related to the other patches you have lying around :) If you *do* pass an argument to autoheader, the argument should be the configure.in file, not the acconfig.h file. The config.h.in file is generated from configure.in (by looking at what defines it sets) with help from acconfig.h. My earlier statement that 'a generic comment will be used if a #define is missing from acconfig.h' was probably a bit misleading, though: it's not that simple. Autoheader uses *two* acconfig.h files: a system-wide one, and the local one. The system-wide one contains the #defines & comments for the most common checks, but if you set one in configure.in which isn't in the global acconfig.h yet, you have to add it to the local acconfig.h yourself. In addition to the two acconfig.h files, autoheader also tries to figure out what #defines you set and auto-generates comments for those: the defines set by AC_CHECK_LIB(S), AC_CHECK_HEADERS, etc, are added automatically, unless they already exist in acconfig.h (in which case, the comment in acconfig.h is used instead of the generated one.) The error you get, about WITH_LIBDB, probably means you need to add WITH_LIBDB to acconfig.h. Oh, and no, there isn't a manpage for autoheader and autoconf, because it's GNU, and documentation on GNU software is primarily 'info'. You have to be lucky to get manpages :-S And 'info autoheader' won't work, because it's a command and not a package: you need to use 'info autoconf', and then look for autoheader (using 's'). That said, do you want me to grab your patch, fix it up and commit it, or do you want to give it a shot yourself ? ------------------------------------------------------- Date: 2000-Aug-26 10:22 By: montanaro Comment: Here's an updated version that includes acconfig.h. config.h.in was generated by autoheader. You should be able to apply this patch but will probably get some offset warnings from patch because I snipped out a couple other changes. Diffs for configure aren't included here. I will generate a proper configure file when checking this in. ------------------------------------------------------- Date: 2000-Aug-26 10:23 By: montanaro Comment: oh bother ... I forgot C-x C-s after trimming the patch... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101298&group_id=5470 From noreply@sourceforge.net Sat Aug 26 19:17:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 11:17:42 -0700 Subject: [Patches] [Patch #101315] "import mod.submod as s" per Guido's wishes. Message-ID: <200008261817.LAA25431@bush.i.sourceforge.net> Patch #101315 has been updated. Project: Category: core (C code) Status: Open Summary: "import mod.submod as s" per Guido's wishes. Follow-Ups: Date: 2000-Aug-26 11:17 By: twouters Comment: Implemented in the way I believe Guido wanted, and assigned to him for approval. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101315&group_id=5470 From noreply@sourceforge.net Sat Aug 26 19:36:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 11:36:34 -0700 Subject: [Patches] [Patch #101313] New builtin function doc Message-ID: <200008261836.LAA16670@delerium.i.sourceforge.net> Patch #101313 has been updated. Project: Category: library Status: Open Summary: New builtin function doc Follow-Ups: Date: 2000-Aug-26 11:36 By: twouters Comment: Someone (Vladimir, I think ?) was working on a help() function, which was a docstring-prettyprinter as well as helpful in many other ways. I also think doc() should only be defined in interactive mode, but that's personal. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101313&group_id=5470 From noreply@sourceforge.net Sat Aug 26 23:40:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 15:40:39 -0700 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' Message-ID: <200008262240.PAA25170@delerium.i.sourceforge.net> Patch #101243 has been updated. Project: Category: core (C code) Status: Open Summary: Use a compile time mechanism to 'find "import-from" args' Follow-Ups: Date: 2000-Aug-20 13:57 By: twouters Comment: This patch changes the mechanism used to find the 'import-arguments' as passed to __import__ (and used by 'ni' and such dynamic import mechanisms.) The current mechanism looks into the 'future' bytecode stream (from the IMPORT_NAME statement onward) looking for IMPORT_FROM statements. The problem is that this limits the extend in which we can change IMPORT_FROM, and that this is a runtime check for information which was available at compile-time. Instead, we create a list of import-from arguments, and push it on the stack. The list creation is still done at runtime (it has to be, I think ?) but it's a simple push-constants-on-the-stack-and-BUILD_LIST operation. The result is that all 'import arguments' (the names imported-from another module) are present not only as normal 'names' in the co_names list, but also as PyString objects in the co_consts list. And that pystone runs a few promille faster on my machine. And that more trickery is allowed in imports, such as those that patch #101234 allows. ------------------------------------------------------- Date: 2000-Aug-21 17:18 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-21 17:21 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-21 17:53 By: gvanrossum Comment: Cool, but needs some work before you can check it in. Notes: - Yes, a tuple constant would be fine. (Note: co_names and co_consts are really redundant; all that's needed is co_consts.) - In ceval.c, why not place "u = POP()" *after* the test for x==NULL? Then you don't need to DECREF it when x==NULL. - You left the fprintf in com_pop() uncommented! - Barry just bumped the MAGIC number. There's no need to do this twice a week if no release occurred. :) ------------------------------------------------------- Date: 2000-Aug-22 07:39 By: twouters Comment: - Okay, I'll rewrite it to create a tuple. Note, however ! This means that the import mechanism gets passed in a tuple, instead of a list. I'm not sure if that will break anything, or influence user-code in any way, because I can't say I fully understand the import mechanisms yet ;) But I did notice that PyImport_ImportModule() takes care to build a list instead of a tuple, to pass to PyImport_ImportModuleEx() - moving the POP(): fine. I'm never quite sure when to POP an item or not. I was under the impression that you needed to pop all items the bytecode is 'supposed' to pop (and push back the number of items it's supposed to push, even if they are NULL) before raising an exception. But that's just the impression I got from reading the code, not from reading the exception mechanism. - The entries in co_names are not really redundant. The co_names entries are used for the actual IMPORT_FROM and STORE_NAME opcodes, this new tuple (or list) only for the IMPORT_NAME opcode. I don't think it's worth the effort to combine the two, because it would require either rewriting the STORE opcodes to use a const rather than a name, or find out in some way which 'names' are used in imports. Anyway, since they're both PyStrings, and both likely to be interned, it's just a pointer duplication. - fprintf: oops. Will fix. - Bumping the magic: I'm not so certain about not upping the bytecode magic: we're not using up a scarce resource, here, because it's upped according to date anyway. Is not upping it worth the small chance that someone imports new bytecode in an old interpreter and gets weird behaviour ? Patch follows later: I'm trying not to neglect my other patches in the mean time, and that's proven tricky with the number of conflicting checkins in the last two weeks :-) ------------------------------------------------------- Date: 2000-Aug-26 15:40 By: twouters Comment: Okay, this patch creates a tuple-constant instead of constructing a list at runtime, makes import.c use a tuple as well, and moves the POP(). However, it still ups the bytecode magic :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 From noreply@sourceforge.net Sat Aug 26 23:44:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 15:44:51 -0700 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' Message-ID: <200008262244.PAA25331@delerium.i.sourceforge.net> Patch #101243 has been updated. Project: Category: core (C code) Status: Open Summary: Use a compile time mechanism to 'find "import-from" args' Follow-Ups: Date: 2000-Aug-20 13:57 By: twouters Comment: This patch changes the mechanism used to find the 'import-arguments' as passed to __import__ (and used by 'ni' and such dynamic import mechanisms.) The current mechanism looks into the 'future' bytecode stream (from the IMPORT_NAME statement onward) looking for IMPORT_FROM statements. The problem is that this limits the extend in which we can change IMPORT_FROM, and that this is a runtime check for information which was available at compile-time. Instead, we create a list of import-from arguments, and push it on the stack. The list creation is still done at runtime (it has to be, I think ?) but it's a simple push-constants-on-the-stack-and-BUILD_LIST operation. The result is that all 'import arguments' (the names imported-from another module) are present not only as normal 'names' in the co_names list, but also as PyString objects in the co_consts list. And that pystone runs a few promille faster on my machine. And that more trickery is allowed in imports, such as those that patch #101234 allows. ------------------------------------------------------- Date: 2000-Aug-21 17:18 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-21 17:21 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-21 17:53 By: gvanrossum Comment: Cool, but needs some work before you can check it in. Notes: - Yes, a tuple constant would be fine. (Note: co_names and co_consts are really redundant; all that's needed is co_consts.) - In ceval.c, why not place "u = POP()" *after* the test for x==NULL? Then you don't need to DECREF it when x==NULL. - You left the fprintf in com_pop() uncommented! - Barry just bumped the MAGIC number. There's no need to do this twice a week if no release occurred. :) ------------------------------------------------------- Date: 2000-Aug-22 07:39 By: twouters Comment: - Okay, I'll rewrite it to create a tuple. Note, however ! This means that the import mechanism gets passed in a tuple, instead of a list. I'm not sure if that will break anything, or influence user-code in any way, because I can't say I fully understand the import mechanisms yet ;) But I did notice that PyImport_ImportModule() takes care to build a list instead of a tuple, to pass to PyImport_ImportModuleEx() - moving the POP(): fine. I'm never quite sure when to POP an item or not. I was under the impression that you needed to pop all items the bytecode is 'supposed' to pop (and push back the number of items it's supposed to push, even if they are NULL) before raising an exception. But that's just the impression I got from reading the code, not from reading the exception mechanism. - The entries in co_names are not really redundant. The co_names entries are used for the actual IMPORT_FROM and STORE_NAME opcodes, this new tuple (or list) only for the IMPORT_NAME opcode. I don't think it's worth the effort to combine the two, because it would require either rewriting the STORE opcodes to use a const rather than a name, or find out in some way which 'names' are used in imports. Anyway, since they're both PyStrings, and both likely to be interned, it's just a pointer duplication. - fprintf: oops. Will fix. - Bumping the magic: I'm not so certain about not upping the bytecode magic: we're not using up a scarce resource, here, because it's upped according to date anyway. Is not upping it worth the small chance that someone imports new bytecode in an old interpreter and gets weird behaviour ? Patch follows later: I'm trying not to neglect my other patches in the mean time, and that's proven tricky with the number of conflicting checkins in the last two weeks :-) ------------------------------------------------------- Date: 2000-Aug-26 15:40 By: twouters Comment: Okay, this patch creates a tuple-constant instead of constructing a list at runtime, makes import.c use a tuple as well, and moves the POP(). However, it still ups the bytecode magic :-) ------------------------------------------------------- Date: 2000-Aug-26 15:44 By: twouters Comment: Oh, and giving it back to Guido. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 From noreply@sourceforge.net Sun Aug 27 10:13:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 02:13:15 -0700 Subject: [Patches] [Patch #101313] New builtin function doc Message-ID: <200008270913.CAA20311@bush.i.sourceforge.net> Patch #101313 has been updated. Project: Category: library Status: Open Summary: New builtin function doc Follow-Ups: Date: 2000-Aug-26 11:36 By: twouters Comment: Someone (Vladimir, I think ?) was working on a help() function, which was a docstring-prettyprinter as well as helpful in many other ways. I also think doc() should only be defined in interactive mode, but that's personal. ------------------------------------------------------- Date: 2000-Aug-27 02:13 By: moshez Comment: Assigned to Jeremy, so he can postpone it. It's definitely not-for-2.0 stuff. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101313&group_id=5470 From noreply@sourceforge.net Sun Aug 27 10:15:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 02:15:19 -0700 Subject: [Patches] [Patch #101310] update help for cmd.py library module Message-ID: <200008270915.CAA20427@bush.i.sourceforge.net> Patch #101310 has been updated. Project: Category: library Status: Open Summary: update help for cmd.py library module Follow-Ups: Date: 2000-Aug-25 22:52 By: tpot Comment: This patch simply gives a docstring to the do_help command so by default, running help in a Cmd object displays some default help for the help command. ------------------------------------------------------- Date: 2000-Aug-27 02:15 By: moshez Comment: OK, I know we're after a feature-freeze, but this is simply adding a doc-string to a function (it could be said to be a bug fix ). I'm going to apply-and-close it later today unless someone objects. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101310&group_id=5470 From noreply@sourceforge.net Sun Aug 27 10:16:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 02:16:05 -0700 Subject: [Patches] [Patch #101312] gettext: Bi-endianness, catalog information, Unicode Message-ID: <200008270916.CAA20430@bush.i.sourceforge.net> Patch #101312 has been updated. Project: Category: library Status: Open Summary: gettext: Bi-endianness, catalog information, Unicode Follow-Ups: Date: 2000-Aug-27 02:16 By: moshez Comment: Assigned to Barry, as he seems to be the i18n guy. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101312&group_id=5470 From noreply@sourceforge.net Sun Aug 27 11:06:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 03:06:42 -0700 Subject: [Patches] [Patch #101310] update help for cmd.py library module Message-ID: <200008271006.DAA13804@delerium.i.sourceforge.net> Patch #101310 has been updated. Project: Category: library Status: Open Summary: update help for cmd.py library module Follow-Ups: Date: 2000-Aug-25 22:52 By: tpot Comment: This patch simply gives a docstring to the do_help command so by default, running help in a Cmd object displays some default help for the help command. ------------------------------------------------------- Date: 2000-Aug-27 02:15 By: moshez Comment: OK, I know we're after a feature-freeze, but this is simply adding a doc-string to a function (it could be said to be a bug fix ). I'm going to apply-and-close it later today unless someone objects. ------------------------------------------------------- Date: 2000-Aug-27 03:06 By: tim_one Comment: I think this falls under the "expert applying a non-controversial change" clause: not a feature, not a bug, just something with no real consequence that ought to be done. Just do it. Except first please note that the patch is buggy (it fails to close the triple-quoted string it introduces). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101310&group_id=5470 From noreply@sourceforge.net Sun Aug 27 11:53:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 03:53:29 -0700 Subject: [Patches] [Patch #101310] update help for cmd.py library module Message-ID: <200008271053.DAA23238@bush.i.sourceforge.net> Patch #101310 has been updated. Project: Category: library Status: Accepted Summary: update help for cmd.py library module Follow-Ups: Date: 2000-Aug-25 22:52 By: tpot Comment: This patch simply gives a docstring to the do_help command so by default, running help in a Cmd object displays some default help for the help command. ------------------------------------------------------- Date: 2000-Aug-27 02:15 By: moshez Comment: OK, I know we're after a feature-freeze, but this is simply adding a doc-string to a function (it could be said to be a bug fix ). I'm going to apply-and-close it later today unless someone objects. ------------------------------------------------------- Date: 2000-Aug-27 03:06 By: tim_one Comment: I think this falls under the "expert applying a non-controversial change" clause: not a feature, not a bug, just something with no real consequence that ought to be done. Just do it. Except first please note that the patch is buggy (it fails to close the triple-quoted string it introduces). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101310&group_id=5470 From noreply@sourceforge.net Sun Aug 27 13:36:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 05:36:23 -0700 Subject: [Patches] [Patch #101310] update help for cmd.py library module Message-ID: <200008271236.FAA20933@delerium.i.sourceforge.net> Patch #101310 has been updated. Project: Category: library Status: Rejected Summary: update help for cmd.py library module Follow-Ups: Date: 2000-Aug-25 22:52 By: tpot Comment: This patch simply gives a docstring to the do_help command so by default, running help in a Cmd object displays some default help for the help command. ------------------------------------------------------- Date: 2000-Aug-27 02:15 By: moshez Comment: OK, I know we're after a feature-freeze, but this is simply adding a doc-string to a function (it could be said to be a bug fix ). I'm going to apply-and-close it later today unless someone objects. ------------------------------------------------------- Date: 2000-Aug-27 03:06 By: tim_one Comment: I think this falls under the "expert applying a non-controversial change" clause: not a feature, not a bug, just something with no real consequence that ought to be done. Just do it. Except first please note that the patch is buggy (it fails to close the triple-quoted string it introduces). ------------------------------------------------------- Date: 2000-Aug-27 05:36 By: gvanrossum Comment: Rejected. It's kind of silly to check in a single doc string in a module that doesn't have any doc strings at all. Plus the doc string doesn't really explain the command much better than its name. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101310&group_id=5470 From noreply@sourceforge.net Sun Aug 27 16:45:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 08:45:56 -0700 Subject: [Patches] [Patch #101320] Translate doc strings Message-ID: <200008271545.IAA27012@delerium.i.sourceforge.net> Patch #101320 has been updated. Project: Category: Build Status: Open Summary: Translate doc strings ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101320&group_id=5470 From noreply@sourceforge.net Sun Aug 27 18:37:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 10:37:19 -0700 Subject: [Patches] [Patch #101226] make threading fork-safe Message-ID: <200008271737.KAA05869@bush.i.sourceforge.net> Patch #101226 has been updated. Project: Category: core (C code) Status: Closed Summary: make threading fork-safe Follow-Ups: Date: 2000-Aug-18 21:46 By: cgw Comment: See http://www.lambdacs.com/newsgroup/FAQ.html#Q120 and "man pthread_atfork" for background. I don't use a pthread_atfork handler here - the explicit approach is more portable. However calling fork() from C extensions could still cause trouble. This patch causes the child to create a new interpreter lock after doing a fork. It would be nice to deallocate the old lock with PyThread_free_lock, but this does some unwanted error-checking in addition to deallocating the lock. So I waste a little memory instead. To really do this cleanly one could add a new PyThread_reset_lock function to all the thread_*.h files, and use that instead. ------------------------------------------------------- Date: 2000-Aug-19 18:51 By: tim_one Comment: Assigned to me. I'll discuss it with Guido too. So far 2e've gotten 3 reports from people who don't see failures in assorted test cases anymore, and no reports of remaining failures. ------------------------------------------------------- Date: 2000-Aug-24 11:02 By: tim_one Comment: Accepted, and assigned to Jeremy for checkin. We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm. Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows. ------------------------------------------------------- Date: 2000-Aug-24 11:19 By: tim_one Comment: Accepted, and assigned to Jeremy for checkin. We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm. Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows. ------------------------------------------------------- Date: 2000-Aug-24 20:06 By: gvanrossum Comment: Don't check this in yet! Tim & I had a brainwave. We can share a single mutex for all locks and grab it around a fork, and the lock reinitialization won't be needed. (We think.) ------------------------------------------------------- Date: 2000-Aug-24 21:09 By: tim_one Comment: Now that I've had a chance to drive recklessly, suck down a Coke, and chain-smoke two butts in peace , I'm certain that the "one mutex" idea will work, and satisfied that the extra contention it may cause is pthread's own damn fault for presuming to kill threads in the child while they're in an unknown state. Full mutex ahead! ------------------------------------------------------- Date: 2000-Aug-27 10:37 By: gvanrossum Comment: The great idea Tim & I had didn't solve the problem! The problem has a *parent* spinning. We suspect now that it is a LinuxThreads or kernel bug, since there's otherwise no way that what happens in the child can affect the parent. (Charles' fix only adds code that runs in the child.) So I've checked in Charles' patch and leave the thread code alone. Do remember that a long chain of forks will leak a bit -- I see no way around that. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101226&group_id=5470 From noreply@sourceforge.net Sun Aug 27 19:10:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 11:10:35 -0700 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' Message-ID: <200008271810.LAA06988@bush.i.sourceforge.net> Patch #101243 has been updated. Project: Category: core (C code) Status: Accepted Summary: Use a compile time mechanism to 'find "import-from" args' Follow-Ups: Date: 2000-Aug-20 13:57 By: twouters Comment: This patch changes the mechanism used to find the 'import-arguments' as passed to __import__ (and used by 'ni' and such dynamic import mechanisms.) The current mechanism looks into the 'future' bytecode stream (from the IMPORT_NAME statement onward) looking for IMPORT_FROM statements. The problem is that this limits the extend in which we can change IMPORT_FROM, and that this is a runtime check for information which was available at compile-time. Instead, we create a list of import-from arguments, and push it on the stack. The list creation is still done at runtime (it has to be, I think ?) but it's a simple push-constants-on-the-stack-and-BUILD_LIST operation. The result is that all 'import arguments' (the names imported-from another module) are present not only as normal 'names' in the co_names list, but also as PyString objects in the co_consts list. And that pystone runs a few promille faster on my machine. And that more trickery is allowed in imports, such as those that patch #101234 allows. ------------------------------------------------------- Date: 2000-Aug-21 17:18 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-21 17:21 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-21 17:53 By: gvanrossum Comment: Cool, but needs some work before you can check it in. Notes: - Yes, a tuple constant would be fine. (Note: co_names and co_consts are really redundant; all that's needed is co_consts.) - In ceval.c, why not place "u = POP()" *after* the test for x==NULL? Then you don't need to DECREF it when x==NULL. - You left the fprintf in com_pop() uncommented! - Barry just bumped the MAGIC number. There's no need to do this twice a week if no release occurred. :) ------------------------------------------------------- Date: 2000-Aug-22 07:39 By: twouters Comment: - Okay, I'll rewrite it to create a tuple. Note, however ! This means that the import mechanism gets passed in a tuple, instead of a list. I'm not sure if that will break anything, or influence user-code in any way, because I can't say I fully understand the import mechanisms yet ;) But I did notice that PyImport_ImportModule() takes care to build a list instead of a tuple, to pass to PyImport_ImportModuleEx() - moving the POP(): fine. I'm never quite sure when to POP an item or not. I was under the impression that you needed to pop all items the bytecode is 'supposed' to pop (and push back the number of items it's supposed to push, even if they are NULL) before raising an exception. But that's just the impression I got from reading the code, not from reading the exception mechanism. - The entries in co_names are not really redundant. The co_names entries are used for the actual IMPORT_FROM and STORE_NAME opcodes, this new tuple (or list) only for the IMPORT_NAME opcode. I don't think it's worth the effort to combine the two, because it would require either rewriting the STORE opcodes to use a const rather than a name, or find out in some way which 'names' are used in imports. Anyway, since they're both PyStrings, and both likely to be interned, it's just a pointer duplication. - fprintf: oops. Will fix. - Bumping the magic: I'm not so certain about not upping the bytecode magic: we're not using up a scarce resource, here, because it's upped according to date anyway. Is not upping it worth the small chance that someone imports new bytecode in an old interpreter and gets weird behaviour ? Patch follows later: I'm trying not to neglect my other patches in the mean time, and that's proven tricky with the number of conflicting checkins in the last two weeks :-) ------------------------------------------------------- Date: 2000-Aug-26 15:40 By: twouters Comment: Okay, this patch creates a tuple-constant instead of constructing a list at runtime, makes import.c use a tuple as well, and moves the POP(). However, it still ups the bytecode magic :-) ------------------------------------------------------- Date: 2000-Aug-26 15:44 By: twouters Comment: Oh, and giving it back to Guido. ------------------------------------------------------- Date: 2000-Aug-27 11:10 By: gvanrossum Comment: Looks good. Check it in. I'm impressed with your understanding of Python bytecode generation and execution! Irrelevant note: you say "PyImport_ImportModule() takes care to build a list instead of a tuple, to pass to PyImport_ImportModuleEx()". I don't see that; but I see that ensure_fromlist() uses PySequence_GetItem() so it's okay. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 From noreply@sourceforge.net Sun Aug 27 19:14:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 11:14:28 -0700 Subject: [Patches] [Patch #101315] "import mod.submod as s" per Guido's wishes. Message-ID: <200008271814.LAA07064@bush.i.sourceforge.net> Patch #101315 has been updated. Project: Category: core (C code) Status: Accepted Summary: "import mod.submod as s" per Guido's wishes. Follow-Ups: Date: 2000-Aug-26 11:17 By: twouters Comment: Implemented in the way I believe Guido wanted, and assigned to him for approval. ------------------------------------------------------- Date: 2000-Aug-27 11:14 By: gvanrossum Comment: Cool, check it in and close it! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101315&group_id=5470 From noreply@sourceforge.net Sun Aug 27 19:25:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 11:25:29 -0700 Subject: [Patches] [Patch #101238] PyOS_CheckStack for Windows (MSVC) Message-ID: <200008271825.LAA07498@bush.i.sourceforge.net> Patch #101238 has been updated. Project: Category: core (C code) Status: Accepted Summary: PyOS_CheckStack for Windows (MSVC) Follow-Ups: Date: 2000-Aug-21 17:11 By: tim_one Comment: Assigned to Guido because there's a policy issue. This implements Jack's PyOS_CheckStack for the combo of Windows and MSVC. The question is whether you think there's a general approach waiting to be had here (I don't, except for adopting Stackless), or whether platform-specific tricks are the best we can do. ------------------------------------------------------- Date: 2000-Aug-21 18:16 By: gvanrossum Comment: The semantics of the stack are completely implementation dependent so I wouldn't know how to do this platform-independent. This looks fine to me -- but when I test it (VC 6 on Win98), it doesn't work. Try this: class C: def __getattr__(self, a): return self.x C() This still aborts the program. ------------------------------------------------------- Date: 2000-Aug-21 19:35 By: gvanrossum Comment: And are you sure you tested this? As shown it breaks the build for _sre because the declaration for PyOS_CheckStack() doesn't use DL_IMPORT(). (MSVC 6.0 on Win98.) ------------------------------------------------------- Date: 2000-Aug-23 07:06 By: effbot Comment: bumped stack margin to 8k on a 32-bit box (same as on the Macintosh). this solves the __getattr__ problem, as well as bug #110615. also: fixed the DL_IMPORT problem. ------------------------------------------------------- Date: 2000-Aug-27 11:25 By: gvanrossum Comment: Thanks -- this works! Check it in and close the patch please. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101238&group_id=5470 From noreply@sourceforge.net Sun Aug 27 19:30:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 11:30:44 -0700 Subject: [Patches] [Patch #101310] update help for cmd.py library module Message-ID: <200008271830.LAA07667@bush.i.sourceforge.net> Patch #101310 has been updated. Project: Category: library Status: Open Summary: update help for cmd.py library module Follow-Ups: Date: 2000-Aug-25 22:52 By: tpot Comment: This patch simply gives a docstring to the do_help command so by default, running help in a Cmd object displays some default help for the help command. ------------------------------------------------------- Date: 2000-Aug-27 02:15 By: moshez Comment: OK, I know we're after a feature-freeze, but this is simply adding a doc-string to a function (it could be said to be a bug fix ). I'm going to apply-and-close it later today unless someone objects. ------------------------------------------------------- Date: 2000-Aug-27 03:06 By: tim_one Comment: I think this falls under the "expert applying a non-controversial change" clause: not a feature, not a bug, just something with no real consequence that ought to be done. Just do it. Except first please note that the patch is buggy (it fails to close the triple-quoted string it introduces). ------------------------------------------------------- Date: 2000-Aug-27 05:36 By: gvanrossum Comment: Rejected. It's kind of silly to check in a single doc string in a module that doesn't have any doc strings at all. Plus the doc string doesn't really explain the command much better than its name. ------------------------------------------------------- Date: 2000-Aug-27 11:30 By: tim_one Comment: I think this falls under the "expert applying a non-controversial change" clause: not a feature, not a bug, just something with no real consequence that ought to be done. Just do it. Except first please note that the patch is buggy (it fails to close the triple-quoted string it introduces). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101310&group_id=5470 From noreply@sourceforge.net Sun Aug 27 20:00:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 12:00:22 -0700 Subject: [Patches] [Patch #101238] PyOS_CheckStack for Windows (MSVC) Message-ID: <200008271900.MAA08653@bush.i.sourceforge.net> Patch #101238 has been updated. Project: Category: core (C code) Status: Closed Summary: PyOS_CheckStack for Windows (MSVC) Follow-Ups: Date: 2000-Aug-21 17:11 By: tim_one Comment: Assigned to Guido because there's a policy issue. This implements Jack's PyOS_CheckStack for the combo of Windows and MSVC. The question is whether you think there's a general approach waiting to be had here (I don't, except for adopting Stackless), or whether platform-specific tricks are the best we can do. ------------------------------------------------------- Date: 2000-Aug-21 18:16 By: gvanrossum Comment: The semantics of the stack are completely implementation dependent so I wouldn't know how to do this platform-independent. This looks fine to me -- but when I test it (VC 6 on Win98), it doesn't work. Try this: class C: def __getattr__(self, a): return self.x C() This still aborts the program. ------------------------------------------------------- Date: 2000-Aug-21 19:35 By: gvanrossum Comment: And are you sure you tested this? As shown it breaks the build for _sre because the declaration for PyOS_CheckStack() doesn't use DL_IMPORT(). (MSVC 6.0 on Win98.) ------------------------------------------------------- Date: 2000-Aug-23 07:06 By: effbot Comment: bumped stack margin to 8k on a 32-bit box (same as on the Macintosh). this solves the __getattr__ problem, as well as bug #110615. also: fixed the DL_IMPORT problem. ------------------------------------------------------- Date: 2000-Aug-27 11:25 By: gvanrossum Comment: Thanks -- this works! Check it in and close the patch please. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101238&group_id=5470 From noreply@sourceforge.net Sun Aug 27 20:28:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 12:28:55 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008271928.MAA09589@bush.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Sun Aug 27 21:22:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 13:22:58 -0700 Subject: [Patches] [Patch #101315] "import mod.submod as s" per Guido's wishes. Message-ID: <200008272022.NAA11475@bush.i.sourceforge.net> Patch #101315 has been updated. Project: Category: core (C code) Status: Closed Summary: "import mod.submod as s" per Guido's wishes. Follow-Ups: Date: 2000-Aug-26 11:17 By: twouters Comment: Implemented in the way I believe Guido wanted, and assigned to him for approval. ------------------------------------------------------- Date: 2000-Aug-27 11:14 By: gvanrossum Comment: Cool, check it in and close it! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101315&group_id=5470 From noreply@sourceforge.net Sun Aug 27 21:49:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 13:49:44 -0700 Subject: [Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args' Message-ID: <200008272049.NAA04697@delerium.i.sourceforge.net> Patch #101243 has been updated. Project: Category: core (C code) Status: Closed Summary: Use a compile time mechanism to 'find "import-from" args' Follow-Ups: Date: 2000-Aug-20 13:57 By: twouters Comment: This patch changes the mechanism used to find the 'import-arguments' as passed to __import__ (and used by 'ni' and such dynamic import mechanisms.) The current mechanism looks into the 'future' bytecode stream (from the IMPORT_NAME statement onward) looking for IMPORT_FROM statements. The problem is that this limits the extend in which we can change IMPORT_FROM, and that this is a runtime check for information which was available at compile-time. Instead, we create a list of import-from arguments, and push it on the stack. The list creation is still done at runtime (it has to be, I think ?) but it's a simple push-constants-on-the-stack-and-BUILD_LIST operation. The result is that all 'import arguments' (the names imported-from another module) are present not only as normal 'names' in the co_names list, but also as PyString objects in the co_consts list. And that pystone runs a few promille faster on my machine. And that more trickery is allowed in imports, such as those that patch #101234 allows. ------------------------------------------------------- Date: 2000-Aug-21 17:18 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-21 17:21 By: tim_one Comment: Leaving unassigned for the moment. I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now. OK, not leaving unassigned: Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts? ------------------------------------------------------- Date: 2000-Aug-21 17:53 By: gvanrossum Comment: Cool, but needs some work before you can check it in. Notes: - Yes, a tuple constant would be fine. (Note: co_names and co_consts are really redundant; all that's needed is co_consts.) - In ceval.c, why not place "u = POP()" *after* the test for x==NULL? Then you don't need to DECREF it when x==NULL. - You left the fprintf in com_pop() uncommented! - Barry just bumped the MAGIC number. There's no need to do this twice a week if no release occurred. :) ------------------------------------------------------- Date: 2000-Aug-22 07:39 By: twouters Comment: - Okay, I'll rewrite it to create a tuple. Note, however ! This means that the import mechanism gets passed in a tuple, instead of a list. I'm not sure if that will break anything, or influence user-code in any way, because I can't say I fully understand the import mechanisms yet ;) But I did notice that PyImport_ImportModule() takes care to build a list instead of a tuple, to pass to PyImport_ImportModuleEx() - moving the POP(): fine. I'm never quite sure when to POP an item or not. I was under the impression that you needed to pop all items the bytecode is 'supposed' to pop (and push back the number of items it's supposed to push, even if they are NULL) before raising an exception. But that's just the impression I got from reading the code, not from reading the exception mechanism. - The entries in co_names are not really redundant. The co_names entries are used for the actual IMPORT_FROM and STORE_NAME opcodes, this new tuple (or list) only for the IMPORT_NAME opcode. I don't think it's worth the effort to combine the two, because it would require either rewriting the STORE opcodes to use a const rather than a name, or find out in some way which 'names' are used in imports. Anyway, since they're both PyStrings, and both likely to be interned, it's just a pointer duplication. - fprintf: oops. Will fix. - Bumping the magic: I'm not so certain about not upping the bytecode magic: we're not using up a scarce resource, here, because it's upped according to date anyway. Is not upping it worth the small chance that someone imports new bytecode in an old interpreter and gets weird behaviour ? Patch follows later: I'm trying not to neglect my other patches in the mean time, and that's proven tricky with the number of conflicting checkins in the last two weeks :-) ------------------------------------------------------- Date: 2000-Aug-26 15:40 By: twouters Comment: Okay, this patch creates a tuple-constant instead of constructing a list at runtime, makes import.c use a tuple as well, and moves the POP(). However, it still ups the bytecode magic :-) ------------------------------------------------------- Date: 2000-Aug-26 15:44 By: twouters Comment: Oh, and giving it back to Guido. ------------------------------------------------------- Date: 2000-Aug-27 11:10 By: gvanrossum Comment: Looks good. Check it in. I'm impressed with your understanding of Python bytecode generation and execution! Irrelevant note: you say "PyImport_ImportModule() takes care to build a list instead of a tuple, to pass to PyImport_ImportModuleEx()". I don't see that; but I see that ensure_fromlist() uses PySequence_GetItem() so it's okay. ------------------------------------------------------- Date: 2000-Aug-27 13:49 By: twouters Comment: Checked in. Thanx for the compliment, but the reason it seems like I understand it is very simple: it's code that is easy to understand, and I've had plenty of motivation. Next stop, the meta-grammar (completely virgin terrain for me) to allow keywords after 'def' and '.' ;-) As for the PyImport_ImportModule() note: the function did this: fromlist = Py_BuildValue("[s]", "*"); when 'fromlist' was None. Explicitly creating a list, that is. And now it does fromlist = Py_BuildValue("(s)", "*"); :-) (Another irrelevant note: is this creation really necessary ? PyImport_ImportModuleEx() also checks for NULL and None...) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470 From noreply@sourceforge.net Sun Aug 27 22:04:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 14:04:38 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008272104.OAA12870@bush.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- Date: 2000-Aug-27 14:04 By: twouters Comment: Alright, here's an updated version. I also included graminit.h and .c, because I don't know if you can run pgen, and if you complain about graminit.h not patching, I guess you can't ;-) (the fact that graminit.h was included in the previous patch was an honest mistake. But if you intend to read this patch: there's nothing interesting below graminit.c, which is about 900 lines.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Mon Aug 28 07:05:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 23:05:02 -0700 Subject: [Patches] [Patch #101310] update help for cmd.py library module Message-ID: <200008280605.XAA22991@delerium.i.sourceforge.net> Patch #101310 has been updated. Project: Category: library Status: Rejected Summary: update help for cmd.py library module Follow-Ups: Date: 2000-Aug-25 22:52 By: tpot Comment: This patch simply gives a docstring to the do_help command so by default, running help in a Cmd object displays some default help for the help command. ------------------------------------------------------- Date: 2000-Aug-27 02:15 By: moshez Comment: OK, I know we're after a feature-freeze, but this is simply adding a doc-string to a function (it could be said to be a bug fix ). I'm going to apply-and-close it later today unless someone objects. ------------------------------------------------------- Date: 2000-Aug-27 03:06 By: tim_one Comment: I think this falls under the "expert applying a non-controversial change" clause: not a feature, not a bug, just something with no real consequence that ought to be done. Just do it. Except first please note that the patch is buggy (it fails to close the triple-quoted string it introduces). ------------------------------------------------------- Date: 2000-Aug-27 05:36 By: gvanrossum Comment: Rejected. It's kind of silly to check in a single doc string in a module that doesn't have any doc strings at all. Plus the doc string doesn't really explain the command much better than its name. ------------------------------------------------------- Date: 2000-Aug-27 11:30 By: tim_one Comment: I think this falls under the "expert applying a non-controversial change" clause: not a feature, not a bug, just something with no real consequence that ought to be done. Just do it. Except first please note that the patch is buggy (it fails to close the triple-quoted string it introduces). ------------------------------------------------------- Date: 2000-Aug-27 23:05 By: tim_one Comment: Looks like an SF page reload 8 hours(!) later duplicated my earlier comment and simultaneously overwrote Guido's "Rejected". Unintended. Reset to Rejected. Also assigned to None. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101310&group_id=5470 From noreply@sourceforge.net Mon Aug 28 08:31:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 00:31:19 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008280731.AAA32692@bush.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- Date: 2000-Aug-27 14:04 By: twouters Comment: Alright, here's an updated version. I also included graminit.h and .c, because I don't know if you can run pgen, and if you complain about graminit.h not patching, I guess you can't ;-) (the fact that graminit.h was included in the previous patch was an honest mistake. But if you intend to read this patch: there's nothing interesting below graminit.c, which is about 900 lines.) ------------------------------------------------------- Date: 2000-Aug-28 00:31 By: tim_one Comment: Assigned to Fred to eyeball the docs; assign back to me if you're happy, else to Thomas if you're not. Thomas, this looks good! I have a nit and a complaint. The nit is that we don't need to keep bumping import's magic number -- once per public release should be enough. The complaint is that PyList_GetLenOfRange is brittle. In the context the code originally appeared, it was file-private, so all call sites were known and close by, that its assumptions were met was easy to verify, and that it did only 48% of the job didn't matter. But here it's almost part of the public API: it should do the whole job. By that I mean it should verify that its step argument is non-zero, and if the step argument is less than 0 it should shuffle the input values around to compute the correct answer. As is, this delicate shuffling is duplicated in its callers, and if someone happens to pass in a step < 0 it's just hosed. I would prefer: 1. Rename it with a leading underscore. This doesn't seem useful enough to be in the public API. 2. If it's private, it's OK to assert argument preconditions instead of error-checking them. So stick in assert(size != 0). 3. Deal with negative step size internally. Like (leading x to stop SourceForge from left-flushing all the lines): if (step < 0) { x long temp = lo; x lo = hi; x hi = temp; x step = -step; } right after the new assert. 4. Remove the if/else argument swapping from all its callers. 5. Change the comment before the function to match. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Mon Aug 28 08:43:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 00:43:09 -0700 Subject: [Patches] [Patch #101313] New builtin function doc Message-ID: <200008280743.AAA26165@delerium.i.sourceforge.net> Patch #101313 has been updated. Project: Category: library Status: Postponed Summary: New builtin function doc Follow-Ups: Date: 2000-Aug-26 11:36 By: twouters Comment: Someone (Vladimir, I think ?) was working on a help() function, which was a docstring-prettyprinter as well as helpful in many other ways. I also think doc() should only be defined in interactive mode, but that's personal. ------------------------------------------------------- Date: 2000-Aug-27 02:13 By: moshez Comment: Assigned to Jeremy, so he can postpone it. It's definitely not-for-2.0 stuff. ------------------------------------------------------- Date: 2000-Aug-28 00:43 By: tim_one Comment: Postponed it as requested (why didn't you do that yourself?). Left assigned to Jeremy for post-2.0 resurrection. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101313&group_id=5470 From noreply@sourceforge.net Mon Aug 28 08:46:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 00:46:19 -0700 Subject: [Patches] [Patch #101320] Translate doc strings Message-ID: <200008280746.AAA26317@delerium.i.sourceforge.net> Patch #101320 has been updated. Project: Category: Build Status: Open Summary: Translate doc strings Follow-Ups: Date: 2000-Aug-28 00:46 By: tim_one Comment: Assigned to Barry since it seems related to gettext. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101320&group_id=5470 From noreply@sourceforge.net Mon Aug 28 09:02:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 01:02:19 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008280802.BAA26879@delerium.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- Date: 2000-Aug-27 14:04 By: twouters Comment: Alright, here's an updated version. I also included graminit.h and .c, because I don't know if you can run pgen, and if you complain about graminit.h not patching, I guess you can't ;-) (the fact that graminit.h was included in the previous patch was an honest mistake. But if you intend to read this patch: there's nothing interesting below graminit.c, which is about 900 lines.) ------------------------------------------------------- Date: 2000-Aug-28 00:31 By: tim_one Comment: Assigned to Fred to eyeball the docs; assign back to me if you're happy, else to Thomas if you're not. Thomas, this looks good! I have a nit and a complaint. The nit is that we don't need to keep bumping import's magic number -- once per public release should be enough. The complaint is that PyList_GetLenOfRange is brittle. In the context the code originally appeared, it was file-private, so all call sites were known and close by, that its assumptions were met was easy to verify, and that it did only 48% of the job didn't matter. But here it's almost part of the public API: it should do the whole job. By that I mean it should verify that its step argument is non-zero, and if the step argument is less than 0 it should shuffle the input values around to compute the correct answer. As is, this delicate shuffling is duplicated in its callers, and if someone happens to pass in a step < 0 it's just hosed. I would prefer: 1. Rename it with a leading underscore. This doesn't seem useful enough to be in the public API. 2. If it's private, it's OK to assert argument preconditions instead of error-checking them. So stick in assert(size != 0). 3. Deal with negative step size internally. Like (leading x to stop SourceForge from left-flushing all the lines): if (step < 0) { x long temp = lo; x lo = hi; x hi = temp; x step = -step; } right after the new assert. 4. Remove the if/else argument swapping from all its callers. 5. Change the comment before the function to match. ------------------------------------------------------- Date: 2000-Aug-28 01:02 By: twouters Comment: Okay, but I have one question: WTH do you mean by '2.' ? assert what size ? the return value of getlenofrange ? all those values are passed-in, from Python expressions, so I don't think assert()in them is that good an idea. I really doubt you want the program to abort() if a user types in '[:0:]' or some such. Oh, and on the nit: I still don't agree, see my other comment in, uhm, some patch or other: we aren't using up a scarce resource with the MAGIC, as it's created by date, and it prevents *new* bytecode from running in *old* (relatively) interpreters, even if those old interpreters are only a few days old and the whole thing would 'only' happen to other developers. Or is there something else I don't know about ? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Mon Aug 28 09:32:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 01:32:49 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008280832.BAA02458@bush.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- Date: 2000-Aug-27 14:04 By: twouters Comment: Alright, here's an updated version. I also included graminit.h and .c, because I don't know if you can run pgen, and if you complain about graminit.h not patching, I guess you can't ;-) (the fact that graminit.h was included in the previous patch was an honest mistake. But if you intend to read this patch: there's nothing interesting below graminit.c, which is about 900 lines.) ------------------------------------------------------- Date: 2000-Aug-28 00:31 By: tim_one Comment: Assigned to Fred to eyeball the docs; assign back to me if you're happy, else to Thomas if you're not. Thomas, this looks good! I have a nit and a complaint. The nit is that we don't need to keep bumping import's magic number -- once per public release should be enough. The complaint is that PyList_GetLenOfRange is brittle. In the context the code originally appeared, it was file-private, so all call sites were known and close by, that its assumptions were met was easy to verify, and that it did only 48% of the job didn't matter. But here it's almost part of the public API: it should do the whole job. By that I mean it should verify that its step argument is non-zero, and if the step argument is less than 0 it should shuffle the input values around to compute the correct answer. As is, this delicate shuffling is duplicated in its callers, and if someone happens to pass in a step < 0 it's just hosed. I would prefer: 1. Rename it with a leading underscore. This doesn't seem useful enough to be in the public API. 2. If it's private, it's OK to assert argument preconditions instead of error-checking them. So stick in assert(size != 0). 3. Deal with negative step size internally. Like (leading x to stop SourceForge from left-flushing all the lines): if (step < 0) { x long temp = lo; x lo = hi; x hi = temp; x step = -step; } right after the new assert. 4. Remove the if/else argument swapping from all its callers. 5. Change the comment before the function to match. ------------------------------------------------------- Date: 2000-Aug-28 01:02 By: twouters Comment: Okay, but I have one question: WTH do you mean by '2.' ? assert what size ? the return value of getlenofrange ? all those values are passed-in, from Python expressions, so I don't think assert()in them is that good an idea. I really doubt you want the program to abort() if a user types in '[:0:]' or some such. Oh, and on the nit: I still don't agree, see my other comment in, uhm, some patch or other: we aren't using up a scarce resource with the MAGIC, as it's created by date, and it prevents *new* bytecode from running in *old* (relatively) interpreters, even if those old interpreters are only a few days old and the whole thing would 'only' happen to other developers. Or is there something else I don't know about ? ------------------------------------------------------- Date: 2000-Aug-28 01:32 By: tim_one Comment: Ack, 'twas a typo, I meant assert(step != 0); It's an *internal* (not user!) error if anyone calls this function with a zero step, so the function should at least assert that its caller isn't screwing up. The advantage to an assert over SystemError is simplicity and that there's no runtime cost in release builds. C functions should always verify their preconditions in debug builds, and public C functions regardless of build mode. The magic number isn't worth arguing about it -- leave it in, take it out, both OK by me (that's what "nit" means ). I always delete my .pyc/.pyo files after an update changes anything; I assume everyone does. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Mon Aug 28 19:55:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 11:55:21 -0700 Subject: [Patches] [Patch #100899] a smaller unicode name database Message-ID: <200008281855.LAA17347@delerium.i.sourceforge.net> Patch #100899 has been updated. Project: Category: None Status: Postponed Summary: a smaller unicode name database Follow-Ups: Date: 2000-Jul-15 15:43 By: effbot Comment: duh. it's too large for sourceforge. if you want to play with it, get it from: http://w1.132.telia.com/~u13208596/uninames-patch.txt ------------------------------------------------------- Date: 2000-Aug-03 11:59 By: lemburg Comment: How is the work on this patch coming along ? Will it be ready for 2.0 ? ------------------------------------------------------- Date: 2000-Aug-15 10:42 By: tim_one Comment: /F or MAL, what's going on with this? MAL, did you look at the patch? /F, do you feel it's done? ------------------------------------------------------- Date: 2000-Aug-23 11:39 By: tim_one Comment: Assigned back to /F because he agrees the ball bounced back into his court: [/F, in Python-Dev mail] mal has reviewed the patch, and is waiting for an update from me. ------------------------------------------------------- Date: 2000-Aug-24 04:37 By: lemburg Comment: I'd rather see this patch postponed. Reason: We're not in a hury here -- better get this done right than to quickly throw together a set of patches without some more extensive testing. Comment for future reference: --------------------- Note that I would also like to unify the different Unicode databases (ctype DBs, Unicode DB and Unicode name DB) into one single unicodedb access module which will be written in Python. The sibling C modules can then be loaded dynamically and in a lazy fashion. This will result in an implementation which should be much easier to maintain than the current (2.0) setup. ------------------------------------------------------- Date: 2000-Aug-28 11:55 By: effbot Comment: postponed, for now. I'm still working on the full unidb package, and will reopen this patch again when I've fixed the other things that needs to be fixed before 2.0b1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100899&group_id=5470 From noreply@sourceforge.net Mon Aug 28 21:31:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 13:31:00 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008282031.NAA20950@delerium.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- Date: 2000-Aug-27 14:04 By: twouters Comment: Alright, here's an updated version. I also included graminit.h and .c, because I don't know if you can run pgen, and if you complain about graminit.h not patching, I guess you can't ;-) (the fact that graminit.h was included in the previous patch was an honest mistake. But if you intend to read this patch: there's nothing interesting below graminit.c, which is about 900 lines.) ------------------------------------------------------- Date: 2000-Aug-28 00:31 By: tim_one Comment: Assigned to Fred to eyeball the docs; assign back to me if you're happy, else to Thomas if you're not. Thomas, this looks good! I have a nit and a complaint. The nit is that we don't need to keep bumping import's magic number -- once per public release should be enough. The complaint is that PyList_GetLenOfRange is brittle. In the context the code originally appeared, it was file-private, so all call sites were known and close by, that its assumptions were met was easy to verify, and that it did only 48% of the job didn't matter. But here it's almost part of the public API: it should do the whole job. By that I mean it should verify that its step argument is non-zero, and if the step argument is less than 0 it should shuffle the input values around to compute the correct answer. As is, this delicate shuffling is duplicated in its callers, and if someone happens to pass in a step < 0 it's just hosed. I would prefer: 1. Rename it with a leading underscore. This doesn't seem useful enough to be in the public API. 2. If it's private, it's OK to assert argument preconditions instead of error-checking them. So stick in assert(size != 0). 3. Deal with negative step size internally. Like (leading x to stop SourceForge from left-flushing all the lines): if (step < 0) { x long temp = lo; x lo = hi; x hi = temp; x step = -step; } right after the new assert. 4. Remove the if/else argument swapping from all its callers. 5. Change the comment before the function to match. ------------------------------------------------------- Date: 2000-Aug-28 01:02 By: twouters Comment: Okay, but I have one question: WTH do you mean by '2.' ? assert what size ? the return value of getlenofrange ? all those values are passed-in, from Python expressions, so I don't think assert()in them is that good an idea. I really doubt you want the program to abort() if a user types in '[:0:]' or some such. Oh, and on the nit: I still don't agree, see my other comment in, uhm, some patch or other: we aren't using up a scarce resource with the MAGIC, as it's created by date, and it prevents *new* bytecode from running in *old* (relatively) interpreters, even if those old interpreters are only a few days old and the whole thing would 'only' happen to other developers. Or is there something else I don't know about ? ------------------------------------------------------- Date: 2000-Aug-28 01:32 By: tim_one Comment: Ack, 'twas a typo, I meant assert(step != 0); It's an *internal* (not user!) error if anyone calls this function with a zero step, so the function should at least assert that its caller isn't screwing up. The advantage to an assert over SystemError is simplicity and that there's no runtime cost in release builds. C functions should always verify their preconditions in debug builds, and public C functions regardless of build mode. The magic number isn't worth arguing about it -- leave it in, take it out, both OK by me (that's what "nit" means ). I always delete my .pyc/.pyo files after an update changes anything; I assume everyone does. ------------------------------------------------------- Date: 2000-Aug-28 13:30 By: twouters Comment: Ok, bettah version, that should address all Tim's issues. And I dropped the Upping of the ByteCodeMagic too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Mon Aug 28 21:53:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 13:53:39 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008282053.NAA21793@delerium.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- Date: 2000-Aug-27 14:04 By: twouters Comment: Alright, here's an updated version. I also included graminit.h and .c, because I don't know if you can run pgen, and if you complain about graminit.h not patching, I guess you can't ;-) (the fact that graminit.h was included in the previous patch was an honest mistake. But if you intend to read this patch: there's nothing interesting below graminit.c, which is about 900 lines.) ------------------------------------------------------- Date: 2000-Aug-28 00:31 By: tim_one Comment: Assigned to Fred to eyeball the docs; assign back to me if you're happy, else to Thomas if you're not. Thomas, this looks good! I have a nit and a complaint. The nit is that we don't need to keep bumping import's magic number -- once per public release should be enough. The complaint is that PyList_GetLenOfRange is brittle. In the context the code originally appeared, it was file-private, so all call sites were known and close by, that its assumptions were met was easy to verify, and that it did only 48% of the job didn't matter. But here it's almost part of the public API: it should do the whole job. By that I mean it should verify that its step argument is non-zero, and if the step argument is less than 0 it should shuffle the input values around to compute the correct answer. As is, this delicate shuffling is duplicated in its callers, and if someone happens to pass in a step < 0 it's just hosed. I would prefer: 1. Rename it with a leading underscore. This doesn't seem useful enough to be in the public API. 2. If it's private, it's OK to assert argument preconditions instead of error-checking them. So stick in assert(size != 0). 3. Deal with negative step size internally. Like (leading x to stop SourceForge from left-flushing all the lines): if (step < 0) { x long temp = lo; x lo = hi; x hi = temp; x step = -step; } right after the new assert. 4. Remove the if/else argument swapping from all its callers. 5. Change the comment before the function to match. ------------------------------------------------------- Date: 2000-Aug-28 01:02 By: twouters Comment: Okay, but I have one question: WTH do you mean by '2.' ? assert what size ? the return value of getlenofrange ? all those values are passed-in, from Python expressions, so I don't think assert()in them is that good an idea. I really doubt you want the program to abort() if a user types in '[:0:]' or some such. Oh, and on the nit: I still don't agree, see my other comment in, uhm, some patch or other: we aren't using up a scarce resource with the MAGIC, as it's created by date, and it prevents *new* bytecode from running in *old* (relatively) interpreters, even if those old interpreters are only a few days old and the whole thing would 'only' happen to other developers. Or is there something else I don't know about ? ------------------------------------------------------- Date: 2000-Aug-28 01:32 By: tim_one Comment: Ack, 'twas a typo, I meant assert(step != 0); It's an *internal* (not user!) error if anyone calls this function with a zero step, so the function should at least assert that its caller isn't screwing up. The advantage to an assert over SystemError is simplicity and that there's no runtime cost in release builds. C functions should always verify their preconditions in debug builds, and public C functions regardless of build mode. The magic number isn't worth arguing about it -- leave it in, take it out, both OK by me (that's what "nit" means ). I always delete my .pyc/.pyo files after an update changes anything; I assume everyone does. ------------------------------------------------------- Date: 2000-Aug-28 13:30 By: twouters Comment: Ok, bettah version, that should address all Tim's issues. And I dropped the Upping of the ByteCodeMagic too. ------------------------------------------------------- Date: 2000-Aug-28 13:53 By: gvanrossum Comment: Oops. Sorry. I'm getting second thoughts about this. I'll post to python-dev. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Mon Aug 28 23:47:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 15:47:35 -0700 Subject: [Patches] [Patch #101312] gettext: Bi-endianness, catalog information, Unicode Message-ID: <200008282247.PAA25928@delerium.i.sourceforge.net> Patch #101312 has been updated. Project: Category: library Status: Closed Summary: gettext: Bi-endianness, catalog information, Unicode Follow-Ups: Date: 2000-Aug-27 02:16 By: moshez Comment: Assigned to Barry, as he seems to be the i18n guy. ------------------------------------------------------- Date: 2000-Aug-28 15:47 By: bwarsaw Comment: I've merged these features into my working copy of gettext.py. They'll soon make it into the checked in revision. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101312&group_id=5470 From noreply@sourceforge.net Mon Aug 28 23:48:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 15:48:32 -0700 Subject: [Patches] [Patch #101173] Adding gettext Message-ID: <200008282248.PAA25961@delerium.i.sourceforge.net> Patch #101173 has been updated. Project: Category: library Status: Closed Summary: Adding gettext Follow-Ups: Date: 2000-Aug-15 11:50 By: tim_one Comment: Assigned to Barry cuz he already put himself down in PEP200 as the gettext guy. ------------------------------------------------------- Date: 2000-Aug-28 15:48 By: bwarsaw Comment: gettext.py will be part of 2.0, but with a slightly different API than presented here. module, tests, and docs are now checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101173&group_id=5470 From noreply@sourceforge.net Tue Aug 29 05:32:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 21:32:55 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008290432.VAA05476@delerium.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- Date: 2000-Aug-27 14:04 By: twouters Comment: Alright, here's an updated version. I also included graminit.h and .c, because I don't know if you can run pgen, and if you complain about graminit.h not patching, I guess you can't ;-) (the fact that graminit.h was included in the previous patch was an honest mistake. But if you intend to read this patch: there's nothing interesting below graminit.c, which is about 900 lines.) ------------------------------------------------------- Date: 2000-Aug-28 00:31 By: tim_one Comment: Assigned to Fred to eyeball the docs; assign back to me if you're happy, else to Thomas if you're not. Thomas, this looks good! I have a nit and a complaint. The nit is that we don't need to keep bumping import's magic number -- once per public release should be enough. The complaint is that PyList_GetLenOfRange is brittle. In the context the code originally appeared, it was file-private, so all call sites were known and close by, that its assumptions were met was easy to verify, and that it did only 48% of the job didn't matter. But here it's almost part of the public API: it should do the whole job. By that I mean it should verify that its step argument is non-zero, and if the step argument is less than 0 it should shuffle the input values around to compute the correct answer. As is, this delicate shuffling is duplicated in its callers, and if someone happens to pass in a step < 0 it's just hosed. I would prefer: 1. Rename it with a leading underscore. This doesn't seem useful enough to be in the public API. 2. If it's private, it's OK to assert argument preconditions instead of error-checking them. So stick in assert(size != 0). 3. Deal with negative step size internally. Like (leading x to stop SourceForge from left-flushing all the lines): if (step < 0) { x long temp = lo; x lo = hi; x hi = temp; x step = -step; } right after the new assert. 4. Remove the if/else argument swapping from all its callers. 5. Change the comment before the function to match. ------------------------------------------------------- Date: 2000-Aug-28 01:02 By: twouters Comment: Okay, but I have one question: WTH do you mean by '2.' ? assert what size ? the return value of getlenofrange ? all those values are passed-in, from Python expressions, so I don't think assert()in them is that good an idea. I really doubt you want the program to abort() if a user types in '[:0:]' or some such. Oh, and on the nit: I still don't agree, see my other comment in, uhm, some patch or other: we aren't using up a scarce resource with the MAGIC, as it's created by date, and it prevents *new* bytecode from running in *old* (relatively) interpreters, even if those old interpreters are only a few days old and the whole thing would 'only' happen to other developers. Or is there something else I don't know about ? ------------------------------------------------------- Date: 2000-Aug-28 01:32 By: tim_one Comment: Ack, 'twas a typo, I meant assert(step != 0); It's an *internal* (not user!) error if anyone calls this function with a zero step, so the function should at least assert that its caller isn't screwing up. The advantage to an assert over SystemError is simplicity and that there's no runtime cost in release builds. C functions should always verify their preconditions in debug builds, and public C functions regardless of build mode. The magic number isn't worth arguing about it -- leave it in, take it out, both OK by me (that's what "nit" means ). I always delete my .pyc/.pyo files after an update changes anything; I assume everyone does. ------------------------------------------------------- Date: 2000-Aug-28 13:30 By: twouters Comment: Ok, bettah version, that should address all Tim's issues. And I dropped the Upping of the ByteCodeMagic too. ------------------------------------------------------- Date: 2000-Aug-28 13:53 By: gvanrossum Comment: Oops. Sorry. I'm getting second thoughts about this. I'll post to python-dev. ------------------------------------------------------- Date: 2000-Aug-28 21:32 By: tim_one Comment: Assigned to Guido. Please Reject or assign back to me (I quickly scanned Thomas's changes, and *think* they're spot-on, but if this is going in I want to spend a little more time with the patch before Accept'ing it). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Tue Aug 29 09:05:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 01:05:33 -0700 Subject: [Patches] [Patch #101335] Adds login to auth-type servers Message-ID: <200008290805.BAA12533@delerium.i.sourceforge.net> Patch #101335 has been updated. Project: Category: library Status: Open Summary: Adds login to auth-type servers ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101335&group_id=5470 From noreply@sourceforge.net Tue Aug 29 10:22:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 02:22:27 -0700 Subject: [Patches] [Patch #101335] Adds login to auth-type servers Message-ID: <200008290922.CAA20870@bush.i.sourceforge.net> Patch #101335 has been updated. Project: Category: library Status: Postponed Summary: Adds login to auth-type servers Follow-Ups: Date: 2000-Aug-29 02:22 By: moshez Comment: Postponed -- we're in feature freeze. Assigned to Jeremy in case he disagrees. Note also that it's preferable to submit patches in diff format, not as human-readable summaries. Try "diff -c". ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101335&group_id=5470 From noreply@sourceforge.net Tue Aug 29 12:33:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 04:33:28 -0700 Subject: [Patches] [Patch #101337] Cleanup configuration for FreeBSD Message-ID: <200008291133.EAA19799@delerium.i.sourceforge.net> Patch #101337 has been updated. Project: Category: Build Status: Open Summary: Cleanup configuration for FreeBSD ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101337&group_id=5470 From noreply@sourceforge.net Tue Aug 29 12:45:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 04:45:22 -0700 Subject: [Patches] [Patch #101338] don't create group-writable dirs; don't install *.orig Message-ID: <200008291145.EAA20189@delerium.i.sourceforge.net> Patch #101338 has been updated. Project: Category: Build Status: Open Summary: don't create group-writable dirs; don't install *.orig ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101338&group_id=5470 From noreply@sourceforge.net Tue Aug 29 12:47:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 04:47:11 -0700 Subject: [Patches] [Patch #101339] posixfile.py: add support for FreeBSD-[45] Message-ID: <200008291147.EAA20324@delerium.i.sourceforge.net> Patch #101339 has been updated. Project: Category: library Status: Open Summary: posixfile.py: add support for FreeBSD-[45] ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101339&group_id=5470 From noreply@sourceforge.net Tue Aug 29 12:48:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 04:48:32 -0700 Subject: [Patches] [Patch #101340] test_fcntl.py: add support for FreeBSD-[45] Message-ID: <200008291148.EAA20349@delerium.i.sourceforge.net> Patch #101340 has been updated. Project: Category: library Status: Open Summary: test_fcntl.py: add support for FreeBSD-[45] ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101340&group_id=5470 From noreply@sourceforge.net Tue Aug 29 12:49:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 04:49:40 -0700 Subject: [Patches] [Patch #101341] tempfile.py: add /var/tmp Message-ID: <200008291149.EAA20374@delerium.i.sourceforge.net> Patch #101341 has been updated. Project: Category: library Status: Open Summary: tempfile.py: add /var/tmp ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101341&group_id=5470 From noreply@sourceforge.net Tue Aug 29 12:56:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 04:56:07 -0700 Subject: [Patches] [Patch #101342] remove -Wstrict-prototypes warnings [aka: Anal Crusade I] Message-ID: <200008291156.EAA26426@bush.i.sourceforge.net> Patch #101342 has been updated. Project: Category: core (C code) Status: Open Summary: remove -Wstrict-prototypes warnings [aka: Anal Crusade I] ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101342&group_id=5470 From noreply@sourceforge.net Tue Aug 29 12:59:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 04:59:35 -0700 Subject: [Patches] [Patch #101342] remove -Wstrict-prototypes warnings [aka: Anal Crusade I] Message-ID: <200008291159.EAA26564@bush.i.sourceforge.net> Patch #101342 has been updated. Project: Category: core (C code) Status: Open Summary: remove -Wstrict-prototypes warnings [aka: Anal Crusade I] Follow-Ups: Date: 2000-Aug-29 04:59 By: nowonder Comment: there is one remaining warning in Modules/main.c. The comment says that getopt() has no standardized prototype. The one given (int, char **, char *) does not work on Linux, but (int, char *const *, const char *) does. Is it worth doing some autoconf magic, or should we just let the warning stick where it is? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101342&group_id=5470 From thomas@xs4all.net Tue Aug 29 15:24:50 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 29 Aug 2000 16:24:50 +0200 Subject: [Patches] [Patch #101342] remove -Wstrict-prototypes warnings [aka: Anal Crusade I] In-Reply-To: <200008291159.EAA26564@bush.i.sourceforge.net>; from noreply@sourceforge.net on Tue, Aug 29, 2000 at 04:59:35AM -0700 References: <200008291159.EAA26564@bush.i.sourceforge.net> Message-ID: <20000829162450.M500@xs4all.nl> On Tue, Aug 29, 2000 at 04:59:35AM -0700, noreply@sourceforge.net wrote: > Summary: remove -Wstrict-prototypes warnings [aka: Anal Crusade I] > By: nowonder > Comment: > there is one remaining warning in Modules/main.c. The comment says that > getopt() has no standardized prototype. The one given (int, char **, char > *) does not work on Linux, but (int, char *const *, const char *) does. Is > it worth doing some autoconf magic, or should we just let the warning > stick where it is? Do yourself (and the rest of us) a favor, and move the 'getopt' prototype into pyport.h and comment it out, re-adding it only for those platforms that don't have a getopt prototype. The problem is that a 'char * const *' (or was it a const char ** ?) and a 'char **' are two *incompatible* types, according to the ANSI C std. It won't matter when you call the function, but it does when you provide a conflicting prototype yourself. There simply is no prototype that will work everywhere. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Tue Aug 29 15:53:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 07:53:08 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200008291453.HAA27078@delerium.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Postponed Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- Date: 2000-Aug-27 14:04 By: twouters Comment: Alright, here's an updated version. I also included graminit.h and .c, because I don't know if you can run pgen, and if you complain about graminit.h not patching, I guess you can't ;-) (the fact that graminit.h was included in the previous patch was an honest mistake. But if you intend to read this patch: there's nothing interesting below graminit.c, which is about 900 lines.) ------------------------------------------------------- Date: 2000-Aug-28 00:31 By: tim_one Comment: Assigned to Fred to eyeball the docs; assign back to me if you're happy, else to Thomas if you're not. Thomas, this looks good! I have a nit and a complaint. The nit is that we don't need to keep bumping import's magic number -- once per public release should be enough. The complaint is that PyList_GetLenOfRange is brittle. In the context the code originally appeared, it was file-private, so all call sites were known and close by, that its assumptions were met was easy to verify, and that it did only 48% of the job didn't matter. But here it's almost part of the public API: it should do the whole job. By that I mean it should verify that its step argument is non-zero, and if the step argument is less than 0 it should shuffle the input values around to compute the correct answer. As is, this delicate shuffling is duplicated in its callers, and if someone happens to pass in a step < 0 it's just hosed. I would prefer: 1. Rename it with a leading underscore. This doesn't seem useful enough to be in the public API. 2. If it's private, it's OK to assert argument preconditions instead of error-checking them. So stick in assert(size != 0). 3. Deal with negative step size internally. Like (leading x to stop SourceForge from left-flushing all the lines): if (step < 0) { x long temp = lo; x lo = hi; x hi = temp; x step = -step; } right after the new assert. 4. Remove the if/else argument swapping from all its callers. 5. Change the comment before the function to match. ------------------------------------------------------- Date: 2000-Aug-28 01:02 By: twouters Comment: Okay, but I have one question: WTH do you mean by '2.' ? assert what size ? the return value of getlenofrange ? all those values are passed-in, from Python expressions, so I don't think assert()in them is that good an idea. I really doubt you want the program to abort() if a user types in '[:0:]' or some such. Oh, and on the nit: I still don't agree, see my other comment in, uhm, some patch or other: we aren't using up a scarce resource with the MAGIC, as it's created by date, and it prevents *new* bytecode from running in *old* (relatively) interpreters, even if those old interpreters are only a few days old and the whole thing would 'only' happen to other developers. Or is there something else I don't know about ? ------------------------------------------------------- Date: 2000-Aug-28 01:32 By: tim_one Comment: Ack, 'twas a typo, I meant assert(step != 0); It's an *internal* (not user!) error if anyone calls this function with a zero step, so the function should at least assert that its caller isn't screwing up. The advantage to an assert over SystemError is simplicity and that there's no runtime cost in release builds. C functions should always verify their preconditions in debug builds, and public C functions regardless of build mode. The magic number isn't worth arguing about it -- leave it in, take it out, both OK by me (that's what "nit" means ). I always delete my .pyc/.pyo files after an update changes anything; I assume everyone does. ------------------------------------------------------- Date: 2000-Aug-28 13:30 By: twouters Comment: Ok, bettah version, that should address all Tim's issues. And I dropped the Upping of the ByteCodeMagic too. ------------------------------------------------------- Date: 2000-Aug-28 13:53 By: gvanrossum Comment: Oops. Sorry. I'm getting second thoughts about this. I'll post to python-dev. ------------------------------------------------------- Date: 2000-Aug-28 21:32 By: tim_one Comment: Assigned to Guido. Please Reject or assign back to me (I quickly scanned Thomas's changes, and *think* they're spot-on, but if this is going in I want to spend a little more time with the patch before Accept'ing it). ------------------------------------------------------- Date: 2000-Aug-29 07:53 By: gvanrossum Comment: Postponed - this may still happen but definitely not in 2.0, there's too much doubt about whether this is the right syntax and too many alternative proposals that have to be reviewed. (Well, at least one. :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Tue Aug 29 15:55:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 07:55:20 -0700 Subject: [Patches] [Patch #101341] tempfile.py: add /var/tmp Message-ID: <200008291455.HAA27115@delerium.i.sourceforge.net> Patch #101341 has been updated. Project: Category: library Status: Closed Summary: tempfile.py: add /var/tmp Follow-Ups: Date: 2000-Aug-29 07:55 By: gvanrossum Comment: Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101341&group_id=5470 From noreply@sourceforge.net Tue Aug 29 15:56:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 07:56:29 -0700 Subject: [Patches] [Patch #101340] test_fcntl.py: add support for FreeBSD-[45] Message-ID: <200008291456.HAA27132@delerium.i.sourceforge.net> Patch #101340 has been updated. Project: Category: library Status: Closed Summary: test_fcntl.py: add support for FreeBSD-[45] Follow-Ups: Date: 2000-Aug-29 07:56 By: gvanrossum Comment: Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101340&group_id=5470 From noreply@sourceforge.net Tue Aug 29 15:57:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 07:57:33 -0700 Subject: [Patches] [Patch #101339] posixfile.py: add support for FreeBSD-[45] Message-ID: <200008291457.HAA27267@delerium.i.sourceforge.net> Patch #101339 has been updated. Project: Category: library Status: Closed Summary: posixfile.py: add support for FreeBSD-[45] Follow-Ups: Date: 2000-Aug-29 07:57 By: gvanrossum Comment: Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101339&group_id=5470 From noreply@sourceforge.net Tue Aug 29 16:00:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 08:00:31 -0700 Subject: [Patches] [Patch #101338] don't create group-writable dirs; don't install *.orig Message-ID: <200008291500.IAA27321@delerium.i.sourceforge.net> Patch #101338 has been updated. Project: Category: Build Status: Closed Summary: don't create group-writable dirs; don't install *.orig Follow-Ups: Date: 2000-Aug-29 08:00 By: gvanrossum Comment: Applied. (Also fixed the comment referring to DIRMODE.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101338&group_id=5470 From noreply@sourceforge.net Tue Aug 29 16:07:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 08:07:17 -0700 Subject: [Patches] [Patch #101337] Cleanup configuration for FreeBSD Message-ID: <200008291507.IAA00789@bush.i.sourceforge.net> Patch #101337 has been updated. Project: Category: Build Status: Closed Summary: Cleanup configuration for FreeBSD Follow-Ups: Date: 2000-Aug-29 08:07 By: gvanrossum Comment: Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101337&group_id=5470 From noreply@sourceforge.net Tue Aug 29 16:58:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 08:58:46 -0700 Subject: [Patches] [Patch #101342] remove -Wstrict-prototypes warnings [aka: Anal Crusade I] Message-ID: <200008291558.IAA02809@bush.i.sourceforge.net> Patch #101342 has been updated. Project: Category: core (C code) Status: Open Summary: remove -Wstrict-prototypes warnings [aka: Anal Crusade I] Follow-Ups: Date: 2000-Aug-29 04:59 By: nowonder Comment: there is one remaining warning in Modules/main.c. The comment says that getopt() has no standardized prototype. The one given (int, char **, char *) does not work on Linux, but (int, char *const *, const char *) does. Is it worth doing some autoconf magic, or should we just let the warning stick where it is? ------------------------------------------------------- Date: 2000-Aug-29 08:58 By: nowonder Comment: Thomas proposed that I should "move the 'getopt' prototype into pyport.h and comment it out, re-adding it only for those platforms that don't have a getopt prototype." ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101342&group_id=5470 From noreply@sourceforge.net Tue Aug 29 17:31:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 09:31:46 -0700 Subject: [Patches] [Patch #101298] Enable Py_DEBUG via configure Message-ID: <200008291631.JAA03949@bush.i.sourceforge.net> Patch #101298 has been updated. Project: Category: Build Status: Open Summary: Enable Py_DEBUG via configure Follow-Ups: Date: 2000-Aug-25 06:07 By: montanaro Comment: Assigned to Thomas so he doesn't need to keep editing config.h manually. ;-) ------------------------------------------------------- Date: 2000-Aug-25 14:38 By: twouters Comment: Looks fine to me, though I would expand the 'help' message for this option a bit. State that it is for 'extensive debugging of the Python interpreter' or some such. And as far as I'm concerned, it's accepted. Oh, wait, not quite accepted: don't edit config.h.in manually. Edit acconfig.h to add a specific comment to a #define (just add the #define and the comment to that file) and then 'autoheader' will create config.h.in just like 'autoconf' creates configure from configure.in. (If the define is not present in acconfig.h, but is set in configure.in, a generic comment is used instead.) ------------------------------------------------------- Date: 2000-Aug-25 15:35 By: montanaro Comment: I've never used autoheader before. Simpleminded usage: autoheader acconfig.h > config.h.in fails with % autoheader acconfig.h error: AC_CONFIG_HEADER not found in acconfig.h  Trying it with no args yields % autoheader /usr/bin/autoheader: Symbol `WITH_LIBDB' is not covered\ by /usr/share/autoconf/acconfig.h ./acconfig.h Of course, there is no autoheader man page or info file on my system. What's the magic incantation? ------------------------------------------------------- Date: 2000-Aug-26 04:00 By: twouters Comment: You don't need to redirect the output of 'autoheader' (or 'autoconf' for that matter!) but you *are* apparently missing something important from acconfig.h. This is probably related to the other patches you have lying around :) If you *do* pass an argument to autoheader, the argument should be the configure.in file, not the acconfig.h file. The config.h.in file is generated from configure.in (by looking at what defines it sets) with help from acconfig.h. My earlier statement that 'a generic comment will be used if a #define is missing from acconfig.h' was probably a bit misleading, though: it's not that simple. Autoheader uses *two* acconfig.h files: a system-wide one, and the local one. The system-wide one contains the #defines & comments for the most common checks, but if you set one in configure.in which isn't in the global acconfig.h yet, you have to add it to the local acconfig.h yourself. In addition to the two acconfig.h files, autoheader also tries to figure out what #defines you set and auto-generates comments for those: the defines set by AC_CHECK_LIB(S), AC_CHECK_HEADERS, etc, are added automatically, unless they already exist in acconfig.h (in which case, the comment in acconfig.h is used instead of the generated one.) The error you get, about WITH_LIBDB, probably means you need to add WITH_LIBDB to acconfig.h. Oh, and no, there isn't a manpage for autoheader and autoconf, because it's GNU, and documentation on GNU software is primarily 'info'. You have to be lucky to get manpages :-S And 'info autoheader' won't work, because it's a command and not a package: you need to use 'info autoconf', and then look for autoheader (using 's'). That said, do you want me to grab your patch, fix it up and commit it, or do you want to give it a shot yourself ? ------------------------------------------------------- Date: 2000-Aug-26 10:22 By: montanaro Comment: Here's an updated version that includes acconfig.h. config.h.in was generated by autoheader. You should be able to apply this patch but will probably get some offset warnings from patch because I snipped out a couple other changes. Diffs for configure aren't included here. I will generate a proper configure file when checking this in. ------------------------------------------------------- Date: 2000-Aug-26 10:23 By: montanaro Comment: oh bother ... I forgot C-x C-s after trimming the patch... ------------------------------------------------------- Date: 2000-Aug-29 09:31 By: marangoz Comment: +1; looks good and works as expected on Linux. Side note: you needn't to include config.h.in in the patch -- this file is generated by autoheader from acconfig.h ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101298&group_id=5470 From noreply@sourceforge.net Tue Aug 29 17:38:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 09:38:16 -0700 Subject: [Patches] [Patch #101345] Remove obsolete --with(out)-readline option Message-ID: <200008291638.JAA04178@bush.i.sourceforge.net> Patch #101345 has been updated. Project: Category: Build Status: Open Summary: Remove obsolete --with(out)-readline option ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101345&group_id=5470 From noreply@sourceforge.net Tue Aug 29 17:40:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 09:40:24 -0700 Subject: [Patches] [Patch #101345] Remove obsolete --with(out)-readline option Message-ID: <200008291640.JAA04312@bush.i.sourceforge.net> Patch #101345 has been updated. Project: Category: Build Status: Open Summary: Remove obsolete --with(out)-readline option Follow-Ups: Date: 2000-Aug-29 09:40 By: marangoz Comment: I believe that it's time for this option to go away. It makes no sense for 2.0 to keep it alive and issue an error, if given, saying that the option is obsolete. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101345&group_id=5470 From noreply@sourceforge.net Tue Aug 29 18:51:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 10:51:40 -0700 Subject: [Patches] [Patch #101309] Specialization of dictionaries for strings. Message-ID: <200008291751.KAA01160@delerium.i.sourceforge.net> Patch #101309 has been updated. Project: Category: core (C code) Status: Open Summary: Specialization of dictionaries for strings. Follow-Ups: Date: 2000-Aug-25 22:26 By: fdrake Comment: This patch introduces some changes to the builtin dictionary type. These changes create a specialization of the type to better support efficient use of dictionaries as a runtime implementation detail. This patch causes all newly created dictionaries to be specialized for string keys; dictionaries are converted (trivially) to handle arbitrary keys as needed. If a non-string is used as a key (even if only doing a lookup and it fails), the dictionary is converted to a normal dictionary. To achieve faster performance, a specialized version of the lookdict() function is used. The specialized implementation can assume two things that the "normal" implementation cannot: - that all comparisons are always done using the PyString_Type.tp_compare function, avoiding some of the overhead of calling PyObject_Compare() and dereferencing the comparison function repeatedly, and - that the comparison function never raises an exception, since two strings can always be compared without an error. Some debugging code added to dictobject.c shows that most dictionaries created during the regression test are never converted to "normal" dictionaries, but always only use strings as keys: created 115874 string dicts converted 2658 to normal dicts 2.29% conversion rate Additional performance tests should be made. I expect that a patch such as this is most valuable if additional code is needed to robustify lookdict() to properly deal with exceptions from user-defined comparison functions (tp_compare handlers of __cmp__() functions in Python code). The patch duplicates the logic of the lookdict() function, which makes maintenance more tedious. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 From noreply@sourceforge.net Tue Aug 29 20:26:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 12:26:39 -0700 Subject: [Patches] [Patch #101346] fetch/restore exceptions around GC collections Message-ID: <200008291926.MAA04606@delerium.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Open Summary: fetch/restore exceptions around GC collections ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Tue Aug 29 20:29:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 12:29:04 -0700 Subject: [Patches] [Patch #101346] fetch/restore exceptions around GC collections Message-ID: <200008291929.MAA04751@delerium.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Open Summary: fetch/restore exceptions around GC collections Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Tue Aug 29 21:34:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 13:34:01 -0700 Subject: [Patches] [Patch #101346] fetch/restore exceptions around GC collections Message-ID: <200008292034.NAA13505@bush.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Open Summary: fetch/restore exceptions around GC collections Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- Date: 2000-Aug-29 13:34 By: jhylton Comment: Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations. Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception. It seems dangerous to ignore one completely, but it's not clear how to recover. If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Wed Aug 30 04:49:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 20:49:30 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008300349.UAA22525@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- Date: 2000-Aug-25 05:49 By: fdrake Comment: Performance has *not* been checked -- there's no need to do that until the patch *works*. I understand the performance issue here; Guido and I have turnned this one around a few times and it's just plain hard to get right. One thing to recall is that the current implementation is broken as well; try the test case Jeremy submitted when he filed the bug report. (Keep in mind that I'm calling this patch "NOT READY" still -- I have no intention of checking this in as it stands.) Clearing exceptions in the comparison is clearly a bad thing, but they're getting raised in a chunk of code that simply doesn't allow raising exceptions. This is not well explained in the comments; I'll try to improve them. One issue with the problem is that and exception in the comparison can cause us not to find the entry we're looking for; during C-level exception handling, we're still trying to propogate another exception as well. Even if the general solution proves too slow for use with the module dictionaries (which will require testing to determine), I have some ideas about what it would take to make those fast anyway. I'll describe those later on python-dev. ------------------------------------------------------- Date: 2000-Aug-25 07:12 By: lemburg Comment: Ok. Sorry if that last message sounded a bit like FUD. This needs to be fixed, but I do think that we should get some more feedback and ideas into this... so let's head for python-dev :-) ------------------------------------------------------- Date: 2000-Aug-29 20:49 By: fdrake Comment: Please review and advise regarding the importance of this bug. Not that this patch may have some problems; appearantly Guido was able to get it to break (missing tstate needed by PyErr_*() usage introduced here), but I've not received information needed to duplicate the breakage. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Wed Aug 30 04:51:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 20:51:39 -0700 Subject: [Patches] [Patch #101350] Fix SMTPlib for large messages Message-ID: <200008300351.UAA22582@delerium.i.sourceforge.net> Patch #101350 has been updated. Project: Category: library Status: Open Summary: Fix SMTPlib for large messages ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101350&group_id=5470 From noreply@sourceforge.net Wed Aug 30 05:21:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 21:21:48 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008300421.VAA23572@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- Date: 2000-Aug-25 05:49 By: fdrake Comment: Performance has *not* been checked -- there's no need to do that until the patch *works*. I understand the performance issue here; Guido and I have turnned this one around a few times and it's just plain hard to get right. One thing to recall is that the current implementation is broken as well; try the test case Jeremy submitted when he filed the bug report. (Keep in mind that I'm calling this patch "NOT READY" still -- I have no intention of checking this in as it stands.) Clearing exceptions in the comparison is clearly a bad thing, but they're getting raised in a chunk of code that simply doesn't allow raising exceptions. This is not well explained in the comments; I'll try to improve them. One issue with the problem is that and exception in the comparison can cause us not to find the entry we're looking for; during C-level exception handling, we're still trying to propogate another exception as well. Even if the general solution proves too slow for use with the module dictionaries (which will require testing to determine), I have some ideas about what it would take to make those fast anyway. I'll describe those later on python-dev. ------------------------------------------------------- Date: 2000-Aug-25 07:12 By: lemburg Comment: Ok. Sorry if that last message sounded a bit like FUD. This needs to be fixed, but I do think that we should get some more feedback and ideas into this... so let's head for python-dev :-) ------------------------------------------------------- Date: 2000-Aug-29 20:49 By: fdrake Comment: Please review and advise regarding the importance of this bug. Not that this patch may have some problems; appearantly Guido was able to get it to break (missing tstate needed by PyErr_*() usage introduced here), but I've not received information needed to duplicate the breakage. ------------------------------------------------------- Date: 2000-Aug-29 21:21 By: tim_one Comment: FYI, Guido told me the patch (or a close relative) made it thru the std test suite, but died running pystone(!). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Wed Aug 30 05:42:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 21:42:52 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008300442.VAA30211@bush.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- Date: 2000-Aug-25 05:49 By: fdrake Comment: Performance has *not* been checked -- there's no need to do that until the patch *works*. I understand the performance issue here; Guido and I have turnned this one around a few times and it's just plain hard to get right. One thing to recall is that the current implementation is broken as well; try the test case Jeremy submitted when he filed the bug report. (Keep in mind that I'm calling this patch "NOT READY" still -- I have no intention of checking this in as it stands.) Clearing exceptions in the comparison is clearly a bad thing, but they're getting raised in a chunk of code that simply doesn't allow raising exceptions. This is not well explained in the comments; I'll try to improve them. One issue with the problem is that and exception in the comparison can cause us not to find the entry we're looking for; during C-level exception handling, we're still trying to propogate another exception as well. Even if the general solution proves too slow for use with the module dictionaries (which will require testing to determine), I have some ideas about what it would take to make those fast anyway. I'll describe those later on python-dev. ------------------------------------------------------- Date: 2000-Aug-25 07:12 By: lemburg Comment: Ok. Sorry if that last message sounded a bit like FUD. This needs to be fixed, but I do think that we should get some more feedback and ideas into this... so let's head for python-dev :-) ------------------------------------------------------- Date: 2000-Aug-29 20:49 By: fdrake Comment: Please review and advise regarding the importance of this bug. Not that this patch may have some problems; appearantly Guido was able to get it to break (missing tstate needed by PyErr_*() usage introduced here), but I've not received information needed to duplicate the breakage. ------------------------------------------------------- Date: 2000-Aug-29 21:21 By: tim_one Comment: FYI, Guido told me the patch (or a close relative) made it thru the std test suite, but died running pystone(!). ------------------------------------------------------- Date: 2000-Aug-29 21:42 By: fdrake Comment: Guido told me that as well, but I was not able to reproduce it. He has not provided instructions to duplicate the failure; I just ran pystones.py as a script. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Wed Aug 30 05:46:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 21:46:54 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008300446.VAA24443@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- Date: 2000-Aug-25 05:49 By: fdrake Comment: Performance has *not* been checked -- there's no need to do that until the patch *works*. I understand the performance issue here; Guido and I have turnned this one around a few times and it's just plain hard to get right. One thing to recall is that the current implementation is broken as well; try the test case Jeremy submitted when he filed the bug report. (Keep in mind that I'm calling this patch "NOT READY" still -- I have no intention of checking this in as it stands.) Clearing exceptions in the comparison is clearly a bad thing, but they're getting raised in a chunk of code that simply doesn't allow raising exceptions. This is not well explained in the comments; I'll try to improve them. One issue with the problem is that and exception in the comparison can cause us not to find the entry we're looking for; during C-level exception handling, we're still trying to propogate another exception as well. Even if the general solution proves too slow for use with the module dictionaries (which will require testing to determine), I have some ideas about what it would take to make those fast anyway. I'll describe those later on python-dev. ------------------------------------------------------- Date: 2000-Aug-25 07:12 By: lemburg Comment: Ok. Sorry if that last message sounded a bit like FUD. This needs to be fixed, but I do think that we should get some more feedback and ideas into this... so let's head for python-dev :-) ------------------------------------------------------- Date: 2000-Aug-29 20:49 By: fdrake Comment: Please review and advise regarding the importance of this bug. Not that this patch may have some problems; appearantly Guido was able to get it to break (missing tstate needed by PyErr_*() usage introduced here), but I've not received information needed to duplicate the breakage. ------------------------------------------------------- Date: 2000-Aug-29 21:21 By: tim_one Comment: FYI, Guido told me the patch (or a close relative) made it thru the std test suite, but died running pystone(!). ------------------------------------------------------- Date: 2000-Aug-29 21:42 By: fdrake Comment: Guido told me that as well, but I was not able to reproduce it. He has not provided instructions to duplicate the failure; I just ran pystones.py as a script. ------------------------------------------------------- Date: 2000-Aug-29 21:46 By: tim_one Comment: Actually, I'm relieved to hear that! pystone doesn't do anything strange at all. Guess we'll have to wait for Guido to chime in ... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Wed Aug 30 10:00:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 02:00:53 -0700 Subject: [Patches] [Patch #101352] PyOS_StackCheck for Unix Message-ID: <200008300900.CAA06325@bush.i.sourceforge.net> Patch #101352 has been updated. Project: Category: core (C code) Status: Open Summary: PyOS_StackCheck for Unix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101352&group_id=5470 From noreply@sourceforge.net Wed Aug 30 10:15:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 02:15:35 -0700 Subject: [Patches] [Patch #101352] PyOS_StackCheck for Unix Message-ID: <200008300915.CAA00661@delerium.i.sourceforge.net> Patch #101352 has been updated. Project: Category: core (C code) Status: Open Summary: PyOS_StackCheck for Unix Follow-Ups: Date: 2000-Aug-30 02:15 By: lemburg Comment: Since getrlimit() might not return useful results on all Unix platforms, I'd suggest adding a test to the configure script (the test should check whether getrlimit() returns a non-zero value for the stack limit). Also, due to the added call overhead, I'd suggest raising the modulo value in ceval's hook to call PyOS_CheckStack(): #ifdef USE_STACKCHECK if (tstate->recursion_depth%10 == 0 && PyOS_CheckStack()) { PyErr_SetString(PyExc_MemoryError, "Stack overflow"); return NULL; } #endif to about 100. That way the stack check will most likely only be triggered by programs which actually use recursion, rather than those which only use shallow function call nesting (10 seems to low w/r to these). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101352&group_id=5470 From noreply@sourceforge.net Wed Aug 30 10:55:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 02:55:38 -0700 Subject: [Patches] [Patch #101354] New files: plat-freebsd{4,5}/* Message-ID: <200008300955.CAA02009@delerium.i.sourceforge.net> Patch #101354 has been updated. Project: Category: library Status: Open Summary: New files: plat-freebsd{4,5}/* ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101354&group_id=5470 From R.Liebscher@gmx.de Wed Aug 30 11:57:20 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed, 30 Aug 2000 12:57:20 +0200 Subject: [Patches] Re: [Patch #101207] BeOS: installing of linker script References: <200008241811.LAA26191@bush.i.sourceforge.net> Message-ID: <39ACE890.64A31255@gmx.de> This is a multi-part message in MIME format. --------------E22B3A2781ECBD3754EF4293 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit noreply@sourceforge.net wrote: > > Patch #101207 has been updated. > > Project: > Category: Build > Status: Closed > Summary: BeOS: installing of linker script > ------------------------------------------------------ > > Date: 2000-Aug-17 18:24 > By: fdrake > > Comment: > Please change this to work the same way as for AIX. The Distutils code may need to be adjusted to be able to locate the linkmodule script; please contribute a patch for that as well or post a bug report for distutils, so that Greg Ward can fix it. > > Thanks! > ------------------------------------------------------- > > Date: 2000-Aug-24 14:11 > By: fdrake > > Comment: > Adjusted the location to match that used on other platforms, and add the "echo" statements to make it behave similarly to the AIX equivalent section. > > Checked in as Makefile.in revision 1.97. > ------------------------------------------------------- It looks good, but while testing it, I found that we have to install dl_export.h in the same directory as config.h. (My first tests didn't show this, because I had still the python source directory there, and the Makefile of the installed version used a include path to the sources' BeOS directory.) I attached a patch which installs dl_export.h in the same directory as config.h . Kind regards Rene Liebscher --------------E22B3A2781ECBD3754EF4293 Content-Type: text/plain; charset=us-ascii; name="dl_export_h.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dl_export_h.patch" Index: python/dist/src/Makefile.in =================================================================== RCS file: /cvsroot/python/python/dist/src/Makefile.in,v retrieving revision 1.98 diff -c -r1.98 Makefile.in *** python/dist/src/Makefile.in 2000/08/29 15:00:11 1.98 --- python/dist/src/Makefile.in 2000/08/30 10:54:58 *************** *** 362,367 **** --- 362,373 ---- $(INSTALL_DATA) $$i $(INCLUDEPY); \ done $(INSTALL_DATA) config.h $(CONFINCLUDEPY)/config.h + @if [ "$(MACHDEP)" == "beos" ] ; then \ + echo; echo "Installing BeOS specific header files"; \ + $(INSTALL_DATA) BeOS/dl_export.h $(CONFINCLUDEPY)/dl_export.h; \ + echo "$(CONFINCLUDEPY)/dl_export.h"; \ + else true; \ + fi # Install the library and miscellaneous stuff needed for extending/embedding # This goes into $(exec_prefix) *************** *** 411,418 **** echo; echo "$(LIBPL)/README"; \ $(INSTALL_DATA) BeOS/README.readline-2.2 $(LIBPL)/README.readline-2.2; \ echo "$(LIBPL)/README.readline-2.2"; \ - $(INSTALL_DATA) BeOS/dl_export.h $(LIBPL)/dl_export.h; \ - echo "$(LIBPL)/dl_export.h"; \ $(INSTALL_PROGRAM) BeOS/ar-fake $(LIBPL)/ar-fake; \ echo "$(LIBPL)/ar-fake"; \ $(INSTALL_PROGRAM) BeOS/linkcc $(LIBPL)/linkcc; \ --- 417,422 ---- --------------E22B3A2781ECBD3754EF4293-- From noreply@sourceforge.net Wed Aug 30 14:40:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 06:40:59 -0700 Subject: [Patches] [Patch #101346] fetch/restore exceptions around GC collections Message-ID: <200008301340.GAA09899@delerium.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Open Summary: fetch/restore exceptions around GC collections Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- Date: 2000-Aug-29 13:34 By: jhylton Comment: Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations. Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception. It seems dangerous to ignore one completely, but it's not clear how to recover. If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c ------------------------------------------------------- Date: 2000-Aug-30 06:40 By: marangoz Comment: Hm. The offending PyErr_Clear should definitely be removed. Not sure that surrounding the collection process with err fetch/restore is a good idea though. The collector could trigger __del__ methods which in turn could set exceptions. The GC code itself should be absolutely transparent w.r.t. exceptions and should propagate them if they're raised elsewhere. So, what needs to be done here is: - remove PyErrClear - use PySys_WriteStderr for debugging. The whole "output" stuff in gcmodule.c should be zapped, because it's a suboptimal and incomplete PySys_WriteStderr. The latter takes care to fetch/restore exceptions when printing the output. PS: now that this is assigned to me, can I upload another patch over this one for review? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Wed Aug 30 15:02:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 07:02:57 -0700 Subject: [Patches] [Patch #101085] calendar.py extensions Message-ID: <200008301402.HAA10710@delerium.i.sourceforge.net> Patch #101085 has been updated. Project: Category: Modules Status: Closed Summary: calendar.py extensions Follow-Ups: Date: 2000-Aug-05 18:54 By: goodger Comment: (1) Allows any weekday to start a week, not just Monday as hardcoded. (2) Added functions which return week, month and year calendars as strings (e.g. prmonth() prints, month() returns string), so we aren't forced to play with stdout when we don't want to print. Had to modify some (manditory, therefore non-keyword) parameters in prweek(), prmonth() & prcal()'s signatures. (3) Removed "caching interface to _monthcalendar" as unnecessary complexity. ------------------------------------------------------- Date: 2000-Aug-15 12:05 By: tim_one Comment: Assigned to Skip because he's a Calendar kind of fellow. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 13:16 By: montanaro Comment: Looks reasonable with the following recommendations and questions: * the w (width) and l (length) keyword args to month and prmonth should probably be called something else (columnwidth and rowheight perhaps?). Should calendar/prcal have columnwidth, rowheight and gutterwidth optional arguments? * I think the month() function should include a trailing newline and that prmonth should call sys.stdout.write. Same for the calendar/prcal pair. * Should firstweekday accept string arguments as well so people don't have to map from days of the week to integers? What does this imply for locales? Can English just be assumed? ------------------------------------------------------- Date: 2000-Aug-17 13:21 By: montanaro Comment: Just occurred to me... Perhaps firstweekday() should reset to the default for the module (Monday) instead of the US convention (Sunday first). ------------------------------------------------------- Date: 2000-Aug-23 19:20 By: montanaro Comment: sent note to David asking about progress on an updated patch. ------------------------------------------------------- Date: 2000-Aug-23 21:16 By: goodger Comment: 1: Skip Montanaro ("SM") writes: SM> * the w (width) and l (length) keyword args to month and SM> prmonth should probably be called something else SM> (columnwidth and rowheight perhaps?) This would break backwards compatibility on prmonth() with keyword arguments. 2: SM> * I think the month() function should include a trailing SM> newline and that prmonth should call sys.stdout.write. SM> Same for the calendar/prcal pair. Newlines: Yes, will do. sys.stdout.write: Why? What advantage would that have over 'print month(theyear, ...),' (note the trailing comma)? 3: SM> * Should firstweekday accept string arguments as well SM> so people don't have to map from days of the week to SM> integers? What does this imply for locales? Can SM> English just be assumed? Supporting locales would entail a much more ambitious patch (perhaps a complete rewrite). Realistically speaking, I don't think it's worth it. Perhaps an enumeration instead? I've added: (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday) = range(7) 4: SM> Perhaps firstweekday() should SM> reset to the default for the module (Monday) instead of SM> the US convention (Sunday first). Since Monday is the default upon importing the module, nobody would call firstweekday() unless they wanted to change it. I will drop the default altogether, rather than forcing behaviour. ------------------------------------------------------- Date: 2000-Aug-23 21:18 By: goodger Comment: 4: SM>I imagine you're correct. I was thinking about the case where someone wants SM>to fiddle the starting day of the week, then restore it: SM>Maybe firstweekday should return the previous value. I've renamed the setting function to setfirstweekday(weekday), and now firstweekday() returns the current setting. I think its better to keep functional and procedural (side-effect) separate. ------------------------------------------------------- Date: 2000-Aug-26 14:13 By: goodger Comment: Revised patch: modified convenience weekday enumeration values to uppercase, as per Python library module standards for constants. ------------------------------------------------------- Date: 2000-Aug-30 07:02 By: montanaro Comment: accepted and checked in ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101085&group_id=5470 From noreply@sourceforge.net Wed Aug 30 16:24:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 08:24:53 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008301524.IAA13973@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- Date: 2000-Aug-25 05:49 By: fdrake Comment: Performance has *not* been checked -- there's no need to do that until the patch *works*. I understand the performance issue here; Guido and I have turnned this one around a few times and it's just plain hard to get right. One thing to recall is that the current implementation is broken as well; try the test case Jeremy submitted when he filed the bug report. (Keep in mind that I'm calling this patch "NOT READY" still -- I have no intention of checking this in as it stands.) Clearing exceptions in the comparison is clearly a bad thing, but they're getting raised in a chunk of code that simply doesn't allow raising exceptions. This is not well explained in the comments; I'll try to improve them. One issue with the problem is that and exception in the comparison can cause us not to find the entry we're looking for; during C-level exception handling, we're still trying to propogate another exception as well. Even if the general solution proves too slow for use with the module dictionaries (which will require testing to determine), I have some ideas about what it would take to make those fast anyway. I'll describe those later on python-dev. ------------------------------------------------------- Date: 2000-Aug-25 07:12 By: lemburg Comment: Ok. Sorry if that last message sounded a bit like FUD. This needs to be fixed, but I do think that we should get some more feedback and ideas into this... so let's head for python-dev :-) ------------------------------------------------------- Date: 2000-Aug-29 20:49 By: fdrake Comment: Please review and advise regarding the importance of this bug. Not that this patch may have some problems; appearantly Guido was able to get it to break (missing tstate needed by PyErr_*() usage introduced here), but I've not received information needed to duplicate the breakage. ------------------------------------------------------- Date: 2000-Aug-29 21:21 By: tim_one Comment: FYI, Guido told me the patch (or a close relative) made it thru the std test suite, but died running pystone(!). ------------------------------------------------------- Date: 2000-Aug-29 21:42 By: fdrake Comment: Guido told me that as well, but I was not able to reproduce it. He has not provided instructions to duplicate the failure; I just ran pystones.py as a script. ------------------------------------------------------- Date: 2000-Aug-29 21:46 By: tim_one Comment: Actually, I'm relieved to hear that! pystone doesn't do anything strange at all. Guess we'll have to wait for Guido to chime in ... ------------------------------------------------------- Date: 2000-Aug-30 08:24 By: marangoz Comment: Hmm. Instead of plugging complicated logic in lookdict which is likely to slow things down, I'd suggest deferring the exception checks in a helper function, say, compare_equal_noex() which will be called from lookdict on hash collisions (this is relatively rare anyway) and which will wrap the call to PyObject_Compare with fetch/restore. This has the advantage of being able to change the semantics of the return value of PyObject_Compare to something more suitable for lookdict (and/or implement the optimized restore-exception-on-need logic of this patch in the helper function). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Wed Aug 30 19:34:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 11:34:02 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008301834.LAA21137@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- Date: 2000-Aug-25 05:49 By: fdrake Comment: Performance has *not* been checked -- there's no need to do that until the patch *works*. I understand the performance issue here; Guido and I have turnned this one around a few times and it's just plain hard to get right. One thing to recall is that the current implementation is broken as well; try the test case Jeremy submitted when he filed the bug report. (Keep in mind that I'm calling this patch "NOT READY" still -- I have no intention of checking this in as it stands.) Clearing exceptions in the comparison is clearly a bad thing, but they're getting raised in a chunk of code that simply doesn't allow raising exceptions. This is not well explained in the comments; I'll try to improve them. One issue with the problem is that and exception in the comparison can cause us not to find the entry we're looking for; during C-level exception handling, we're still trying to propogate another exception as well. Even if the general solution proves too slow for use with the module dictionaries (which will require testing to determine), I have some ideas about what it would take to make those fast anyway. I'll describe those later on python-dev. ------------------------------------------------------- Date: 2000-Aug-25 07:12 By: lemburg Comment: Ok. Sorry if that last message sounded a bit like FUD. This needs to be fixed, but I do think that we should get some more feedback and ideas into this... so let's head for python-dev :-) ------------------------------------------------------- Date: 2000-Aug-29 20:49 By: fdrake Comment: Please review and advise regarding the importance of this bug. Not that this patch may have some problems; appearantly Guido was able to get it to break (missing tstate needed by PyErr_*() usage introduced here), but I've not received information needed to duplicate the breakage. ------------------------------------------------------- Date: 2000-Aug-29 21:21 By: tim_one Comment: FYI, Guido told me the patch (or a close relative) made it thru the std test suite, but died running pystone(!). ------------------------------------------------------- Date: 2000-Aug-29 21:42 By: fdrake Comment: Guido told me that as well, but I was not able to reproduce it. He has not provided instructions to duplicate the failure; I just ran pystones.py as a script. ------------------------------------------------------- Date: 2000-Aug-29 21:46 By: tim_one Comment: Actually, I'm relieved to hear that! pystone doesn't do anything strange at all. Guess we'll have to wait for Guido to chime in ... ------------------------------------------------------- Date: 2000-Aug-30 08:24 By: marangoz Comment: Hmm. Instead of plugging complicated logic in lookdict which is likely to slow things down, I'd suggest deferring the exception checks in a helper function, say, compare_equal_noex() which will be called from lookdict on hash collisions (this is relatively rare anyway) and which will wrap the call to PyObject_Compare with fetch/restore. This has the advantage of being able to change the semantics of the return value of PyObject_Compare to something more suitable for lookdict (and/or implement the optimized restore-exception-on-need logic of this patch in the helper function). ------------------------------------------------------- Date: 2000-Aug-30 11:34 By: marangoz Comment: Well, things are clearly broken and we all realize that . What needs to be done here is to return a failure from the public API (PyDict_GetItem, _SetItem, etc). For that matter, we need to abort the current table search (lookdict) for any *newly* raised exception. (assuming the dict API is called with no errors in place -- and I'm unclear on whether we can safely assume that...). Which means that whenever an error is detected from PyObject_Compare, we need to fail. Both in lookdict and in insertdict. On failure, lookdict should return a predefined "error_item" which has a NULL value. Subsequently, insertdict should be made to detect this error case and return -1 (on ma_value == NULL and ep == error_item) to signal the failure to SetItem which will in turn return -1. So, among others, insertdict() needs to return an error code (currently it's a void function). And I don't see a way to avoid this if we want to detect a new error incoming from PyObject_Compare(). OTOH, things get complicated because if there's a previous error in place, it seems like we need to propagate the original error (both on failure and on success). It is still unclear, however, what to do if PyDict_SetItem is called with an existing error *and* PyObject_Compare raises an exception. Should we fail by leaving the new exception or fail by propagating the old one? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:14:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:14:13 -0700 Subject: [Patches] [Patch #101086] libcalendar.tex extensions (untested; don't have TeX) Message-ID: <200008301914.MAA22719@delerium.i.sourceforge.net> Patch #101086 has been updated. Project: Category: documentation Status: Open Summary: libcalendar.tex extensions (untested; don't have TeX) Follow-Ups: Date: 2000-Aug-05 18:57 By: goodger Comment: I don't have TeX, and am not fluent, so I hacked the doc code. I haven't tested it and can't guarantee it is without error. I hope it doesn't cause you any trouble. Sorry! ------------------------------------------------------- Date: 2000-Aug-15 12:08 By: tim_one Comment: Assigned to Skip because it appears to be a companion to the calendar.py patch. Skip, if you like the latter patch, I guess this patch should get assigned to Fred next. ------------------------------------------------------- Date: 2000-Aug-17 13:19 By: montanaro Comment: Documentation of function signatures should match definition (e.g., w & l vs width & length) ------------------------------------------------------- Date: 2000-Aug-23 19:21 By: montanaro Comment: sent note to David asking about status of an updated patch ------------------------------------------------------- Date: 2000-Aug-23 21:22 By: goodger Comment: will post an update by the weekend ------------------------------------------------------- Date: 2000-Aug-26 14:20 By: goodger Comment: revised patch: Up to date with calendar.py patch (#101085); all function signatures now match the module code. ------------------------------------------------------- Date: 2000-Aug-30 12:14 By: gvanrossum Comment: For Fred to close after verifying that the docs are okay. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101086&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:16:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:16:59 -0700 Subject: [Patches] [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing Message-ID: <200008301916.MAA22773@delerium.i.sourceforge.net> Patch #101272 has been updated. Project: Category: Modules Status: Open Summary: Allow bsddbmodule.c to compile with libdb 2.x w/o editing Follow-Ups: Date: 2000-Aug-23 19:22 By: montanaro Comment: Eric's been doing lots w/ libdb stuff lately. I'll see if he want's to check this patch out... ;-) ------------------------------------------------------- Date: 2000-Aug-23 20:01 By: fdrake Comment: Update patch to also determine whether the bsddb module should be built at all automatically (adding a stanza to Setup.config.in and a comment to Setup.in). This won't detect all cases automatically, but will catch it on platforms which have it installed as part of the base system (same as for the original patch). ------------------------------------------------------- Date: 2000-Aug-23 20:02 By: fdrake Comment: I'd better note that this still needs testing on a system that only offers BSD db 1.85. ------------------------------------------------------- Date: 2000-Aug-23 20:24 By: montanaro Comment: I'm afraid that's beyond my feeble autoconf/configure skills. libdb.a is hardly installed in a standard location on all systems. The Setup.config.in line would be more involved than @USE_BSDDB_MODULE@bsddb bsddbmodule.c -ldb (though that would work on my Mandrake Linux system). I suspect many people still have to install libdb themselves, so it could wind up just about anywhere. You'd have to teach autoconf to reliably find libdb.a then add a line to Setup.config.in that has the correct -L flag. ------------------------------------------------------- Date: 2000-Aug-23 20:39 By: fdrake Comment: This is sufficient for all cases that the header detection can deal with. We could (& perhaps should) add the necessary test to make sure -ldb works. For BSD db installs that aren't picked up this way, the stanza in Setup.in remains, and can be edited in Setup or provided in Setup.local. ------------------------------------------------------- Date: 2000-Aug-24 08:17 By: montanaro Comment: Okay, this patch goes a bit farther. Here's a quick summary: 1. It adds a line to Modules/Setup.config.in for the bsddb module, prefixed with USE_BSDDB_MODULE. 2. Configure gains a --with-libdb flag. If either --with-libdb is added to the command line or db.h is found, the bsddb module will be enabled. Of course, running configure using --without-libdb will disable it. 3. There's a comment in Setup.in about the new way of enabling the bsddb module, but the old commented out lines are still there. 4. If db_185.h is found, it's included instead of db.h. Both #includes are protected by their relevant HAVE_* defines in Modules/bsddbmodule.c (or should I let the db.h include fail?). 5. No attempt is made to search for libdb.h. It's assumed that if users install it in some odd location they will run configure with the --libdir and/or --includedir flags. Still needs testing on a 1.85/1.86 libdb. ------------------------------------------------------- Date: 2000-Aug-24 18:49 By: montanaro Comment: A new version of the patch to keep pace with other changes to the configure.in file ------------------------------------------------------- Date: 2000-Aug-30 12:16 By: gvanrossum Comment: For Fred to accept or check in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101272&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:19:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:19:42 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008301919.MAA22903@delerium.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Open Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 07:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 08:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 08:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- Date: 2000-Aug-24 08:19 By: montanaro Comment: try "man 1 test". -nt is actually an argument to the test command. Bash's builtin test command does support -nt. ------------------------------------------------------- Date: 2000-Aug-24 08:32 By: twouters Comment: BSDI 'test' does not support -nt. ------------------------------------------------------- Date: 2000-Aug-24 09:51 By: montanaro Comment: In light of Thomas's comment about BSDI's test command, I recommend this patch be postponed until 2.1. It's minor enough. Still, we do need to prod people into comparing Setup.in with preexisting Setup files, otherwise we're going to get a lot of "not-a-bugs" once the software is made widely available. find(1) has a -newer predicate. Is it safe enough to assume it's universally available on systems that can build with Python's Makefile? if [ "`find . -name Setup.in -newer Setup`" = "./Setup.in" ] then echo 'compare Setup and Setup.in for changes!' fi ------------------------------------------------------- Date: 2000-Aug-24 10:03 By: fdrake Comment: Postponed for Python 2.1; assigned to the release manager to re-open after 2.0 is released. The use of find is more difficult; the whole thing must be inside a test that makes sure Setup already exists. Also, the test should be something closer to (untested): [ "`find $(srcdir) -name Setup.in -newer Setup`" = "$(srcdir)/Setup.in" ] ------------------------------------------------------- Date: 2000-Aug-24 14:49 By: twouters Comment: Eep, don't use find. Find has more platform-specific issues than has 'test'! (Don't get me started on BSDI find, please ;) However, I'm getting the feeling this is re-inventing the wheel. 'make' was intended for this kind of thing! And it already does the modified-time check and such: if Setup.in isn't newer than the existing Setup, the body of the rule shouldn't get called. Isn't it enough to test whether there already exists a Setup, and produce a warning if so ? ------------------------------------------------------- Date: 2000-Aug-24 15:15 By: montanaro Comment: doh! I think Thomas is onto something... ------------------------------------------------------- Date: 2000-Aug-24 19:04 By: montanaro Comment: Thomas was correct. I reworked the patch and sent a copy to Fred. I think this patch will ward off a lot of spurious "2.0 won't build" messages in c.l.py and should - for that reason alone - be added to 2.0. People are going to try building 2.0 with 1.5 Setup files. Socket at least won't build without some Setup file tweaks. I'm reopening it and assigning it back to Fred. ------------------------------------------------------- Date: 2000-Aug-30 12:19 By: gvanrossum Comment: Make Setup depend on Setup.in in the Makefile. Then the rule is invoked when Setup.in is newer than Setup as well as when Setup doesn't exist yet. The rule should test whether Setup already exists and in that case issue a warning instead of overwriting Setup. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:21:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:21:22 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008301921.MAA22935@delerium.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Open Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- Date: 2000-Aug-25 05:49 By: fdrake Comment: Performance has *not* been checked -- there's no need to do that until the patch *works*. I understand the performance issue here; Guido and I have turnned this one around a few times and it's just plain hard to get right. One thing to recall is that the current implementation is broken as well; try the test case Jeremy submitted when he filed the bug report. (Keep in mind that I'm calling this patch "NOT READY" still -- I have no intention of checking this in as it stands.) Clearing exceptions in the comparison is clearly a bad thing, but they're getting raised in a chunk of code that simply doesn't allow raising exceptions. This is not well explained in the comments; I'll try to improve them. One issue with the problem is that and exception in the comparison can cause us not to find the entry we're looking for; during C-level exception handling, we're still trying to propogate another exception as well. Even if the general solution proves too slow for use with the module dictionaries (which will require testing to determine), I have some ideas about what it would take to make those fast anyway. I'll describe those later on python-dev. ------------------------------------------------------- Date: 2000-Aug-25 07:12 By: lemburg Comment: Ok. Sorry if that last message sounded a bit like FUD. This needs to be fixed, but I do think that we should get some more feedback and ideas into this... so let's head for python-dev :-) ------------------------------------------------------- Date: 2000-Aug-29 20:49 By: fdrake Comment: Please review and advise regarding the importance of this bug. Not that this patch may have some problems; appearantly Guido was able to get it to break (missing tstate needed by PyErr_*() usage introduced here), but I've not received information needed to duplicate the breakage. ------------------------------------------------------- Date: 2000-Aug-29 21:21 By: tim_one Comment: FYI, Guido told me the patch (or a close relative) made it thru the std test suite, but died running pystone(!). ------------------------------------------------------- Date: 2000-Aug-29 21:42 By: fdrake Comment: Guido told me that as well, but I was not able to reproduce it. He has not provided instructions to duplicate the failure; I just ran pystones.py as a script. ------------------------------------------------------- Date: 2000-Aug-29 21:46 By: tim_one Comment: Actually, I'm relieved to hear that! pystone doesn't do anything strange at all. Guess we'll have to wait for Guido to chime in ... ------------------------------------------------------- Date: 2000-Aug-30 08:24 By: marangoz Comment: Hmm. Instead of plugging complicated logic in lookdict which is likely to slow things down, I'd suggest deferring the exception checks in a helper function, say, compare_equal_noex() which will be called from lookdict on hash collisions (this is relatively rare anyway) and which will wrap the call to PyObject_Compare with fetch/restore. This has the advantage of being able to change the semantics of the return value of PyObject_Compare to something more suitable for lookdict (and/or implement the optimized restore-exception-on-need logic of this patch in the helper function). ------------------------------------------------------- Date: 2000-Aug-30 11:34 By: marangoz Comment: Well, things are clearly broken and we all realize that . What needs to be done here is to return a failure from the public API (PyDict_GetItem, _SetItem, etc). For that matter, we need to abort the current table search (lookdict) for any *newly* raised exception. (assuming the dict API is called with no errors in place -- and I'm unclear on whether we can safely assume that...). Which means that whenever an error is detected from PyObject_Compare, we need to fail. Both in lookdict and in insertdict. On failure, lookdict should return a predefined "error_item" which has a NULL value. Subsequently, insertdict should be made to detect this error case and return -1 (on ma_value == NULL and ep == error_item) to signal the failure to SetItem which will in turn return -1. So, among others, insertdict() needs to return an error code (currently it's a void function). And I don't see a way to avoid this if we want to detect a new error incoming from PyObject_Compare(). OTOH, things get complicated because if there's a previous error in place, it seems like we need to propagate the original error (both on failure and on success). It is still unclear, however, what to do if PyDict_SetItem is called with an existing error *and* PyObject_Compare raises an exception. Should we fail by leaving the new exception or fail by propagating the old one? ------------------------------------------------------- Date: 2000-Aug-30 12:21 By: gvanrossum Comment: For Fred to resolve. We've discussed this at our meeting and we agree on Fred's approach. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:24:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:24:59 -0700 Subject: [Patches] [Patch #101278] Enable --program-suffix option in configure for Cygwin et. a Message-ID: <200008301924.MAA23089@delerium.i.sourceforge.net> Patch #101278 has been updated. Project: Category: Build Status: Open Summary: Enable --program-suffix option in configure for Cygwin et. a Follow-Ups: Date: 2000-Aug-30 12:24 By: gvanrossum Comment: Who's going to test it on Cygwin? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101278&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:27:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:27:05 -0700 Subject: [Patches] [Patch #101298] Enable Py_DEBUG via configure Message-ID: <200008301927.MAA23137@delerium.i.sourceforge.net> Patch #101298 has been updated. Project: Category: Build Status: Accepted Summary: Enable Py_DEBUG via configure Follow-Ups: Date: 2000-Aug-25 06:07 By: montanaro Comment: Assigned to Thomas so he doesn't need to keep editing config.h manually. ;-) ------------------------------------------------------- Date: 2000-Aug-25 14:38 By: twouters Comment: Looks fine to me, though I would expand the 'help' message for this option a bit. State that it is for 'extensive debugging of the Python interpreter' or some such. And as far as I'm concerned, it's accepted. Oh, wait, not quite accepted: don't edit config.h.in manually. Edit acconfig.h to add a specific comment to a #define (just add the #define and the comment to that file) and then 'autoheader' will create config.h.in just like 'autoconf' creates configure from configure.in. (If the define is not present in acconfig.h, but is set in configure.in, a generic comment is used instead.) ------------------------------------------------------- Date: 2000-Aug-25 15:35 By: montanaro Comment: I've never used autoheader before. Simpleminded usage: autoheader acconfig.h > config.h.in fails with % autoheader acconfig.h error: AC_CONFIG_HEADER not found in acconfig.h  Trying it with no args yields % autoheader /usr/bin/autoheader: Symbol `WITH_LIBDB' is not covered\ by /usr/share/autoconf/acconfig.h ./acconfig.h Of course, there is no autoheader man page or info file on my system. What's the magic incantation? ------------------------------------------------------- Date: 2000-Aug-26 04:00 By: twouters Comment: You don't need to redirect the output of 'autoheader' (or 'autoconf' for that matter!) but you *are* apparently missing something important from acconfig.h. This is probably related to the other patches you have lying around :) If you *do* pass an argument to autoheader, the argument should be the configure.in file, not the acconfig.h file. The config.h.in file is generated from configure.in (by looking at what defines it sets) with help from acconfig.h. My earlier statement that 'a generic comment will be used if a #define is missing from acconfig.h' was probably a bit misleading, though: it's not that simple. Autoheader uses *two* acconfig.h files: a system-wide one, and the local one. The system-wide one contains the #defines & comments for the most common checks, but if you set one in configure.in which isn't in the global acconfig.h yet, you have to add it to the local acconfig.h yourself. In addition to the two acconfig.h files, autoheader also tries to figure out what #defines you set and auto-generates comments for those: the defines set by AC_CHECK_LIB(S), AC_CHECK_HEADERS, etc, are added automatically, unless they already exist in acconfig.h (in which case, the comment in acconfig.h is used instead of the generated one.) The error you get, about WITH_LIBDB, probably means you need to add WITH_LIBDB to acconfig.h. Oh, and no, there isn't a manpage for autoheader and autoconf, because it's GNU, and documentation on GNU software is primarily 'info'. You have to be lucky to get manpages :-S And 'info autoheader' won't work, because it's a command and not a package: you need to use 'info autoconf', and then look for autoheader (using 's'). That said, do you want me to grab your patch, fix it up and commit it, or do you want to give it a shot yourself ? ------------------------------------------------------- Date: 2000-Aug-26 10:22 By: montanaro Comment: Here's an updated version that includes acconfig.h. config.h.in was generated by autoheader. You should be able to apply this patch but will probably get some offset warnings from patch because I snipped out a couple other changes. Diffs for configure aren't included here. I will generate a proper configure file when checking this in. ------------------------------------------------------- Date: 2000-Aug-26 10:23 By: montanaro Comment: oh bother ... I forgot C-x C-s after trimming the patch... ------------------------------------------------------- Date: 2000-Aug-29 09:31 By: marangoz Comment: +1; looks good and works as expected on Linux. Side note: you needn't to include config.h.in in the patch -- this file is generated by autoheader from acconfig.h ------------------------------------------------------- Date: 2000-Aug-30 12:27 By: gvanrossum Comment: OK, check it in. Please also check in the generated file! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101298&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:27:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:27:26 -0700 Subject: [Patches] [Patch #101309] Specialization of dictionaries for strings. Message-ID: <200008301927.MAA23149@delerium.i.sourceforge.net> Patch #101309 has been updated. Project: Category: core (C code) Status: Postponed Summary: Specialization of dictionaries for strings. Follow-Ups: Date: 2000-Aug-25 22:26 By: fdrake Comment: This patch introduces some changes to the builtin dictionary type. These changes create a specialization of the type to better support efficient use of dictionaries as a runtime implementation detail. This patch causes all newly created dictionaries to be specialized for string keys; dictionaries are converted (trivially) to handle arbitrary keys as needed. If a non-string is used as a key (even if only doing a lookup and it fails), the dictionary is converted to a normal dictionary. To achieve faster performance, a specialized version of the lookdict() function is used. The specialized implementation can assume two things that the "normal" implementation cannot: - that all comparisons are always done using the PyString_Type.tp_compare function, avoiding some of the overhead of calling PyObject_Compare() and dereferencing the comparison function repeatedly, and - that the comparison function never raises an exception, since two strings can always be compared without an error. Some debugging code added to dictobject.c shows that most dictionaries created during the regression test are never converted to "normal" dictionaries, but always only use strings as keys: created 115874 string dicts converted 2658 to normal dicts 2.29% conversion rate Additional performance tests should be made. I expect that a patch such as this is most valuable if additional code is needed to robustify lookdict() to properly deal with exceptions from user-defined comparison functions (tp_compare handlers of __cmp__() functions in Python code). The patch duplicates the logic of the lookdict() function, which makes maintenance more tedious. ------------------------------------------------------- Date: 2000-Aug-30 12:27 By: marangoz Comment: I doubt we'll gain something from this, if anything at all. Some more stats: for pystone: 1052981 total dict lookups, of which 2182 (0.21%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons for the regression test suite: 7266955 total dict lookups, of which 580978 (7.99%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons Postponed for further investigation. There's an idea in the lazy, runtime specialization of the lookup algorithm! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:30:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:30:55 -0700 Subject: [Patches] [Patch #101309] Specialization of dictionaries for strings. Message-ID: <200008301930.MAA23314@delerium.i.sourceforge.net> Patch #101309 has been updated. Project: Category: core (C code) Status: Postponed Summary: Specialization of dictionaries for strings. Follow-Ups: Date: 2000-Aug-25 22:26 By: fdrake Comment: This patch introduces some changes to the builtin dictionary type. These changes create a specialization of the type to better support efficient use of dictionaries as a runtime implementation detail. This patch causes all newly created dictionaries to be specialized for string keys; dictionaries are converted (trivially) to handle arbitrary keys as needed. If a non-string is used as a key (even if only doing a lookup and it fails), the dictionary is converted to a normal dictionary. To achieve faster performance, a specialized version of the lookdict() function is used. The specialized implementation can assume two things that the "normal" implementation cannot: - that all comparisons are always done using the PyString_Type.tp_compare function, avoiding some of the overhead of calling PyObject_Compare() and dereferencing the comparison function repeatedly, and - that the comparison function never raises an exception, since two strings can always be compared without an error. Some debugging code added to dictobject.c shows that most dictionaries created during the regression test are never converted to "normal" dictionaries, but always only use strings as keys: created 115874 string dicts converted 2658 to normal dicts 2.29% conversion rate Additional performance tests should be made. I expect that a patch such as this is most valuable if additional code is needed to robustify lookdict() to properly deal with exceptions from user-defined comparison functions (tp_compare handlers of __cmp__() functions in Python code). The patch duplicates the logic of the lookdict() function, which makes maintenance more tedious. ------------------------------------------------------- Date: 2000-Aug-30 12:27 By: marangoz Comment: I doubt we'll gain something from this, if anything at all. Some more stats: for pystone: 1052981 total dict lookups, of which 2182 (0.21%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons for the regression test suite: 7266955 total dict lookups, of which 580978 (7.99%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons Postponed for further investigation. There's an idea in the lazy, runtime specialization of the lookup algorithm! ------------------------------------------------------- Date: 2000-Aug-30 12:30 By: gvanrossum Comment: Guido needs to decide whether this is needed to make the other dict patch safe when tstate==NULL. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:33:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:33:52 -0700 Subject: [Patches] [Patch #101309] Specialization of dictionaries for strings. Message-ID: <200008301933.MAA23444@delerium.i.sourceforge.net> Patch #101309 has been updated. Project: Category: core (C code) Status: Open Summary: Specialization of dictionaries for strings. Follow-Ups: Date: 2000-Aug-25 22:26 By: fdrake Comment: This patch introduces some changes to the builtin dictionary type. These changes create a specialization of the type to better support efficient use of dictionaries as a runtime implementation detail. This patch causes all newly created dictionaries to be specialized for string keys; dictionaries are converted (trivially) to handle arbitrary keys as needed. If a non-string is used as a key (even if only doing a lookup and it fails), the dictionary is converted to a normal dictionary. To achieve faster performance, a specialized version of the lookdict() function is used. The specialized implementation can assume two things that the "normal" implementation cannot: - that all comparisons are always done using the PyString_Type.tp_compare function, avoiding some of the overhead of calling PyObject_Compare() and dereferencing the comparison function repeatedly, and - that the comparison function never raises an exception, since two strings can always be compared without an error. Some debugging code added to dictobject.c shows that most dictionaries created during the regression test are never converted to "normal" dictionaries, but always only use strings as keys: created 115874 string dicts converted 2658 to normal dicts 2.29% conversion rate Additional performance tests should be made. I expect that a patch such as this is most valuable if additional code is needed to robustify lookdict() to properly deal with exceptions from user-defined comparison functions (tp_compare handlers of __cmp__() functions in Python code). The patch duplicates the logic of the lookdict() function, which makes maintenance more tedious. ------------------------------------------------------- Date: 2000-Aug-30 12:27 By: marangoz Comment: I doubt we'll gain something from this, if anything at all. Some more stats: for pystone: 1052981 total dict lookups, of which 2182 (0.21%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons for the regression test suite: 7266955 total dict lookups, of which 580978 (7.99%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons Postponed for further investigation. There's an idea in the lazy, runtime specialization of the lookup algorithm! ------------------------------------------------------- Date: 2000-Aug-30 12:30 By: gvanrossum Comment: Guido needs to decide whether this is needed to make the other dict patch safe when tstate==NULL. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:38:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:38:47 -0700 Subject: [Patches] [Patch #101320] Translate doc strings Message-ID: <200008301938.MAA23604@delerium.i.sourceforge.net> Patch #101320 has been updated. Project: Category: Build Status: Open Summary: Translate doc strings Follow-Ups: Date: 2000-Aug-28 00:46 By: tim_one Comment: Assigned to Barry since it seems related to gettext. ------------------------------------------------------- Date: 2000-Aug-30 12:38 By: gvanrossum Comment: Barry will comment on this and then postpone it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101320&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:44:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:44:08 -0700 Subject: [Patches] [Patch #101342] remove -Wstrict-prototypes warnings [aka: Anal Crusade I] Message-ID: <200008301944.MAA23820@delerium.i.sourceforge.net> Patch #101342 has been updated. Project: Category: core (C code) Status: Open Summary: remove -Wstrict-prototypes warnings [aka: Anal Crusade I] Follow-Ups: Date: 2000-Aug-29 04:59 By: nowonder Comment: there is one remaining warning in Modules/main.c. The comment says that getopt() has no standardized prototype. The one given (int, char **, char *) does not work on Linux, but (int, char *const *, const char *) does. Is it worth doing some autoconf magic, or should we just let the warning stick where it is? ------------------------------------------------------- Date: 2000-Aug-29 08:58 By: nowonder Comment: Thomas proposed that I should "move the 'getopt' prototype into pyport.h and comment it out, re-adding it only for those platforms that don't have a getopt prototype." ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101342&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:45:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:45:34 -0700 Subject: [Patches] [Patch #101345] Remove obsolete --with(out)-readline option Message-ID: <200008301945.MAA23846@delerium.i.sourceforge.net> Patch #101345 has been updated. Project: Category: Build Status: Accepted Summary: Remove obsolete --with(out)-readline option Follow-Ups: Date: 2000-Aug-29 09:40 By: marangoz Comment: I believe that it's time for this option to go away. It makes no sense for 2.0 to keep it alive and issue an error, if given, saying that the option is obsolete. ------------------------------------------------------- Date: 2000-Aug-30 12:45 By: gvanrossum Comment: Cool. Go ahead. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101345&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:46:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:46:27 -0700 Subject: [Patches] [Patch #101309] Specialization of dictionaries for strings. Message-ID: <200008301946.MAA29407@bush.i.sourceforge.net> Patch #101309 has been updated. Project: Category: core (C code) Status: Open Summary: Specialization of dictionaries for strings. Follow-Ups: Date: 2000-Aug-25 22:26 By: fdrake Comment: This patch introduces some changes to the builtin dictionary type. These changes create a specialization of the type to better support efficient use of dictionaries as a runtime implementation detail. This patch causes all newly created dictionaries to be specialized for string keys; dictionaries are converted (trivially) to handle arbitrary keys as needed. If a non-string is used as a key (even if only doing a lookup and it fails), the dictionary is converted to a normal dictionary. To achieve faster performance, a specialized version of the lookdict() function is used. The specialized implementation can assume two things that the "normal" implementation cannot: - that all comparisons are always done using the PyString_Type.tp_compare function, avoiding some of the overhead of calling PyObject_Compare() and dereferencing the comparison function repeatedly, and - that the comparison function never raises an exception, since two strings can always be compared without an error. Some debugging code added to dictobject.c shows that most dictionaries created during the regression test are never converted to "normal" dictionaries, but always only use strings as keys: created 115874 string dicts converted 2658 to normal dicts 2.29% conversion rate Additional performance tests should be made. I expect that a patch such as this is most valuable if additional code is needed to robustify lookdict() to properly deal with exceptions from user-defined comparison functions (tp_compare handlers of __cmp__() functions in Python code). The patch duplicates the logic of the lookdict() function, which makes maintenance more tedious. ------------------------------------------------------- Date: 2000-Aug-30 12:27 By: marangoz Comment: I doubt we'll gain something from this, if anything at all. Some more stats: for pystone: 1052981 total dict lookups, of which 2182 (0.21%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons for the regression test suite: 7266955 total dict lookups, of which 580978 (7.99%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons Postponed for further investigation. There's an idea in the lazy, runtime specialization of the lookup algorithm! ------------------------------------------------------- Date: 2000-Aug-30 12:30 By: gvanrossum Comment: Guido needs to decide whether this is needed to make the other dict patch safe when tstate==NULL. ------------------------------------------------------- Date: 2000-Aug-30 12:46 By: marangoz Comment: Looks like the other dict patch needs to use PyErr_xxx calls inside/after PyThreadState_GET() != NULL checks. if tstate==NULL, the PyErr logic must be skipped (this is an orphan state or a temporary state on early initialization & late finalization -- need to dbl check this once again). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:48:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:48:44 -0700 Subject: [Patches] [Patch #101346] fetch/restore exceptions around GC collections Message-ID: <200008301948.MAA23895@delerium.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Open Summary: fetch/restore exceptions around GC collections Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- Date: 2000-Aug-29 13:34 By: jhylton Comment: Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations. Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception. It seems dangerous to ignore one completely, but it's not clear how to recover. If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c ------------------------------------------------------- Date: 2000-Aug-30 06:40 By: marangoz Comment: Hm. The offending PyErr_Clear should definitely be removed. Not sure that surrounding the collection process with err fetch/restore is a good idea though. The collector could trigger __del__ methods which in turn could set exceptions. The GC code itself should be absolutely transparent w.r.t. exceptions and should propagate them if they're raised elsewhere. So, what needs to be done here is: - remove PyErrClear - use PySys_WriteStderr for debugging. The whole "output" stuff in gcmodule.c should be zapped, because it's a suboptimal and incomplete PySys_WriteStderr. The latter takes care to fetch/restore exceptions when printing the output. PS: now that this is assigned to me, can I upload another patch over this one for review? ------------------------------------------------------- Date: 2000-Aug-30 12:48 By: gvanrossum Comment: We agree with Vladimir. You can't upload a new version to this patch, but you can submit it as a new patch. We still want to check for spurious exceptions in the GC code and turn them into fatal errors, because they shouldn't happen and we want to make sure they don't. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:52:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:52:31 -0700 Subject: [Patches] [Patch #101352] PyOS_StackCheck for Unix Message-ID: <200008301952.MAA24074@delerium.i.sourceforge.net> Patch #101352 has been updated. Project: Category: core (C code) Status: Open Summary: PyOS_StackCheck for Unix Follow-Ups: Date: 2000-Aug-30 02:15 By: lemburg Comment: Since getrlimit() might not return useful results on all Unix platforms, I'd suggest adding a test to the configure script (the test should check whether getrlimit() returns a non-zero value for the stack limit). Also, due to the added call overhead, I'd suggest raising the modulo value in ceval's hook to call PyOS_CheckStack(): #ifdef USE_STACKCHECK if (tstate->recursion_depth%10 == 0 && PyOS_CheckStack()) { PyErr_SetString(PyExc_MemoryError, "Stack overflow"); return NULL; } #endif to about 100. That way the stack check will most likely only be triggered by programs which actually use recursion, rather than those which only use shallow function call nesting (10 seems to low w/r to these). ------------------------------------------------------- Date: 2000-Aug-30 05:31 By: loewis Comment: IMO, testing could be deferred until some system shows up that indeed returns zero. As for the frequency of the OS call, it may be useful to cache the result of getrlimit, on a per-thread basis. That won't catch changes done by the script itself, or from the outside, but if people do such things, they need to be careful, anyway. ------------------------------------------------------- Date: 2000-Aug-30 12:52 By: gvanrossum Comment: Given to Jeremy. We don't think we can get PyOS_CheckStack to work reliably and efficiently on Unix. Instead, we're going to make the recursion limit a user settable thing (sys.{set,get}recursionlimit) with a small default, e.g. 1000. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101352&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:55:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:55:21 -0700 Subject: [Patches] [Patch #101350] Fix SMTPlib for large messages Message-ID: <200008301955.MAA24212@delerium.i.sourceforge.net> Patch #101350 has been updated. Project: Category: library Status: Accepted Summary: Fix SMTPlib for large messages ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101350&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:56:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:56:19 -0700 Subject: [Patches] [Patch #101354] New files: plat-freebsd{4,5}/* Message-ID: <200008301956.MAA24245@delerium.i.sourceforge.net> Patch #101354 has been updated. Project: Category: library Status: Accepted Summary: New files: plat-freebsd{4,5}/* ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101354&group_id=5470 From noreply@sourceforge.net Wed Aug 30 21:01:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 13:01:18 -0700 Subject: [Patches] [Patch #100955] ptags, eptags: regex->re, 4 char indent. Message-ID: <200008302001.NAA24427@delerium.i.sourceforge.net> Patch #100955 has been updated. Project: Category: None Status: Accepted Summary: ptags, eptags: regex->re, 4 char indent. Follow-Ups: Date: 2000-Jul-22 01:35 By: hooft Comment: This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex. ------------------------------------------------------- Date: 2000-Jul-22 23:44 By: moshez Comment: I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this? ------------------------------------------------------- Date: 2000-Jul-25 13:57 By: gvanrossum Comment: SRE should be faster again, right? The parser module is a very big gun for this simple app -- look at it as an example for text processing (and documentation for TAGS files :-). I say go for it. ------------------------------------------------------- Date: 2000-Jul-26 07:12 By: moshez Comment: Somehow it passed through me, so I added ptags change too. Anyway, Jeremy, Guido is for this. ------------------------------------------------------- Date: 2000-Aug-15 11:12 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-15 11:13 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-15 11:13 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-21 18:51 By: tim_one Comment: Barry, please follow up on this, or assign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470 From noreply@sourceforge.net Wed Aug 30 22:02:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 14:02:48 -0700 Subject: [Patches] [Patch #101362] fix GC debugging output w.r.t. exceptions Message-ID: <200008302102.OAA26689@delerium.i.sourceforge.net> Patch #101362 has been updated. Project: Category: core (C code) Status: Open Summary: fix GC debugging output w.r.t. exceptions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101362&group_id=5470 From noreply@sourceforge.net Wed Aug 30 22:12:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 14:12:52 -0700 Subject: [Patches] [Patch #101362] fix GC debugging output w.r.t. exceptions Message-ID: <200008302112.OAA27101@delerium.i.sourceforge.net> Patch #101362 has been updated. Project: Category: core (C code) Status: Open Summary: fix GC debugging output w.r.t. exceptions Follow-Ups: Date: 2000-Aug-30 14:12 By: marangoz Comment: Related to SF patch 101346. Use PySys_WriteStderr for debugging output to avoid interference with exception handling. Remove offending PyErr_Clear. If not initialized, output debugging messages through fprintf(stderr, ...) -- otherwise we can start finalization with remaining gc.debug flags which may screw up PySys_WriteStderr. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101362&group_id=5470 From noreply@sourceforge.net Wed Aug 30 23:02:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 15:02:08 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008302202.PAA28899@delerium.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Open Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 07:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 08:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 08:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- Date: 2000-Aug-24 08:19 By: montanaro Comment: try "man 1 test". -nt is actually an argument to the test command. Bash's builtin test command does support -nt. ------------------------------------------------------- Date: 2000-Aug-24 08:32 By: twouters Comment: BSDI 'test' does not support -nt. ------------------------------------------------------- Date: 2000-Aug-24 09:51 By: montanaro Comment: In light of Thomas's comment about BSDI's test command, I recommend this patch be postponed until 2.1. It's minor enough. Still, we do need to prod people into comparing Setup.in with preexisting Setup files, otherwise we're going to get a lot of "not-a-bugs" once the software is made widely available. find(1) has a -newer predicate. Is it safe enough to assume it's universally available on systems that can build with Python's Makefile? if [ "`find . -name Setup.in -newer Setup`" = "./Setup.in" ] then echo 'compare Setup and Setup.in for changes!' fi ------------------------------------------------------- Date: 2000-Aug-24 10:03 By: fdrake Comment: Postponed for Python 2.1; assigned to the release manager to re-open after 2.0 is released. The use of find is more difficult; the whole thing must be inside a test that makes sure Setup already exists. Also, the test should be something closer to (untested): [ "`find $(srcdir) -name Setup.in -newer Setup`" = "$(srcdir)/Setup.in" ] ------------------------------------------------------- Date: 2000-Aug-24 14:49 By: twouters Comment: Eep, don't use find. Find has more platform-specific issues than has 'test'! (Don't get me started on BSDI find, please ;) However, I'm getting the feeling this is re-inventing the wheel. 'make' was intended for this kind of thing! And it already does the modified-time check and such: if Setup.in isn't newer than the existing Setup, the body of the rule shouldn't get called. Isn't it enough to test whether there already exists a Setup, and produce a warning if so ? ------------------------------------------------------- Date: 2000-Aug-24 15:15 By: montanaro Comment: doh! I think Thomas is onto something... ------------------------------------------------------- Date: 2000-Aug-24 19:04 By: montanaro Comment: Thomas was correct. I reworked the patch and sent a copy to Fred. I think this patch will ward off a lot of spurious "2.0 won't build" messages in c.l.py and should - for that reason alone - be added to 2.0. People are going to try building 2.0 with 1.5 Setup files. Socket at least won't build without some Setup file tweaks. I'm reopening it and assigning it back to Fred. ------------------------------------------------------- Date: 2000-Aug-30 12:19 By: gvanrossum Comment: Make Setup depend on Setup.in in the Makefile. Then the rule is invoked when Setup.in is newer than Setup as well as when Setup doesn't exist yet. The rule should test whether Setup already exists and in that case issue a warning instead of overwriting Setup. ------------------------------------------------------- Date: 2000-Aug-30 15:02 By: montanaro Comment: yup - that's what the latest patch does. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Wed Aug 30 23:31:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 15:31:37 -0700 Subject: [Patches] [Patch #101298] Enable Py_DEBUG via configure Message-ID: <200008302231.PAA03183@bush.i.sourceforge.net> Patch #101298 has been updated. Project: Category: Build Status: Closed Summary: Enable Py_DEBUG via configure Follow-Ups: Date: 2000-Aug-25 06:07 By: montanaro Comment: Assigned to Thomas so he doesn't need to keep editing config.h manually. ;-) ------------------------------------------------------- Date: 2000-Aug-25 14:38 By: twouters Comment: Looks fine to me, though I would expand the 'help' message for this option a bit. State that it is for 'extensive debugging of the Python interpreter' or some such. And as far as I'm concerned, it's accepted. Oh, wait, not quite accepted: don't edit config.h.in manually. Edit acconfig.h to add a specific comment to a #define (just add the #define and the comment to that file) and then 'autoheader' will create config.h.in just like 'autoconf' creates configure from configure.in. (If the define is not present in acconfig.h, but is set in configure.in, a generic comment is used instead.) ------------------------------------------------------- Date: 2000-Aug-25 15:35 By: montanaro Comment: I've never used autoheader before. Simpleminded usage: autoheader acconfig.h > config.h.in fails with % autoheader acconfig.h error: AC_CONFIG_HEADER not found in acconfig.h  Trying it with no args yields % autoheader /usr/bin/autoheader: Symbol `WITH_LIBDB' is not covered\ by /usr/share/autoconf/acconfig.h ./acconfig.h Of course, there is no autoheader man page or info file on my system. What's the magic incantation? ------------------------------------------------------- Date: 2000-Aug-26 04:00 By: twouters Comment: You don't need to redirect the output of 'autoheader' (or 'autoconf' for that matter!) but you *are* apparently missing something important from acconfig.h. This is probably related to the other patches you have lying around :) If you *do* pass an argument to autoheader, the argument should be the configure.in file, not the acconfig.h file. The config.h.in file is generated from configure.in (by looking at what defines it sets) with help from acconfig.h. My earlier statement that 'a generic comment will be used if a #define is missing from acconfig.h' was probably a bit misleading, though: it's not that simple. Autoheader uses *two* acconfig.h files: a system-wide one, and the local one. The system-wide one contains the #defines & comments for the most common checks, but if you set one in configure.in which isn't in the global acconfig.h yet, you have to add it to the local acconfig.h yourself. In addition to the two acconfig.h files, autoheader also tries to figure out what #defines you set and auto-generates comments for those: the defines set by AC_CHECK_LIB(S), AC_CHECK_HEADERS, etc, are added automatically, unless they already exist in acconfig.h (in which case, the comment in acconfig.h is used instead of the generated one.) The error you get, about WITH_LIBDB, probably means you need to add WITH_LIBDB to acconfig.h. Oh, and no, there isn't a manpage for autoheader and autoconf, because it's GNU, and documentation on GNU software is primarily 'info'. You have to be lucky to get manpages :-S And 'info autoheader' won't work, because it's a command and not a package: you need to use 'info autoconf', and then look for autoheader (using 's'). That said, do you want me to grab your patch, fix it up and commit it, or do you want to give it a shot yourself ? ------------------------------------------------------- Date: 2000-Aug-26 10:22 By: montanaro Comment: Here's an updated version that includes acconfig.h. config.h.in was generated by autoheader. You should be able to apply this patch but will probably get some offset warnings from patch because I snipped out a couple other changes. Diffs for configure aren't included here. I will generate a proper configure file when checking this in. ------------------------------------------------------- Date: 2000-Aug-26 10:23 By: montanaro Comment: oh bother ... I forgot C-x C-s after trimming the patch... ------------------------------------------------------- Date: 2000-Aug-29 09:31 By: marangoz Comment: +1; looks good and works as expected on Linux. Side note: you needn't to include config.h.in in the patch -- this file is generated by autoheader from acconfig.h ------------------------------------------------------- Date: 2000-Aug-30 12:27 By: gvanrossum Comment: OK, check it in. Please also check in the generated file! ------------------------------------------------------- Date: 2000-Aug-30 15:31 By: montanaro Comment: two source files (acconfig.h and configure.in) were affected as well as two generated files (config.h.in and configure). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101298&group_id=5470 From noreply@sourceforge.net Thu Aug 31 02:33:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 18:33:48 -0700 Subject: [Patches] [Patch #101352] PyOS_StackCheck for Unix Message-ID: <200008310133.SAA03687@delerium.i.sourceforge.net> Patch #101352 has been updated. Project: Category: core (C code) Status: Postponed Summary: PyOS_StackCheck for Unix Follow-Ups: Date: 2000-Aug-30 02:15 By: lemburg Comment: Since getrlimit() might not return useful results on all Unix platforms, I'd suggest adding a test to the configure script (the test should check whether getrlimit() returns a non-zero value for the stack limit). Also, due to the added call overhead, I'd suggest raising the modulo value in ceval's hook to call PyOS_CheckStack(): #ifdef USE_STACKCHECK if (tstate->recursion_depth%10 == 0 && PyOS_CheckStack()) { PyErr_SetString(PyExc_MemoryError, "Stack overflow"); return NULL; } #endif to about 100. That way the stack check will most likely only be triggered by programs which actually use recursion, rather than those which only use shallow function call nesting (10 seems to low w/r to these). ------------------------------------------------------- Date: 2000-Aug-30 05:31 By: loewis Comment: IMO, testing could be deferred until some system shows up that indeed returns zero. As for the frequency of the OS call, it may be useful to cache the result of getrlimit, on a per-thread basis. That won't catch changes done by the script itself, or from the outside, but if people do such things, they need to be careful, anyway. ------------------------------------------------------- Date: 2000-Aug-30 12:52 By: gvanrossum Comment: Given to Jeremy. We don't think we can get PyOS_CheckStack to work reliably and efficiently on Unix. Instead, we're going to make the recursion limit a user settable thing (sys.{set,get}recursionlimit) with a small default, e.g. 1000. ------------------------------------------------------- Date: 2000-Aug-30 18:33 By: jhylton Comment: Postponed, because it is sufficiently complex to fall subject to the feature freeze for 2.0b1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101352&group_id=5470 From noreply@sourceforge.net Thu Aug 31 03:28:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 19:28:29 -0700 Subject: [Patches] [Patch #101362] fix GC debugging output w.r.t. exceptions Message-ID: <200008310228.TAA05515@delerium.i.sourceforge.net> Patch #101362 has been updated. Project: Category: core (C code) Status: Open Summary: fix GC debugging output w.r.t. exceptions Follow-Ups: Date: 2000-Aug-30 14:12 By: marangoz Comment: Related to SF patch 101346. Use PySys_WriteStderr for debugging output to avoid interference with exception handling. Remove offending PyErr_Clear. If not initialized, output debugging messages through fprintf(stderr, ...) -- otherwise we can start finalization with remaining gc.debug flags which may screw up PySys_WriteStderr. ------------------------------------------------------- Date: 2000-Aug-30 19:28 By: jhylton Comment: Two issues; one simple. I don't understand why the Py_IsInitialized call is necessary. Can you add a brief comment that explains it? We discussed various patch options at a meeting today. One of our goals was to eliminate all the sprintf calls in gcmodule.c, since PySys_WriteStderr has a printf-like interface. Can you modify the local write_stderr so that it has the same interface? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101362&group_id=5470 From noreply@sourceforge.net Thu Aug 31 03:42:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 19:42:22 -0700 Subject: [Patches] [Patch #101354] New files: plat-freebsd{4,5}/* Message-ID: <200008310242.TAA05997@delerium.i.sourceforge.net> Patch #101354 has been updated. Project: Category: library Status: Closed Summary: New files: plat-freebsd{4,5}/* ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101354&group_id=5470 From noreply@sourceforge.net Thu Aug 31 06:19:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 22:19:35 -0700 Subject: [Patches] [Patch #101342] remove -Wstrict-prototypes warnings [aka: Anal Crusade I] Message-ID: <200008310519.WAA16427@bush.i.sourceforge.net> Patch #101342 has been updated. Project: Category: core (C code) Status: Closed Summary: remove -Wstrict-prototypes warnings [aka: Anal Crusade I] Follow-Ups: Date: 2000-Aug-29 04:59 By: nowonder Comment: there is one remaining warning in Modules/main.c. The comment says that getopt() has no standardized prototype. The one given (int, char **, char *) does not work on Linux, but (int, char *const *, const char *) does. Is it worth doing some autoconf magic, or should we just let the warning stick where it is? ------------------------------------------------------- Date: 2000-Aug-29 08:58 By: nowonder Comment: Thomas proposed that I should "move the 'getopt' prototype into pyport.h and comment it out, re-adding it only for those platforms that don't have a getopt prototype." ------------------------------------------------------- Date: 2000-Aug-30 22:19 By: fdrake Comment: Checked in. Please submit a separate patch for the getopt() prototype in Modules/main.c -- thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101342&group_id=5470 From noreply@sourceforge.net Thu Aug 31 06:28:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 22:28:52 -0700 Subject: [Patches] [Patch #101309] Specialization of dictionaries for strings. Message-ID: <200008310528.WAA16788@bush.i.sourceforge.net> Patch #101309 has been updated. Project: Category: core (C code) Status: Open Summary: Specialization of dictionaries for strings. Follow-Ups: Date: 2000-Aug-25 22:26 By: fdrake Comment: This patch introduces some changes to the builtin dictionary type. These changes create a specialization of the type to better support efficient use of dictionaries as a runtime implementation detail. This patch causes all newly created dictionaries to be specialized for string keys; dictionaries are converted (trivially) to handle arbitrary keys as needed. If a non-string is used as a key (even if only doing a lookup and it fails), the dictionary is converted to a normal dictionary. To achieve faster performance, a specialized version of the lookdict() function is used. The specialized implementation can assume two things that the "normal" implementation cannot: - that all comparisons are always done using the PyString_Type.tp_compare function, avoiding some of the overhead of calling PyObject_Compare() and dereferencing the comparison function repeatedly, and - that the comparison function never raises an exception, since two strings can always be compared without an error. Some debugging code added to dictobject.c shows that most dictionaries created during the regression test are never converted to "normal" dictionaries, but always only use strings as keys: created 115874 string dicts converted 2658 to normal dicts 2.29% conversion rate Additional performance tests should be made. I expect that a patch such as this is most valuable if additional code is needed to robustify lookdict() to properly deal with exceptions from user-defined comparison functions (tp_compare handlers of __cmp__() functions in Python code). The patch duplicates the logic of the lookdict() function, which makes maintenance more tedious. ------------------------------------------------------- Date: 2000-Aug-30 12:27 By: marangoz Comment: I doubt we'll gain something from this, if anything at all. Some more stats: for pystone: 1052981 total dict lookups, of which 2182 (0.21%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons for the regression test suite: 7266955 total dict lookups, of which 580978 (7.99%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons Postponed for further investigation. There's an idea in the lazy, runtime specialization of the lookup algorithm! ------------------------------------------------------- Date: 2000-Aug-30 12:30 By: gvanrossum Comment: Guido needs to decide whether this is needed to make the other dict patch safe when tstate==NULL. ------------------------------------------------------- Date: 2000-Aug-30 12:46 By: marangoz Comment: Looks like the other dict patch needs to use PyErr_xxx calls inside/after PyThreadState_GET() != NULL checks. if tstate==NULL, the PyErr logic must be skipped (this is an orphan state or a temporary state on early initialization & late finalization -- need to dbl check this once again). ------------------------------------------------------- Date: 2000-Aug-30 22:28 By: fdrake Comment: Changed this a little: - counting code that determines how often dictionaries are "degraded" is conditionalized and not included by default. - Instead of calling PyObject_Compare() in lookdict_string(), directly call the string type's tp_compare handler. This saves the various tests done in PyObject_Compare(), as well as the creation of a few C call frames. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 From noreply@sourceforge.net Thu Aug 31 08:51:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 00:51:06 -0700 Subject: [Patches] [Patch #101369] Solves bug 111961 Message-ID: <200008310751.AAA16060@delerium.i.sourceforge.net> Patch #101369 has been updated. Project: Category: Modules Status: Open Summary: Solves bug 111961 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101369&group_id=5470 From noreply@sourceforge.net Thu Aug 31 08:52:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 00:52:08 -0700 Subject: [Patches] [Patch #101369] Solves bug 111961 Message-ID: <200008310752.AAA16065@delerium.i.sourceforge.net> Patch #101369 has been updated. Project: Category: Modules Status: Open Summary: Solves bug 111961 Follow-Ups: Date: 2000-Aug-31 00:52 By: fdrake Comment: Moshe requested that I post this patch and assign it to Jeremy; his net connection is flaky at the moment. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101369&group_id=5470 From noreply@sourceforge.net Thu Aug 31 11:40:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 03:40:34 -0700 Subject: [Patches] [Patch #101373] configure.in: missing brackets Message-ID: <200008311040.DAA27304@bush.i.sourceforge.net> Patch #101373 has been updated. Project: Category: Build Status: Open Summary: configure.in: missing brackets ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101373&group_id=5470 From noreply@sourceforge.net Thu Aug 31 12:03:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 04:03:05 -0700 Subject: [Patches] [Patch #101374] linuxaudiodev.c: add support for FreeBSD Message-ID: <200008311103.EAA22311@delerium.i.sourceforge.net> Patch #101374 has been updated. Project: Category: Modules Status: Open Summary: linuxaudiodev.c: add support for FreeBSD ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101374&group_id=5470 From noreply@sourceforge.net Thu Aug 31 14:17:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 06:17:45 -0700 Subject: [Patches] [Patch #101362] fix GC debugging output w.r.t. exceptions Message-ID: <200008311317.GAA27082@delerium.i.sourceforge.net> Patch #101362 has been updated. Project: Category: core (C code) Status: Open Summary: fix GC debugging output w.r.t. exceptions Follow-Ups: Date: 2000-Aug-30 14:12 By: marangoz Comment: Related to SF patch 101346. Use PySys_WriteStderr for debugging output to avoid interference with exception handling. Remove offending PyErr_Clear. If not initialized, output debugging messages through fprintf(stderr, ...) -- otherwise we can start finalization with remaining gc.debug flags which may screw up PySys_WriteStderr. ------------------------------------------------------- Date: 2000-Aug-30 19:28 By: jhylton Comment: Two issues; one simple. I don't understand why the Py_IsInitialized call is necessary. Can you add a brief comment that explains it? We discussed various patch options at a meeting today. One of our goals was to eliminate all the sprintf calls in gcmodule.c, since PySys_WriteStderr has a printf-like interface. Can you modify the local write_stderr so that it has the same interface? ------------------------------------------------------- Date: 2000-Aug-31 06:17 By: marangoz Comment: Ok -- removed sprintf calls & write_stderr altogether. Use only PySys_WriteStderr. The Py_IsInitialized business: you're right that it isn't necessary in the current state of the collector. Nevertheless, PySys_WriteStderr() keeps the collector dependent on an initialized interpreter for debugging output. As long as the collector works only on Python objects and triggers the collection process only on object allocations, this seems to be fine. If someday the collector is made to be triggered on object deallocations and it happens that a user GC'd object is freed (or allocated) after the interpreter is finalized, we'll fail with a fatal error while there's no such error and this is what I've tried to avoid (I have been bitten by this with memprof, but the latter is lower lever). The point is that once the gc.debug flags are set, there's no way to deactivate them from C & there's no a gc_fini function, so the collector will persist to output debugging traces independently on the Python state, through a Python function. This is not very cool for a garbage collector, which, in theory, is supposed to be at a lower level than the one of the application code. So there -- we may be bitten by this in the future. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101362&group_id=5470 From Aaron_Lacayo@popa.hn Thu Aug 31 14:02:13 2000 From: Aaron_Lacayo@popa.hn (Aaron Lacayo) Date: Thu, 31 Aug 2000 08:02:13 -0500 Subject: [Patches] Aaron Lacayo Message-ID: <39AE5754.95B2081C@popa.hn> Hi!, I am Aaron Lacayo from Honduras, and i will like to know if you have a patch for transport protocol call CA-MLINK and for PCanywhere cause I have a real problems with this two protocols. Thank Best regards! Aaron Lacayo From noreply@sourceforge.net Thu Aug 31 16:07:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:07:48 -0700 Subject: [Patches] [Patch #101362] fix GC debugging output w.r.t. exceptions Message-ID: <200008311507.IAA04398@bush.i.sourceforge.net> Patch #101362 has been updated. Project: Category: core (C code) Status: Accepted Summary: fix GC debugging output w.r.t. exceptions Follow-Ups: Date: 2000-Aug-30 14:12 By: marangoz Comment: Related to SF patch 101346. Use PySys_WriteStderr for debugging output to avoid interference with exception handling. Remove offending PyErr_Clear. If not initialized, output debugging messages through fprintf(stderr, ...) -- otherwise we can start finalization with remaining gc.debug flags which may screw up PySys_WriteStderr. ------------------------------------------------------- Date: 2000-Aug-30 19:28 By: jhylton Comment: Two issues; one simple. I don't understand why the Py_IsInitialized call is necessary. Can you add a brief comment that explains it? We discussed various patch options at a meeting today. One of our goals was to eliminate all the sprintf calls in gcmodule.c, since PySys_WriteStderr has a printf-like interface. Can you modify the local write_stderr so that it has the same interface? ------------------------------------------------------- Date: 2000-Aug-31 06:17 By: marangoz Comment: Ok -- removed sprintf calls & write_stderr altogether. Use only PySys_WriteStderr. The Py_IsInitialized business: you're right that it isn't necessary in the current state of the collector. Nevertheless, PySys_WriteStderr() keeps the collector dependent on an initialized interpreter for debugging output. As long as the collector works only on Python objects and triggers the collection process only on object allocations, this seems to be fine. If someday the collector is made to be triggered on object deallocations and it happens that a user GC'd object is freed (or allocated) after the interpreter is finalized, we'll fail with a fatal error while there's no such error and this is what I've tried to avoid (I have been bitten by this with memprof, but the latter is lower lever). The point is that once the gc.debug flags are set, there's no way to deactivate them from C & there's no a gc_fini function, so the collector will persist to output debugging traces independently on the Python state, through a Python function. This is not very cool for a garbage collector, which, in theory, is supposed to be at a lower level than the one of the application code. So there -- we may be bitten by this in the future. ------------------------------------------------------- Date: 2000-Aug-31 08:07 By: jhylton Comment: I'll check it in now, with two trivial changes (add .100 qualifier to two %s formats) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101362&group_id=5470 From noreply@sourceforge.net Thu Aug 31 16:13:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:13:21 -0700 Subject: [Patches] [Patch #101362] fix GC debugging output w.r.t. exceptions Message-ID: <200008311513.IAA04653@bush.i.sourceforge.net> Patch #101362 has been updated. Project: Category: core (C code) Status: Closed Summary: fix GC debugging output w.r.t. exceptions Follow-Ups: Date: 2000-Aug-30 14:12 By: marangoz Comment: Related to SF patch 101346. Use PySys_WriteStderr for debugging output to avoid interference with exception handling. Remove offending PyErr_Clear. If not initialized, output debugging messages through fprintf(stderr, ...) -- otherwise we can start finalization with remaining gc.debug flags which may screw up PySys_WriteStderr. ------------------------------------------------------- Date: 2000-Aug-30 19:28 By: jhylton Comment: Two issues; one simple. I don't understand why the Py_IsInitialized call is necessary. Can you add a brief comment that explains it? We discussed various patch options at a meeting today. One of our goals was to eliminate all the sprintf calls in gcmodule.c, since PySys_WriteStderr has a printf-like interface. Can you modify the local write_stderr so that it has the same interface? ------------------------------------------------------- Date: 2000-Aug-31 06:17 By: marangoz Comment: Ok -- removed sprintf calls & write_stderr altogether. Use only PySys_WriteStderr. The Py_IsInitialized business: you're right that it isn't necessary in the current state of the collector. Nevertheless, PySys_WriteStderr() keeps the collector dependent on an initialized interpreter for debugging output. As long as the collector works only on Python objects and triggers the collection process only on object allocations, this seems to be fine. If someday the collector is made to be triggered on object deallocations and it happens that a user GC'd object is freed (or allocated) after the interpreter is finalized, we'll fail with a fatal error while there's no such error and this is what I've tried to avoid (I have been bitten by this with memprof, but the latter is lower lever). The point is that once the gc.debug flags are set, there's no way to deactivate them from C & there's no a gc_fini function, so the collector will persist to output debugging traces independently on the Python state, through a Python function. This is not very cool for a garbage collector, which, in theory, is supposed to be at a lower level than the one of the application code. So there -- we may be bitten by this in the future. ------------------------------------------------------- Date: 2000-Aug-31 08:07 By: jhylton Comment: I'll check it in now, with two trivial changes (add .100 qualifier to two %s formats) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101362&group_id=5470 From noreply@sourceforge.net Thu Aug 31 16:38:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:38:04 -0700 Subject: [Patches] [Patch #101369] Solves bug 111961 Message-ID: <200008311538.IAA05704@bush.i.sourceforge.net> Patch #101369 has been updated. Project: Category: Modules Status: Accepted Summary: Solves bug 111961 Follow-Ups: Date: 2000-Aug-31 00:52 By: fdrake Comment: Moshe requested that I post this patch and assign it to Jeremy; his net connection is flaky at the moment. ------------------------------------------------------- Date: 2000-Aug-31 08:38 By: jhylton Comment: looks fine; i'll apply ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101369&group_id=5470 From noreply@sourceforge.net Thu Aug 31 16:49:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:49:04 -0700 Subject: [Patches] [Patch #101369] Solves bug 111961 Message-ID: <200008311549.IAA06103@bush.i.sourceforge.net> Patch #101369 has been updated. Project: Category: Modules Status: Closed Summary: Solves bug 111961 Follow-Ups: Date: 2000-Aug-31 00:52 By: fdrake Comment: Moshe requested that I post this patch and assign it to Jeremy; his net connection is flaky at the moment. ------------------------------------------------------- Date: 2000-Aug-31 08:38 By: jhylton Comment: looks fine; i'll apply ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101369&group_id=5470 From noreply@sourceforge.net Thu Aug 31 16:56:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:56:55 -0700 Subject: [Patches] [Patch #101374] linuxaudiodev.c: add support for FreeBSD Message-ID: <200008311556.IAA06433@bush.i.sourceforge.net> Patch #101374 has been updated. Project: Category: Modules Status: Accepted Summary: linuxaudiodev.c: add support for FreeBSD ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101374&group_id=5470 From noreply@sourceforge.net Thu Aug 31 17:14:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 09:14:02 -0700 Subject: [Patches] [Patch #101272] Allow bsddbmodule.c to compile with libdb 2.x w/o editing Message-ID: <200008311614.JAA06978@bush.i.sourceforge.net> Patch #101272 has been updated. Project: Category: Modules Status: Closed Summary: Allow bsddbmodule.c to compile with libdb 2.x w/o editing Follow-Ups: Date: 2000-Aug-23 19:22 By: montanaro Comment: Eric's been doing lots w/ libdb stuff lately. I'll see if he want's to check this patch out... ;-) ------------------------------------------------------- Date: 2000-Aug-23 20:01 By: fdrake Comment: Update patch to also determine whether the bsddb module should be built at all automatically (adding a stanza to Setup.config.in and a comment to Setup.in). This won't detect all cases automatically, but will catch it on platforms which have it installed as part of the base system (same as for the original patch). ------------------------------------------------------- Date: 2000-Aug-23 20:02 By: fdrake Comment: I'd better note that this still needs testing on a system that only offers BSD db 1.85. ------------------------------------------------------- Date: 2000-Aug-23 20:24 By: montanaro Comment: I'm afraid that's beyond my feeble autoconf/configure skills. libdb.a is hardly installed in a standard location on all systems. The Setup.config.in line would be more involved than @USE_BSDDB_MODULE@bsddb bsddbmodule.c -ldb (though that would work on my Mandrake Linux system). I suspect many people still have to install libdb themselves, so it could wind up just about anywhere. You'd have to teach autoconf to reliably find libdb.a then add a line to Setup.config.in that has the correct -L flag. ------------------------------------------------------- Date: 2000-Aug-23 20:39 By: fdrake Comment: This is sufficient for all cases that the header detection can deal with. We could (& perhaps should) add the necessary test to make sure -ldb works. For BSD db installs that aren't picked up this way, the stanza in Setup.in remains, and can be edited in Setup or provided in Setup.local. ------------------------------------------------------- Date: 2000-Aug-24 08:17 By: montanaro Comment: Okay, this patch goes a bit farther. Here's a quick summary: 1. It adds a line to Modules/Setup.config.in for the bsddb module, prefixed with USE_BSDDB_MODULE. 2. Configure gains a --with-libdb flag. If either --with-libdb is added to the command line or db.h is found, the bsddb module will be enabled. Of course, running configure using --without-libdb will disable it. 3. There's a comment in Setup.in about the new way of enabling the bsddb module, but the old commented out lines are still there. 4. If db_185.h is found, it's included instead of db.h. Both #includes are protected by their relevant HAVE_* defines in Modules/bsddbmodule.c (or should I let the db.h include fail?). 5. No attempt is made to search for libdb.h. It's assumed that if users install it in some odd location they will run configure with the --libdir and/or --includedir flags. Still needs testing on a 1.85/1.86 libdb. ------------------------------------------------------- Date: 2000-Aug-24 18:49 By: montanaro Comment: A new version of the patch to keep pace with other changes to the configure.in file ------------------------------------------------------- Date: 2000-Aug-30 12:16 By: gvanrossum Comment: For Fred to accept or check in. ------------------------------------------------------- Date: 2000-Aug-31 09:14 By: fdrake Comment: Checked in with minor changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101272&group_id=5470 From noreply@sourceforge.net Thu Aug 31 17:37:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 09:37:01 -0700 Subject: [Patches] [Patch #101086] libcalendar.tex extensions (untested; don't have TeX) Message-ID: <200008311637.JAA07848@bush.i.sourceforge.net> Patch #101086 has been updated. Project: Category: documentation Status: Closed Summary: libcalendar.tex extensions (untested; don't have TeX) Follow-Ups: Date: 2000-Aug-05 18:57 By: goodger Comment: I don't have TeX, and am not fluent, so I hacked the doc code. I haven't tested it and can't guarantee it is without error. I hope it doesn't cause you any trouble. Sorry! ------------------------------------------------------- Date: 2000-Aug-15 12:08 By: tim_one Comment: Assigned to Skip because it appears to be a companion to the calendar.py patch. Skip, if you like the latter patch, I guess this patch should get assigned to Fred next. ------------------------------------------------------- Date: 2000-Aug-17 13:19 By: montanaro Comment: Documentation of function signatures should match definition (e.g., w & l vs width & length) ------------------------------------------------------- Date: 2000-Aug-23 19:21 By: montanaro Comment: sent note to David asking about status of an updated patch ------------------------------------------------------- Date: 2000-Aug-23 21:22 By: goodger Comment: will post an update by the weekend ------------------------------------------------------- Date: 2000-Aug-26 14:20 By: goodger Comment: revised patch: Up to date with calendar.py patch (#101085); all function signatures now match the module code. ------------------------------------------------------- Date: 2000-Aug-30 12:14 By: gvanrossum Comment: For Fred to close after verifying that the docs are okay. ------------------------------------------------------- Date: 2000-Aug-31 09:37 By: fdrake Comment: Looks fine, and it's already applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101086&group_id=5470 From noreply@sourceforge.net Thu Aug 31 17:40:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 09:40:50 -0700 Subject: [Patches] [Patch #101345] Remove obsolete --with(out)-readline option Message-ID: <200008311640.JAA07952@bush.i.sourceforge.net> Patch #101345 has been updated. Project: Category: Build Status: Closed Summary: Remove obsolete --with(out)-readline option Follow-Ups: Date: 2000-Aug-29 09:40 By: marangoz Comment: I believe that it's time for this option to go away. It makes no sense for 2.0 to keep it alive and issue an error, if given, saying that the option is obsolete. ------------------------------------------------------- Date: 2000-Aug-30 12:45 By: gvanrossum Comment: Cool. Go ahead. ------------------------------------------------------- Date: 2000-Aug-31 09:40 By: marangoz Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101345&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:36:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:36:11 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311736.KAA10079@bush.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Open Summary: sys.(get|set)recursionlimit ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:39:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:39:13 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311739.KAA10209@bush.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Open Summary: sys.(get|set)recursionlimit Follow-Ups: Date: 2000-Aug-31 10:39 By: jhylton Comment: I also have a script find_limit.py that tries executes a bunch of different infinite recursion tests. It could be included in Misc to let people find the right value for their platform. The limit of 2500 is a bit conservative, but it's based on a recursive repr function that crashes after 2900 calls on my Linux box. The other tests seems to survive up to 9100. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:42:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:42:55 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311742.KAA10385@bush.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Open Summary: sys.(get|set)recursionlimit Follow-Ups: Date: 2000-Aug-31 10:39 By: jhylton Comment: I also have a script find_limit.py that tries executes a bunch of different infinite recursion tests. It could be included in Misc to let people find the right value for their platform. The limit of 2500 is a bit conservative, but it's based on a recursive repr function that crashes after 2900 calls on my Linux box. The other tests seems to survive up to 9100. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:45:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:45:45 -0700 Subject: [Patches] [Patch #101373] configure.in: missing brackets Message-ID: <200008311745.KAA10429@bush.i.sourceforge.net> Patch #101373 has been updated. Project: Category: Build Status: Accepted Summary: configure.in: missing brackets ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101373&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:46:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:46:11 -0700 Subject: [Patches] [Patch #101373] configure.in: missing brackets Message-ID: <200008311746.KAA10471@bush.i.sourceforge.net> Patch #101373 has been updated. Project: Category: Build Status: Closed Summary: configure.in: missing brackets ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101373&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:46:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:46:15 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311746.KAA10475@bush.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Open Summary: sys.(get|set)recursionlimit Follow-Ups: Date: 2000-Aug-31 10:39 By: jhylton Comment: I also have a script find_limit.py that tries executes a bunch of different infinite recursion tests. It could be included in Misc to let people find the right value for their platform. The limit of 2500 is a bit conservative, but it's based on a recursive repr function that crashes after 2900 calls on my Linux box. The other tests seems to survive up to 9100. ------------------------------------------------------- Date: 2000-Aug-31 10:46 By: marangoz Comment: _Py_RecursionLimit is a better name for the variable. A public C API Py_SetRecursionLimit() / Py_GetRecursionLimit() would be nice and fair play with extension writers. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 17:54:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 09:54:32 -0700 Subject: [Patches] [Patch #101275] Issue a warning if Setup.in is newer than Setup Message-ID: <200008311654.JAA02913@delerium.i.sourceforge.net> Patch #101275 has been updated. Project: Category: Build Status: Closed Summary: Issue a warning if Setup.in is newer than Setup Follow-Ups: Date: 2000-Aug-24 07:23 By: fdrake Comment: This issues a waring during the build if the generated Setup flie is older than the Setup.in file. This is helpful in getting users to check that they have everything they need in their Setup file. The limitation is that the warning is issued several times during a build, but it's not clear that's a serious problem, though it is potentially annoying. ------------------------------------------------------- Date: 2000-Aug-24 08:05 By: montanaro Comment: This works fine for me. My only question is whether the use of the relatively new "-nt" flag of test is going to be as portable as we'd like. I notice it's not used anywhere else in the Python makefiles or in the configure script. Configure only uses =, !=, -gt and -eq. It's a script that tries to be painfully portable. On the other hand, if we're requiring an ANSI C compiler, why not a fairly recent incarnation of /bin/sh? Other than that thought, I say check it in. ------------------------------------------------------- Date: 2000-Aug-24 08:13 By: fdrake Comment: My Mandrake box doesn't have a man page for sh(1), so it may be that -nt is specific to bash; Mandrake uses a symlink to use bash as sh, so there's no way for me to tell if -nt is available under a traditional sh. This could be a showstopper for this patch. ------------------------------------------------------- Date: 2000-Aug-24 08:19 By: montanaro Comment: try "man 1 test". -nt is actually an argument to the test command. Bash's builtin test command does support -nt. ------------------------------------------------------- Date: 2000-Aug-24 08:32 By: twouters Comment: BSDI 'test' does not support -nt. ------------------------------------------------------- Date: 2000-Aug-24 09:51 By: montanaro Comment: In light of Thomas's comment about BSDI's test command, I recommend this patch be postponed until 2.1. It's minor enough. Still, we do need to prod people into comparing Setup.in with preexisting Setup files, otherwise we're going to get a lot of "not-a-bugs" once the software is made widely available. find(1) has a -newer predicate. Is it safe enough to assume it's universally available on systems that can build with Python's Makefile? if [ "`find . -name Setup.in -newer Setup`" = "./Setup.in" ] then echo 'compare Setup and Setup.in for changes!' fi ------------------------------------------------------- Date: 2000-Aug-24 10:03 By: fdrake Comment: Postponed for Python 2.1; assigned to the release manager to re-open after 2.0 is released. The use of find is more difficult; the whole thing must be inside a test that makes sure Setup already exists. Also, the test should be something closer to (untested): [ "`find $(srcdir) -name Setup.in -newer Setup`" = "$(srcdir)/Setup.in" ] ------------------------------------------------------- Date: 2000-Aug-24 14:49 By: twouters Comment: Eep, don't use find. Find has more platform-specific issues than has 'test'! (Don't get me started on BSDI find, please ;) However, I'm getting the feeling this is re-inventing the wheel. 'make' was intended for this kind of thing! And it already does the modified-time check and such: if Setup.in isn't newer than the existing Setup, the body of the rule shouldn't get called. Isn't it enough to test whether there already exists a Setup, and produce a warning if so ? ------------------------------------------------------- Date: 2000-Aug-24 15:15 By: montanaro Comment: doh! I think Thomas is onto something... ------------------------------------------------------- Date: 2000-Aug-24 19:04 By: montanaro Comment: Thomas was correct. I reworked the patch and sent a copy to Fred. I think this patch will ward off a lot of spurious "2.0 won't build" messages in c.l.py and should - for that reason alone - be added to 2.0. People are going to try building 2.0 with 1.5 Setup files. Socket at least won't build without some Setup file tweaks. I'm reopening it and assigning it back to Fred. ------------------------------------------------------- Date: 2000-Aug-30 12:19 By: gvanrossum Comment: Make Setup depend on Setup.in in the Makefile. Then the rule is invoked when Setup.in is newer than Setup as well as when Setup doesn't exist yet. The rule should test whether Setup already exists and in that case issue a warning instead of overwriting Setup. ------------------------------------------------------- Date: 2000-Aug-30 15:02 By: montanaro Comment: yup - that's what the latest patch does. ------------------------------------------------------- Date: 2000-Aug-31 09:54 By: fdrake Comment: Checked in using a portable test -- only use the "-f" test. If the file already exists and this rule is being called, that's *because* make knows that Setup.in is newer than Setup, as Thomas points out. Don't do the work if we don't have to! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101275&group_id=5470 From noreply@sourceforge.net Thu Aug 31 19:00:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 11:00:09 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311800.LAA11035@bush.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Open Summary: sys.(get|set)recursionlimit Follow-Ups: Date: 2000-Aug-31 10:39 By: jhylton Comment: I also have a script find_limit.py that tries executes a bunch of different infinite recursion tests. It could be included in Misc to let people find the right value for their platform. The limit of 2500 is a bit conservative, but it's based on a recursive repr function that crashes after 2900 calls on my Linux box. The other tests seems to survive up to 9100. ------------------------------------------------------- Date: 2000-Aug-31 10:46 By: marangoz Comment: _Py_RecursionLimit is a better name for the variable. A public C API Py_SetRecursionLimit() / Py_GetRecursionLimit() would be nice and fair play with extension writers. ------------------------------------------------------- Date: 2000-Aug-31 11:00 By: jhylton Comment: Improvements from Vladimir, plus cleanup of some sloppy naming in sysmodule. Still need to add docs for new C API calls. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 19:11:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 11:11:18 -0700 Subject: [Patches] [Patch #101374] linuxaudiodev.c: add support for FreeBSD Message-ID: <200008311811.LAA11428@bush.i.sourceforge.net> Patch #101374 has been updated. Project: Category: Modules Status: Closed Summary: linuxaudiodev.c: add support for FreeBSD ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101374&group_id=5470 From noreply@sourceforge.net Thu Aug 31 19:17:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 11:17:35 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311817.LAA06185@delerium.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Open Summary: sys.(get|set)recursionlimit Follow-Ups: Date: 2000-Aug-31 10:39 By: jhylton Comment: I also have a script find_limit.py that tries executes a bunch of different infinite recursion tests. It could be included in Misc to let people find the right value for their platform. The limit of 2500 is a bit conservative, but it's based on a recursive repr function that crashes after 2900 calls on my Linux box. The other tests seems to survive up to 9100. ------------------------------------------------------- Date: 2000-Aug-31 10:46 By: marangoz Comment: _Py_RecursionLimit is a better name for the variable. A public C API Py_SetRecursionLimit() / Py_GetRecursionLimit() would be nice and fair play with extension writers. ------------------------------------------------------- Date: 2000-Aug-31 11:00 By: jhylton Comment: Improvements from Vladimir, plus cleanup of some sloppy naming in sysmodule. Still need to add docs for new C API calls. ------------------------------------------------------- Date: 2000-Aug-31 11:17 By: gvanrossum Comment: missing sysmodule.c part. the recursion limit variable should be static. otherwise fine. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 19:20:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 11:20:26 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311820.LAA11816@bush.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Open Summary: sys.(get|set)recursionlimit Follow-Ups: Date: 2000-Aug-31 10:39 By: jhylton Comment: I also have a script find_limit.py that tries executes a bunch of different infinite recursion tests. It could be included in Misc to let people find the right value for their platform. The limit of 2500 is a bit conservative, but it's based on a recursive repr function that crashes after 2900 calls on my Linux box. The other tests seems to survive up to 9100. ------------------------------------------------------- Date: 2000-Aug-31 10:46 By: marangoz Comment: _Py_RecursionLimit is a better name for the variable. A public C API Py_SetRecursionLimit() / Py_GetRecursionLimit() would be nice and fair play with extension writers. ------------------------------------------------------- Date: 2000-Aug-31 11:00 By: jhylton Comment: Improvements from Vladimir, plus cleanup of some sloppy naming in sysmodule. Still need to add docs for new C API calls. ------------------------------------------------------- Date: 2000-Aug-31 11:17 By: gvanrossum Comment: missing sysmodule.c part. the recursion limit variable should be static. otherwise fine. ------------------------------------------------------- Date: 2000-Aug-31 11:20 By: jhylton Comment: make _Py_RecursionLimit static; use the C API add sysmodule.c changes to patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 19:32:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 11:32:45 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311832.LAA12359@bush.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Open Summary: sys.(get|set)recursionlimit Follow-Ups: Date: 2000-Aug-31 10:39 By: jhylton Comment: I also have a script find_limit.py that tries executes a bunch of different infinite recursion tests. It could be included in Misc to let people find the right value for their platform. The limit of 2500 is a bit conservative, but it's based on a recursive repr function that crashes after 2900 calls on my Linux box. The other tests seems to survive up to 9100. ------------------------------------------------------- Date: 2000-Aug-31 10:46 By: marangoz Comment: _Py_RecursionLimit is a better name for the variable. A public C API Py_SetRecursionLimit() / Py_GetRecursionLimit() would be nice and fair play with extension writers. ------------------------------------------------------- Date: 2000-Aug-31 11:00 By: jhylton Comment: Improvements from Vladimir, plus cleanup of some sloppy naming in sysmodule. Still need to add docs for new C API calls. ------------------------------------------------------- Date: 2000-Aug-31 11:17 By: gvanrossum Comment: missing sysmodule.c part. the recursion limit variable should be static. otherwise fine. ------------------------------------------------------- Date: 2000-Aug-31 11:20 By: jhylton Comment: make _Py_RecursionLimit static; use the C API add sysmodule.c changes to patch ------------------------------------------------------- Date: 2000-Aug-31 11:32 By: jhylton Comment: Oops. Made the old patch with a >> /tmp/file instead of > /tmp/file ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 19:39:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 11:39:31 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311839.LAA12610@bush.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Open Summary: sys.(get|set)recursionlimit Follow-Ups: Date: 2000-Aug-31 10:39 By: jhylton Comment: I also have a script find_limit.py that tries executes a bunch of different infinite recursion tests. It could be included in Misc to let people find the right value for their platform. The limit of 2500 is a bit conservative, but it's based on a recursive repr function that crashes after 2900 calls on my Linux box. The other tests seems to survive up to 9100. ------------------------------------------------------- Date: 2000-Aug-31 10:46 By: marangoz Comment: _Py_RecursionLimit is a better name for the variable. A public C API Py_SetRecursionLimit() / Py_GetRecursionLimit() would be nice and fair play with extension writers. ------------------------------------------------------- Date: 2000-Aug-31 11:00 By: jhylton Comment: Improvements from Vladimir, plus cleanup of some sloppy naming in sysmodule. Still need to add docs for new C API calls. ------------------------------------------------------- Date: 2000-Aug-31 11:17 By: gvanrossum Comment: missing sysmodule.c part. the recursion limit variable should be static. otherwise fine. ------------------------------------------------------- Date: 2000-Aug-31 11:20 By: jhylton Comment: make _Py_RecursionLimit static; use the C API add sysmodule.c changes to patch ------------------------------------------------------- Date: 2000-Aug-31 11:32 By: jhylton Comment: Oops. Made the old patch with a >> /tmp/file instead of > /tmp/file ------------------------------------------------------- Date: 2000-Aug-31 11:39 By: marangoz Comment: Looks good. I thought we agreed to be conservative and default to 1000? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 19:46:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 11:46:25 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311846.LAA07321@delerium.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Open Summary: sys.(get|set)recursionlimit Follow-Ups: Date: 2000-Aug-31 10:39 By: jhylton Comment: I also have a script find_limit.py that tries executes a bunch of different infinite recursion tests. It could be included in Misc to let people find the right value for their platform. The limit of 2500 is a bit conservative, but it's based on a recursive repr function that crashes after 2900 calls on my Linux box. The other tests seems to survive up to 9100. ------------------------------------------------------- Date: 2000-Aug-31 10:46 By: marangoz Comment: _Py_RecursionLimit is a better name for the variable. A public C API Py_SetRecursionLimit() / Py_GetRecursionLimit() would be nice and fair play with extension writers. ------------------------------------------------------- Date: 2000-Aug-31 11:00 By: jhylton Comment: Improvements from Vladimir, plus cleanup of some sloppy naming in sysmodule. Still need to add docs for new C API calls. ------------------------------------------------------- Date: 2000-Aug-31 11:17 By: gvanrossum Comment: missing sysmodule.c part. the recursion limit variable should be static. otherwise fine. ------------------------------------------------------- Date: 2000-Aug-31 11:20 By: jhylton Comment: make _Py_RecursionLimit static; use the C API add sysmodule.c changes to patch ------------------------------------------------------- Date: 2000-Aug-31 11:32 By: jhylton Comment: Oops. Made the old patch with a >> /tmp/file instead of > /tmp/file ------------------------------------------------------- Date: 2000-Aug-31 11:39 By: marangoz Comment: Looks good. I thought we agreed to be conservative and default to 1000? ------------------------------------------------------- Date: 2000-Aug-31 11:46 By: marangoz Comment: Oops. A hardcoded lowest possible minimum seems desirable (100 ?), both in the Python and the C interface. If the limit is set to 1, I expect big fun. And leaving it like this would be open to abuse... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 20:06:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 12:06:13 -0700 Subject: [Patches] [Patch #101277] Catch errors raised by comparisons during dictionary lookup. Message-ID: <200008311906.MAA13587@bush.i.sourceforge.net> Patch #101277 has been updated. Project: Category: core (C code) Status: Closed Summary: Catch errors raised by comparisons during dictionary lookup. Follow-Ups: Date: 2000-Aug-24 08:44 By: fdrake Comment: THIS PATCH IS NOT READY! This attempts to fix the bug described in SourceForge bug #112558. In attempting to catch and ignore errors raised by PyObject_Compare(), it checks for those errors, and, if found, clears them and continues to search for another entry. Unfortunately, this doesn't quite work. It fixes the specific case presented in the bug report, but causes other cases to fail. Running the regression tests for compile, getopt, sre, strftime, and tokenize all fail when PyEval_CallObjectWithKeywords() or eval_code2() detect an error return without an exception being set. Is should note that errors are detected in these cases when PyObject_Compare() is returning 0; I'm not actually seeing any cases where the comparison is returning non-zero other than the test case in the bug report. I'd really appreciate some help on this one! ------------------------------------------------------- Date: 2000-Aug-24 09:00 By: gvanrossum Comment: Fine, except that there are two fprintf statements that should be taken out! After that, check it in and close it, presuming "make test" succeeds. (I would hope that you have tried this before submitting.) ------------------------------------------------------- Date: 2000-Aug-24 09:33 By: fdrake Comment: (Yes, I knew about the fprintf()s; I figured that's fine as long as the patch was in a testing phase and clearly declared not yet ready.) Here's a new version of the patch that makes a change to the error detection: it only checks PyErr_Occurred() if PyObject_Compare() returns non-zero. The regression test passes and the test case in the bug report now does the right thing. This is based on my vague recollection that the tp_compare function is supposed to return non-zero on errors. I can't find any documentation about that however. It would mean that the documentation needs to be updated to state that PyObject_Compare() will return non-zero on errors as well, and code elsewhere that checks for errors after calling PyObject_Compare() may need to be adjusted. There is a question lurking here: if an exception is getting set before lookdict() is called or by a comparison returning 0, there's some broken code somewhere else that may need revision. I'm also led to believe that PyObject_Cmp() may not always report correctly. So I think this patch is better than no change, but I'm not convinced it's really right. ------------------------------------------------------- Date: 2000-Aug-24 10:01 By: gvanrossum Comment: I don't think this is any better -- it can still call PyErr_Clear when there was a previously existing exception. Unfortunately you can't use PyObject_Cmp() either, because it does the same thing: just calls PyErr_Occurred(). So the solution is really to use PyErr_Fetch and _Restore... ------------------------------------------------------- Date: 2000-Aug-24 10:55 By: fdrake Comment: Revised to handle Guido's concerns stated in his comments below. This doesn't avoid the problem of "PyThreadState_Get: no current thread" -- PyErr_Occurred() needs the current thread state to work, and it may not be available. ;-( ------------------------------------------------------- Date: 2000-Aug-25 00:54 By: lemburg Comment: Fred, have you checked the performance hit this introduces ? I'm just asking because the code you are touching here is just about the most often executed in the Python interpreter and I don't really see the point of adding a performance for situations which only occur rarely if at all in most programs. Also, why do you think that masking compare errors during dict key compare is a good thing ? I agree that the current situation is bad because it produces dangling execption states, but simply clearing the exception doesn't help much either -- it only masks other problems. The simple and clear solution would be passing the exception back to the caller instead of clearing it. If you really think that exceptions during compares should be considered as "doesn't match", then I'd opt for introducing a whole new PyObject_CompareEx() API which wraps this idea and takes the appropriate actions. I think this needs some more discussion on python-dev... ------------------------------------------------------- Date: 2000-Aug-25 05:49 By: fdrake Comment: Performance has *not* been checked -- there's no need to do that until the patch *works*. I understand the performance issue here; Guido and I have turnned this one around a few times and it's just plain hard to get right. One thing to recall is that the current implementation is broken as well; try the test case Jeremy submitted when he filed the bug report. (Keep in mind that I'm calling this patch "NOT READY" still -- I have no intention of checking this in as it stands.) Clearing exceptions in the comparison is clearly a bad thing, but they're getting raised in a chunk of code that simply doesn't allow raising exceptions. This is not well explained in the comments; I'll try to improve them. One issue with the problem is that and exception in the comparison can cause us not to find the entry we're looking for; during C-level exception handling, we're still trying to propogate another exception as well. Even if the general solution proves too slow for use with the module dictionaries (which will require testing to determine), I have some ideas about what it would take to make those fast anyway. I'll describe those later on python-dev. ------------------------------------------------------- Date: 2000-Aug-25 07:12 By: lemburg Comment: Ok. Sorry if that last message sounded a bit like FUD. This needs to be fixed, but I do think that we should get some more feedback and ideas into this... so let's head for python-dev :-) ------------------------------------------------------- Date: 2000-Aug-29 20:49 By: fdrake Comment: Please review and advise regarding the importance of this bug. Not that this patch may have some problems; appearantly Guido was able to get it to break (missing tstate needed by PyErr_*() usage introduced here), but I've not received information needed to duplicate the breakage. ------------------------------------------------------- Date: 2000-Aug-29 21:21 By: tim_one Comment: FYI, Guido told me the patch (or a close relative) made it thru the std test suite, but died running pystone(!). ------------------------------------------------------- Date: 2000-Aug-29 21:42 By: fdrake Comment: Guido told me that as well, but I was not able to reproduce it. He has not provided instructions to duplicate the failure; I just ran pystones.py as a script. ------------------------------------------------------- Date: 2000-Aug-29 21:46 By: tim_one Comment: Actually, I'm relieved to hear that! pystone doesn't do anything strange at all. Guess we'll have to wait for Guido to chime in ... ------------------------------------------------------- Date: 2000-Aug-30 08:24 By: marangoz Comment: Hmm. Instead of plugging complicated logic in lookdict which is likely to slow things down, I'd suggest deferring the exception checks in a helper function, say, compare_equal_noex() which will be called from lookdict on hash collisions (this is relatively rare anyway) and which will wrap the call to PyObject_Compare with fetch/restore. This has the advantage of being able to change the semantics of the return value of PyObject_Compare to something more suitable for lookdict (and/or implement the optimized restore-exception-on-need logic of this patch in the helper function). ------------------------------------------------------- Date: 2000-Aug-30 11:34 By: marangoz Comment: Well, things are clearly broken and we all realize that . What needs to be done here is to return a failure from the public API (PyDict_GetItem, _SetItem, etc). For that matter, we need to abort the current table search (lookdict) for any *newly* raised exception. (assuming the dict API is called with no errors in place -- and I'm unclear on whether we can safely assume that...). Which means that whenever an error is detected from PyObject_Compare, we need to fail. Both in lookdict and in insertdict. On failure, lookdict should return a predefined "error_item" which has a NULL value. Subsequently, insertdict should be made to detect this error case and return -1 (on ma_value == NULL and ep == error_item) to signal the failure to SetItem which will in turn return -1. So, among others, insertdict() needs to return an error code (currently it's a void function). And I don't see a way to avoid this if we want to detect a new error incoming from PyObject_Compare(). OTOH, things get complicated because if there's a previous error in place, it seems like we need to propagate the original error (both on failure and on success). It is still unclear, however, what to do if PyDict_SetItem is called with an existing error *and* PyObject_Compare raises an exception. Should we fail by leaving the new exception or fail by propagating the old one? ------------------------------------------------------- Date: 2000-Aug-30 12:21 By: gvanrossum Comment: For Fred to resolve. We've discussed this at our meeting and we agree on Fred's approach. ------------------------------------------------------- Date: 2000-Aug-31 12:06 By: fdrake Comment: Checked in as dictobject.c revision 2.63; bug marked closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 From noreply@sourceforge.net Thu Aug 31 20:24:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 12:24:40 -0700 Subject: [Patches] [Patch #101380] sys.(get|set)recursionlimit Message-ID: <200008311924.MAA14308@bush.i.sourceforge.net> Patch #101380 has been updated. Project: Category: core (C code) Status: Closed Summary: sys.(get|set)recursionlimit Follow-Ups: Date: 2000-Aug-31 10:39 By: jhylton Comment: I also have a script find_limit.py that tries executes a bunch of different infinite recursion tests. It could be included in Misc to let people find the right value for their platform. The limit of 2500 is a bit conservative, but it's based on a recursive repr function that crashes after 2900 calls on my Linux box. The other tests seems to survive up to 9100. ------------------------------------------------------- Date: 2000-Aug-31 10:46 By: marangoz Comment: _Py_RecursionLimit is a better name for the variable. A public C API Py_SetRecursionLimit() / Py_GetRecursionLimit() would be nice and fair play with extension writers. ------------------------------------------------------- Date: 2000-Aug-31 11:00 By: jhylton Comment: Improvements from Vladimir, plus cleanup of some sloppy naming in sysmodule. Still need to add docs for new C API calls. ------------------------------------------------------- Date: 2000-Aug-31 11:17 By: gvanrossum Comment: missing sysmodule.c part. the recursion limit variable should be static. otherwise fine. ------------------------------------------------------- Date: 2000-Aug-31 11:20 By: jhylton Comment: make _Py_RecursionLimit static; use the C API add sysmodule.c changes to patch ------------------------------------------------------- Date: 2000-Aug-31 11:32 By: jhylton Comment: Oops. Made the old patch with a >> /tmp/file instead of > /tmp/file ------------------------------------------------------- Date: 2000-Aug-31 11:39 By: marangoz Comment: Looks good. I thought we agreed to be conservative and default to 1000? ------------------------------------------------------- Date: 2000-Aug-31 11:46 By: marangoz Comment: Oops. A hardcoded lowest possible minimum seems desirable (100 ?), both in the Python and the C interface. If the limit is set to 1, I expect big fun. And leaving it like this would be open to abuse... ------------------------------------------------------- Date: 2000-Aug-31 12:24 By: jhylton Comment: Slightly modified patch accepted by Guido and checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101380&group_id=5470 From noreply@sourceforge.net Thu Aug 31 20:32:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 12:32:20 -0700 Subject: [Patches] [Patch #101309] Specialization of dictionaries for strings. Message-ID: <200008311932.MAA08918@delerium.i.sourceforge.net> Patch #101309 has been updated. Project: Category: core (C code) Status: Closed Summary: Specialization of dictionaries for strings. Follow-Ups: Date: 2000-Aug-25 22:26 By: fdrake Comment: This patch introduces some changes to the builtin dictionary type. These changes create a specialization of the type to better support efficient use of dictionaries as a runtime implementation detail. This patch causes all newly created dictionaries to be specialized for string keys; dictionaries are converted (trivially) to handle arbitrary keys as needed. If a non-string is used as a key (even if only doing a lookup and it fails), the dictionary is converted to a normal dictionary. To achieve faster performance, a specialized version of the lookdict() function is used. The specialized implementation can assume two things that the "normal" implementation cannot: - that all comparisons are always done using the PyString_Type.tp_compare function, avoiding some of the overhead of calling PyObject_Compare() and dereferencing the comparison function repeatedly, and - that the comparison function never raises an exception, since two strings can always be compared without an error. Some debugging code added to dictobject.c shows that most dictionaries created during the regression test are never converted to "normal" dictionaries, but always only use strings as keys: created 115874 string dicts converted 2658 to normal dicts 2.29% conversion rate Additional performance tests should be made. I expect that a patch such as this is most valuable if additional code is needed to robustify lookdict() to properly deal with exceptions from user-defined comparison functions (tp_compare handlers of __cmp__() functions in Python code). The patch duplicates the logic of the lookdict() function, which makes maintenance more tedious. ------------------------------------------------------- Date: 2000-Aug-30 12:27 By: marangoz Comment: I doubt we'll gain something from this, if anything at all. Some more stats: for pystone: 1052981 total dict lookups, of which 2182 (0.21%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons for the regression test suite: 7266955 total dict lookups, of which 580978 (7.99%) hash collisions/calls to cmp 0 (0.00%) failed object comparisons Postponed for further investigation. There's an idea in the lazy, runtime specialization of the lookup algorithm! ------------------------------------------------------- Date: 2000-Aug-30 12:30 By: gvanrossum Comment: Guido needs to decide whether this is needed to make the other dict patch safe when tstate==NULL. ------------------------------------------------------- Date: 2000-Aug-30 12:46 By: marangoz Comment: Looks like the other dict patch needs to use PyErr_xxx calls inside/after PyThreadState_GET() != NULL checks. if tstate==NULL, the PyErr logic must be skipped (this is an orphan state or a temporary state on early initialization & late finalization -- need to dbl check this once again). ------------------------------------------------------- Date: 2000-Aug-30 22:28 By: fdrake Comment: Changed this a little: - counting code that determines how often dictionaries are "degraded" is conditionalized and not included by default. - Instead of calling PyObject_Compare() in lookdict_string(), directly call the string type's tp_compare handler. This saves the various tests done in PyObject_Compare(), as well as the creation of a few C call frames. ------------------------------------------------------- Date: 2000-Aug-31 12:32 By: fdrake Comment: Checked in as dictobject.c 2.64 -- uploaded final version of the patch with this closure. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 From noreply@sourceforge.net Thu Aug 31 22:22:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 14:22:01 -0700 Subject: [Patches] [Patch #101320] Translate doc strings Message-ID: <200008312122.OAA18663@bush.i.sourceforge.net> Patch #101320 has been updated. Project: Category: library Status: Postponed Summary: Translate doc strings Follow-Ups: Date: 2000-Aug-28 00:46 By: tim_one Comment: Assigned to Barry since it seems related to gettext. ------------------------------------------------------- Date: 2000-Aug-30 12:38 By: gvanrossum Comment: Barry will comment on this and then postpone it. ------------------------------------------------------- Date: 2000-Aug-31 14:22 By: bwarsaw Comment: We're postponing this patch for 2.0 for a couple of reasons. First, it seems that more discussion about exactly how to distribute translations of docstrings should take place on the i18n-sig. Second, these files are fairly large so they probably shouldn't go into the core Python distribution, although some infrastructure is need to get these to translators, and back to end users. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101320&group_id=5470 From noreply@sourceforge.net Thu Aug 31 22:36:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 14:36:13 -0700 Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display Message-ID: <200008312136.OAA13427@delerium.i.sourceforge.net> Patch #100947 has been updated. Project: Category: library Status: Postponed Summary: increase control and default size of pdb traceback display Follow-Ups: Date: 2000-Aug-13 20:15 By: nowonder Comment: There is a detailed description in the patch. ------------------------------------------------------- Date: 2000-Aug-15 10:55 By: tim_one Comment: Reassigned to Guido in Jeremy's absence, cuz I never use pdb but know Guido has at least once . Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 12:36 By: gvanrossum Comment: I like the idea fine, but the command name "scaletb" sucks. Once a better name is coined Ken should get checkin permissions if he doesn't already have them, so he can check it in. (Isn't it ironic that Ken, who enjoys naming debates so much, came up with a sucky name? :-) Possibly a better name could include "control" (or an abbreviation) instead of "scale"? ------------------------------------------------------- Date: 2000-Aug-21 16:59 By: tim_one Comment: Ken, are you going to repsond to Guido's comments? And do you want developer privileges? ------------------------------------------------------- Date: 2000-Aug-27 09:57 By: klm Comment: Sorry about not responding more promptly. Actually, i got the email for guido's patch comment, and wasn't sure who to contact about getting checkin privileges, so was waiting for a moment to look around a bit to track that down and think things through. It so happens (1) i didn't get the moment until this morning (!), and (2) i must have missed tim's subsequent comment in my email box, because this is the first i saw of it. I do seem to have cvs ssh access, now, and have an alternate name to suggest. I'd be happy to arrive at some agreement on a name and then check in the changes. My current suggestion is 'limit_tb', with no abbreviation. I think this name is a lot more self-evident than scaletb, and a lot more specific than something like 'control_tb'. I can see objections to this, and am open to other suggestions. (If you insist on 'control_tb' or somesuch, fine.) Though this is Just A Name, there are some complications arriving at a name that fits well with the pdb commands. First, none of the other pdb command names are very long, so while "limit_traceback" would be most clear, it would be out of place. And cumbersome. Inclusion of an underscore in a pdb command name is, itself, unprecedented, but that helps avoid confusion with the "tb" of 'tbreak' (where "tb" => "temporary break"). Perhaps the "tb" collision is enough reason to spell out "traceback" - but incongruous and cumbersome, see above. Perhaps the most comprehensive solution would be to have a pdb "set" command, to set operational options, and then have a "set traceback_limit". That seems much too elaborate for a single option. It also seems like overkill even for several options, if there's no persistence to the pdb configuration - too much for settings that only last for a python session. While there may or may not be good reasons to have a persistent mechanism, i think the limit_tb command would be quite useful without it - people can enlarge the tb size once they see it's necessary, and reevoke it. So i'm for 'limit_tb', but open to other suggestions, willing to accept an edict if that means i can just check this in (or try another approach). (I think i'm set to do the checkin - i assume my addition to the python project developers roster means i have the privileges, and i've applied the patch to an ssh checkout, ready and sort of eager to try the checkin...) Ken ------------------------------------------------------- Date: 2000-Aug-31 14:36 By: jhylton Comment: Ken has disappeared ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470 From noreply@sourceforge.net Thu Aug 31 22:44:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 14:44:27 -0700 Subject: [Patches] [Patch #101346] print warning if exception occurs in GC Message-ID: <200008312144.OAA13685@delerium.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Open Summary: print warning if exception occurs in GC Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- Date: 2000-Aug-29 13:34 By: jhylton Comment: Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations. Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception. It seems dangerous to ignore one completely, but it's not clear how to recover. If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c ------------------------------------------------------- Date: 2000-Aug-30 06:40 By: marangoz Comment: Hm. The offending PyErr_Clear should definitely be removed. Not sure that surrounding the collection process with err fetch/restore is a good idea though. The collector could trigger __del__ methods which in turn could set exceptions. The GC code itself should be absolutely transparent w.r.t. exceptions and should propagate them if they're raised elsewhere. So, what needs to be done here is: - remove PyErrClear - use PySys_WriteStderr for debugging. The whole "output" stuff in gcmodule.c should be zapped, because it's a suboptimal and incomplete PySys_WriteStderr. The latter takes care to fetch/restore exceptions when printing the output. PS: now that this is assigned to me, can I upload another patch over this one for review? ------------------------------------------------------- Date: 2000-Aug-30 12:48 By: gvanrossum Comment: We agree with Vladimir. You can't upload a new version to this patch, but you can submit it as a new patch. We still want to check for spurious exceptions in the GC code and turn them into fatal errors, because they shouldn't happen and we want to make sure they don't. ------------------------------------------------------- Date: 2000-Aug-31 14:44 By: jhylton Comment: This is a paranoid safety measure. The GC should not raise any exceptions, and we don't think it does. But just in case, print a message to stderr if an exception does occur. Then raise a fatal error. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Thu Aug 31 23:01:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 15:01:40 -0700 Subject: [Patches] [Patch #101346] print warning if exception occurs in GC Message-ID: <200008312201.PAA20101@bush.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Open Summary: print warning if exception occurs in GC Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- Date: 2000-Aug-29 13:34 By: jhylton Comment: Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations. Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception. It seems dangerous to ignore one completely, but it's not clear how to recover. If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c ------------------------------------------------------- Date: 2000-Aug-30 06:40 By: marangoz Comment: Hm. The offending PyErr_Clear should definitely be removed. Not sure that surrounding the collection process with err fetch/restore is a good idea though. The collector could trigger __del__ methods which in turn could set exceptions. The GC code itself should be absolutely transparent w.r.t. exceptions and should propagate them if they're raised elsewhere. So, what needs to be done here is: - remove PyErrClear - use PySys_WriteStderr for debugging. The whole "output" stuff in gcmodule.c should be zapped, because it's a suboptimal and incomplete PySys_WriteStderr. The latter takes care to fetch/restore exceptions when printing the output. PS: now that this is assigned to me, can I upload another patch over this one for review? ------------------------------------------------------- Date: 2000-Aug-30 12:48 By: gvanrossum Comment: We agree with Vladimir. You can't upload a new version to this patch, but you can submit it as a new patch. We still want to check for spurious exceptions in the GC code and turn them into fatal errors, because they shouldn't happen and we want to make sure they don't. ------------------------------------------------------- Date: 2000-Aug-31 14:44 By: jhylton Comment: This is a paranoid safety measure. The GC should not raise any exceptions, and we don't think it does. But just in case, print a message to stderr if an exception does occur. Then raise a fatal error. ------------------------------------------------------- Date: 2000-Aug-31 15:01 By: bwarsaw Comment: Summary: - I'd call the factored out C function PyError_WriteUnraisable() - not sure gcmodule.c's `unhandled' needs to be a static, but perhaps you're worried about unexpected memory errors? - if you keep this variable, maybe call it gcerror. Other than that +1 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470