From noreply@sourceforge.net Wed Aug 1 13:59:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 05:59:10 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ü": 42}), unicode({"u": 23, u"ü": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ü"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Wed Aug 1 14:45:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 06:45:38 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ü": 42}), unicode({"u": 23, u"ü": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ü"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Wed Aug 1 14:49:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 06:49:07 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ü": 42}), unicode({"u": 23, u"ü": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ü"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ü") u'\xfc' *>>> unicode(str(u"ü")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ü")) u'\xfc' *>>> unicode(str(foo(u"ü"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Wed Aug 1 14:55:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 06:55:39 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ü": 42}), unicode({"u": 23, u"ü": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ü"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ü") u'\xfc' *>>> unicode(str(u"ü")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ü")) u'\xfc' *>>> unicode(str(foo(u"ü"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Wed Aug 1 17:16:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 09:16:51 -0700 Subject: [Patches] [ python-Patches-440292 ] Test cases for pyclbr.py Message-ID: Patches item #440292, was opened at 2001-07-10 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test cases for pyclbr.py Initial Comment: These test cases exercise the pyclbr module. They work by comparing the output of pyclbr to the results of module introspection for some of the largest modules in the Python distribution. They also skirt several limitations of pyclbr not mentioned in the BUGS section of pyclbr.py. For example, pyclbr.py does really bad in the presence of the string [ '"""' ]. (This keeps it from handling pydoc.py.) While writing these test cases, I also found a minor bug in pyclbr.py that would prevent it from finding functions (but not classes) declared in other modules. I'm also including a patch for this bug. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-08-01 09:16 Message: Logged In: YES user_id=499 Are you certain you tried the latest version of the test and the patch? I just tried the following (on a clean CVS tree): 1) Install test_pyclbr.py. (v3 given below; 153 lines) 2) ./python Lib/test/test_pyclbr.py GOT ERROR MESSAGE: test_easy (__main__.PyclbrTest) ... ok test_others (__main__.PyclbrTest) ... *** getstatus FAIL ====================================================================== FAIL: test_others (__main__.PyclbrTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_pyclbr.py", line 147, in test_others module=sys.modules[__name__]) File "Lib/test/test_pyclbr.py", line 99, in checkModule self.assertHaskey(dict, name, ignore) File "Lib/test/test_pyclbr.py", line 43, in assertHaskey self.failUnless(obj.has_key(key)) File "/home/nickm/src/python/dist/src/Lib/unittest.py", line 249, in failUnless if not expr: raise self.failureException, msg AssertionError 3) Patch pyclbr.py (patch v2 given below; 60 lines) 4) ./python Lib/test/test_pyclbr.py [ TESTS PASS ] Is it possible that you weren't running the most recent versions of each? Or do we have platform differences? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-22 19:45 Message: Logged In: YES user_id=3066 Sorry -- the new test still doesn't fail without the patch, so there's appearantly something missing in the test. The patch will definately make more sense if there's an example of what breaks without it. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-21 20:10 Message: Logged In: YES user_id=499 Well, there were two problems: 1) The test case didn't test the problem I thought it did. 2) The patch didn't fix the problem I thought I was testing! :) I'm uploading new versions of each. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-21 13:38 Message: Logged In: YES user_id=3066 The test case doesn't cover the bug fixed in the patch; it should fail if I try it without applying the patch. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:25 Message: Logged In: YES user_id=499 Updated to use unittest, and to be generally a bit more legible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:22 Message: Logged In: YES user_id=499 (More information on the bug: whereas pyclbr.py can notice imports of the format: "from module import class", it wasn't able to handle "from module import fn". Now it can.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 From noreply@sourceforge.net Wed Aug 1 17:42:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 09:42:00 -0700 Subject: [Patches] [ python-Patches-445770 ] Make calendar.py work forever. Message-ID: Patches item #445770, was opened at 2001-07-29 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph A Knapka (jknapka) Assigned to: Nobody/Anonymous (nobody) Summary: Make calendar.py work forever. Initial Comment: Changes to calendar.py (using a lot of code stolen from Pmw) to make it work for essentially any date, and handle Julian vs. Gregorian dating properly. julian=[-1|0|1] and papal=[0|1] arguments added to many functions, with appropriate defaults. If julian==1, Julian dating is used; if julian==0 Gregorian dating is used; if julian==-1 the code decides based on the date which dating system to use. If papal==1 the Gregorian reformation is applied in October 1582, the year of the edict; if papal==0 the reformation is applied in September 1752, the year in which Britain applied the change. julian defaults to -1 and papal to 0, so normally no one will need to care about them. Dependencies on the "time" module have been removed. Added functions: ymdtojdn(y,m,d) - convert year,month,day to Julian day number jdntoymd(jdn) - convert jdn to (year,month,day) tuple. jdntodow(jdn) - compute the day-of-week (0-6) of a Julian day number. Modified all existing code to use the new date and day-of-week code. So "prcal()" for example does the right thing. Testing: it gets the same answers as the "cal" program for a selection of months between 01/01 and 9999/12, including Oct 1582 and Sept 1752, when papal=0. ---------------------------------------------------------------------- >Comment By: Joseph A Knapka (jknapka) Date: 2001-08-01 09:42 Message: Logged In: YES user_id=118570 The current calendar.py code only works after 1900AD. I can think of a number of applications (library catalogs, or any other kind of historical record-keeping, for example) that need to represent dates before 1900. Furthermore, this code will work into the indefinite future, barring further Papal edicts, whereas the current calendar.py code is bound by the limitations of the "time" module. What's the point of keeping arbitrary limitations in the standard library? Essentially this code was written because I had an application that could use it, and I thought it might be a nice improvement to the existing calendar code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-29 15:29 Message: Logged In: YES user_id=6380 Apart from the novelty value, what's the point of supporting calendars hundreds of years back? Why does this belong in the standard library? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470 From noreply@sourceforge.net Wed Aug 1 20:02:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 12:02:12 -0700 Subject: [Patches] [ python-Patches-446899 ] Permit import of .pyw under Windows Message-ID: Patches item #446899, was opened at 2001-08-01 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Bolen (db3l) Assigned to: Nobody/Anonymous (nobody) Summary: Permit import of .pyw under Windows Initial Comment: Under windows, the extension .pyw is provided (in the default installation registry settings) to map scripts to pythonw.exe (no console) rather than python.exe. While scripts thus named are generally top level scripts, in some cases even top level scripts are imported by other code (particularly with test harnesses). However, Python itself does not recognize the pyw extension for import purposes. While an explicit compilation of the pyw file can work around this, it is error prone and manual - and subject to failure if multiple Python releases are in use. This patch adds .pyw as a possible source extension, on Windows only. (With slight modification, it could permit the extension on any platform if desired). The .pyw extension is secondary in the table to .py, so should both extensions exist (which is not a logical thing to do, but someone could do it), the import will find the .py prior to the .pyw. The attached patch is against the CVS tree main branch as of 8/1. -- David ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 From noreply@sourceforge.net Wed Aug 1 20:14:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 12:14:59 -0700 Subject: [Patches] [ python-Patches-446907 ] Allow jython to complete test_import Message-ID: Patches item #446907, was opened at 2001-08-01 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow jython to complete test_import Initial Comment: Adds cleanup of the jython .class files after this test. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 From noreply@sourceforge.net Wed Aug 1 20:20:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 12:20:47 -0700 Subject: [Patches] [ python-Patches-446912 ] Recursive object detection in xmlrpclib Message-ID: Patches item #446912, was opened at 2001-08-01 12:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446912&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Recursive object detection in xmlrpclib Initial Comment: The current implementation of xmlrpclib.Marshaller is a little inaccurate, in that it identifies as recursive any container object that has more than one reference to a given object. E.g. >>> import xmlrpclib >>> m = xmlrpclib.Marshaller() >>> a = (1,) >>> m.dumps((a, a)) Traceback (most recent call last): File "", line 1, in ? File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 393, in dumps self.__dump(v) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 406, in __dump f(self, value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 438, in dump_array self.__dump(v) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 406, in __dump f(self, value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 434, in dump_array self.container(value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 430, in container raise TypeError, "cannot marshal recursive data structures" TypeError: cannot marshal recursive data structures >>> The attached patch corrects this by first getting the reference graph of the object to be marshalled, and topsort'ing it to check that it's not cyclic. I'm not sure whether this is better behaviour than the current implementation's, as it could lead to massive duplication in the xml response that gets generated. However, at least the error message "cannot marshal recursive data" should be changed if the current implementation is left unchanged, as it misleadingly implies that the object it was passed is recursive. The attached testing script works with python from the CVS repository. A bunch of other tests are failing, but I don't think they're related to xmlrpc. HTH. Alex. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446912&group_id=5470 From noreply@sourceforge.net Wed Aug 1 20:25:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 12:25:55 -0700 Subject: [Patches] [ python-Patches-446899 ] Permit import of .pyw under Windows Message-ID: Patches item #446899, was opened at 2001-08-01 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None >Priority: 3 Submitted By: David Bolen (db3l) Assigned to: Nobody/Anonymous (nobody) Summary: Permit import of .pyw under Windows Initial Comment: Under windows, the extension .pyw is provided (in the default installation registry settings) to map scripts to pythonw.exe (no console) rather than python.exe. While scripts thus named are generally top level scripts, in some cases even top level scripts are imported by other code (particularly with test harnesses). However, Python itself does not recognize the pyw extension for import purposes. While an explicit compilation of the pyw file can work around this, it is error prone and manual - and subject to failure if multiple Python releases are in use. This patch adds .pyw as a possible source extension, on Windows only. (With slight modification, it could permit the extension on any platform if desired). The .pyw extension is secondary in the table to .py, so should both extensions exist (which is not a logical thing to do, but someone could do it), the import will find the .py prior to the .pyw. The attached patch is against the CVS tree main branch as of 8/1. -- David ---------------------------------------------------------------------- >Comment By: David Bolen (db3l) Date: 2001-08-01 12:25 Message: Logged In: YES user_id=53196 I can't seem to delete the first diff file (even though it's my own patch submission), but please use the later version (SF file id 9138). Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 From noreply@sourceforge.net Wed Aug 1 20:34:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 12:34:10 -0700 Subject: [Patches] [ python-Patches-446907 ] Allow jython to complete test_import Message-ID: Patches item #446907, was opened at 2001-08-01 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 >Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Tim Peters (tim_one) Summary: Allow jython to complete test_import Initial Comment: Adds cleanup of the jython .class files after this test. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-01 12:34 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 From noreply@sourceforge.net Wed Aug 1 20:40:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 12:40:11 -0700 Subject: [Patches] [ python-Patches-446907 ] Allow jython to complete test_import Message-ID: Patches item #446907, was opened at 2001-08-01 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Tim Peters (tim_one) Summary: Allow jython to complete test_import Initial Comment: Adds cleanup of the jython .class files after this test. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-01 12:40 Message: Logged In: YES user_id=31435 Checked in, but changed the code to if sys.platform.endswith('java'): . pyc = TESTFN + "$py.class" else: . pyc = TESTFN + ".pyc" for clarity. Please don't tell me that Jython doesn't implement .endswith() -- that would be too ironic to bear . Lib/test/test_import.py; new revision: 1.5 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-01 12:34 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 From noreply@sourceforge.net Wed Aug 1 21:18:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 13:18:42 -0700 Subject: [Patches] [ python-Patches-446907 ] Allow jython to complete test_import Message-ID: Patches item #446907, was opened at 2001-08-01 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 Category: library Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Tim Peters (tim_one) Summary: Allow jython to complete test_import Initial Comment: Adds cleanup of the jython .class files after this test. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-08-01 13:18 Message: Logged In: YES user_id=4201 Jython also have startswith() and I think that is what you wanted to use in this case. Jython 2.1a3 on java1.4.0-beta (JIT: null) Type "copyright", "credits" or "license" for more information. >>> import sys >>> sys.platform 'java1.4.0-beta' ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-01 12:40 Message: Logged In: YES user_id=31435 Checked in, but changed the code to if sys.platform.endswith('java'): . pyc = TESTFN + "$py.class" else: . pyc = TESTFN + ".pyc" for clarity. Please don't tell me that Jython doesn't implement .endswith() -- that would be too ironic to bear . Lib/test/test_import.py; new revision: 1.5 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-01 12:34 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 From noreply@sourceforge.net Wed Aug 1 21:24:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 13:24:31 -0700 Subject: [Patches] [ python-Patches-446907 ] Allow jython to complete test_import Message-ID: Patches item #446907, was opened at 2001-08-01 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 Category: library Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Tim Peters (tim_one) Summary: Allow jython to complete test_import Initial Comment: Adds cleanup of the jython .class files after this test. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-01 13:24 Message: Logged In: YES user_id=31435 Oops! Good point. Repaired in Lib/test/test_import.py; new revision: 1.6 ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-08-01 13:18 Message: Logged In: YES user_id=4201 Jython also have startswith() and I think that is what you wanted to use in this case. Jython 2.1a3 on java1.4.0-beta (JIT: null) Type "copyright", "credits" or "license" for more information. >>> import sys >>> sys.platform 'java1.4.0-beta' ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-01 12:40 Message: Logged In: YES user_id=31435 Checked in, but changed the code to if sys.platform.endswith('java'): . pyc = TESTFN + "$py.class" else: . pyc = TESTFN + ".pyc" for clarity. Please don't tell me that Jython doesn't implement .endswith() -- that would be too ironic to bear . Lib/test/test_import.py; new revision: 1.5 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-01 12:34 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 From noreply@sourceforge.net Wed Aug 1 23:19:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 15:19:32 -0700 Subject: [Patches] [ python-Patches-446912 ] Recursive object detection in xmlrpclib Message-ID: Patches item #446912, was opened at 2001-08-01 12:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446912&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) >Assigned to: Fredrik Lundh (effbot) Summary: Recursive object detection in xmlrpclib Initial Comment: The current implementation of xmlrpclib.Marshaller is a little inaccurate, in that it identifies as recursive any container object that has more than one reference to a given object. E.g. >>> import xmlrpclib >>> m = xmlrpclib.Marshaller() >>> a = (1,) >>> m.dumps((a, a)) Traceback (most recent call last): File "", line 1, in ? File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 393, in dumps self.__dump(v) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 406, in __dump f(self, value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 438, in dump_array self.__dump(v) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 406, in __dump f(self, value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 434, in dump_array self.container(value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 430, in container raise TypeError, "cannot marshal recursive data structures" TypeError: cannot marshal recursive data structures >>> The attached patch corrects this by first getting the reference graph of the object to be marshalled, and topsort'ing it to check that it's not cyclic. I'm not sure whether this is better behaviour than the current implementation's, as it could lead to massive duplication in the xml response that gets generated. However, at least the error message "cannot marshal recursive data" should be changed if the current implementation is left unchanged, as it misleadingly implies that the object it was passed is recursive. The attached testing script works with python from the CVS repository. A bunch of other tests are failing, but I don't think they're related to xmlrpc. HTH. Alex. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446912&group_id=5470 From noreply@sourceforge.net Wed Aug 1 23:20:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 15:20:10 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: M.-A. Lemburg (lemburg) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ü": 42}), unicode({"u": 23, u"ü": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ü"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ü") u'\xfc' *>>> unicode(str(u"ü")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ü")) u'\xfc' *>>> unicode(str(foo(u"ü"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Wed Aug 1 23:20:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 15:20:22 -0700 Subject: [Patches] [ python-Patches-445770 ] Make calendar.py work forever. Message-ID: Patches item #445770, was opened at 2001-07-29 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph A Knapka (jknapka) >Assigned to: Skip Montanaro (montanaro) Summary: Make calendar.py work forever. Initial Comment: Changes to calendar.py (using a lot of code stolen from Pmw) to make it work for essentially any date, and handle Julian vs. Gregorian dating properly. julian=[-1|0|1] and papal=[0|1] arguments added to many functions, with appropriate defaults. If julian==1, Julian dating is used; if julian==0 Gregorian dating is used; if julian==-1 the code decides based on the date which dating system to use. If papal==1 the Gregorian reformation is applied in October 1582, the year of the edict; if papal==0 the reformation is applied in September 1752, the year in which Britain applied the change. julian defaults to -1 and papal to 0, so normally no one will need to care about them. Dependencies on the "time" module have been removed. Added functions: ymdtojdn(y,m,d) - convert year,month,day to Julian day number jdntoymd(jdn) - convert jdn to (year,month,day) tuple. jdntodow(jdn) - compute the day-of-week (0-6) of a Julian day number. Modified all existing code to use the new date and day-of-week code. So "prcal()" for example does the right thing. Testing: it gets the same answers as the "cal" program for a selection of months between 01/01 and 9999/12, including Oct 1582 and Sept 1752, when papal=0. ---------------------------------------------------------------------- Comment By: Joseph A Knapka (jknapka) Date: 2001-08-01 09:42 Message: Logged In: YES user_id=118570 The current calendar.py code only works after 1900AD. I can think of a number of applications (library catalogs, or any other kind of historical record-keeping, for example) that need to represent dates before 1900. Furthermore, this code will work into the indefinite future, barring further Papal edicts, whereas the current calendar.py code is bound by the limitations of the "time" module. What's the point of keeping arbitrary limitations in the standard library? Essentially this code was written because I had an application that could use it, and I thought it might be a nice improvement to the existing calendar code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-29 15:29 Message: Logged In: YES user_id=6380 Apart from the novelty value, what's the point of supporting calendars hundreds of years back? Why does this belong in the standard library? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470 From noreply@sourceforge.net Wed Aug 1 23:21:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 15:21:17 -0700 Subject: [Patches] [ python-Patches-445744 ] PEP 250 Implementation Message-ID: Patches item #445744, was opened at 2001-07-29 12:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445744&group_id=5470 Category: distutils Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 250 Implementation Initial Comment: Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-08-01 15:21 Message: Logged In: YES user_id=31392 there's nothing here and no username associated ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445744&group_id=5470 From noreply@sourceforge.net Wed Aug 1 23:22:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 15:22:04 -0700 Subject: [Patches] [ python-Patches-445433 ] a getPart method for mimetools.Message Message-ID: Patches item #445433, was opened at 2001-07-27 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445433&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: Barry Warsaw (bwarsaw) Summary: a getPart method for mimetools.Message Initial Comment: This is a getPart method for the mimetools.Message class. The code comes from the roundup project (roundup.sf.net) ... it seems odd that mimetools.Message doesn't provide this out-of-the-box. Anyway, it's simple enough. There is a unit test for this code in the roundup test directory. class Message(mimetools.Message): def getPart(self) boundary = self.getparam('boundary') mid, end = '--'+boundary, '--'+boundary+'--' s = cStringIO.StringIO() while 1: line = self.fp.readline() if not line: break if line.strip() in (mid, end): break s.write(line) if not s.getvalue().strip(): return None s.seek(0) return Message(s) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445433&group_id=5470 From noreply@sourceforge.net Wed Aug 1 23:22:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 15:22:26 -0700 Subject: [Patches] [ python-Patches-445413 ] docs for Lib/difflib.py patch Message-ID: Patches item #445413, was opened at 2001-07-27 21:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445413&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) >Assigned to: Tim Peters (tim_one) Summary: docs for Lib/difflib.py patch Initial Comment: Docs for http://sourceforge.net/tracker/ index.php?func=detail&aid=445412&group_id= 5470&atid=305470 ; followup to patch 438331, "make ndiff.py into a library module" (http:// sourceforge.net/tracker/?func=detail&atid= 305470&aid=438331&group_id=5470). - Added docs for class Differ; functions ndiff(), restore(), IS_LINE_JUNK(), IS_CHARACTER_JUNK. - Rearranged the module overview part; hope you like it. - New subsection for each of Differ class & examples. - Minor edits to SequenceMatcher subsection to account for Tools/scripts/ndiff.py functionality extraction. - Since there are now two Examples subsections, renamed "difflib-examples" to "sequencematcher- examples". This patch is untested as I don't have LaTeX installed; hopefully there aren't (too many) errors. Apologies in advance if there are. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445413&group_id=5470 From noreply@sourceforge.net Wed Aug 1 23:22:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 15:22:26 -0700 Subject: [Patches] [ python-Patches-445412 ] extract ndiff functionality to difflib Message-ID: Patches item #445412, was opened at 2001-07-27 21:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445412&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) >Assigned to: Tim Peters (tim_one) Summary: extract ndiff functionality to difflib Initial Comment: This is a followup to patch 438331, "make ndiff.py into a library module" (http://sourceforge.net/ tracker/?func=detail&atid=305470&aid=438331& group_id=5470). Tools/scripts/ndiff.py: - Extracted useful functionality to Lib/difflib.py. - Moved most explanatory comments to difflib.py, some as docstrings, some as comments. Lib/difflib.py: - Functionality from ndiff.py now accessible from class Differ, and convenience functions ndiff() and restore(). Fully docstringed and doctested. - Rearranged SequenceMatcher docstrings: removed duplicates (class docs were in class AND module docstrings). - Bumped version up to 1.7.0 (if it matters). TeX documentation patch posted separately. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445412&group_id=5470 From noreply@sourceforge.net Wed Aug 1 23:23:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 15:23:06 -0700 Subject: [Patches] [ python-Patches-444359 ] Remove unused imports Message-ID: Patches item #444359, was opened at 2001-07-24 23:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: Remove unused imports Initial Comment: This patch removes a number of unneeded import statements from the standard library. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-08-01 15:23 Message: Logged In: YES user_id=31392 Can this be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-25 07:40 Message: Logged In: YES user_id=21627 Yes, I've checked them all; I still may have made a mistake. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-25 07:20 Message: Logged In: YES user_id=6380 Note: pychecker sometimes lies about unised imports, e.g. when the import is only used during module initialization. Did you check that these are really unneeded? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 From noreply@sourceforge.net Wed Aug 1 23:37:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 15:37:14 -0700 Subject: [Patches] [ python-Patches-444359 ] Remove unused imports Message-ID: Patches item #444359, was opened at 2001-07-24 23:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Remove unused imports Initial Comment: This patch removes a number of unneeded import statements from the standard library. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 15:37 Message: Logged In: YES user_id=6380 I think MvL still needs to check them in. Go ahead, Martin! ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-01 15:23 Message: Logged In: YES user_id=31392 Can this be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-25 07:40 Message: Logged In: YES user_id=21627 Yes, I've checked them all; I still may have made a mistake. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-25 07:20 Message: Logged In: YES user_id=6380 Note: pychecker sometimes lies about unised imports, e.g. when the import is only used during module initialization. Did you check that these are really unneeded? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 From noreply@sourceforge.net Thu Aug 2 07:09:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 23:09:57 -0700 Subject: [Patches] [ python-Patches-445762 ] Support --disable-unicode Message-ID: Patches item #445762, was opened at 2001-07-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support --disable-unicode Initial Comment: This patch implements the option --disable-unicode. In particular, it: - does not compile unicodeobject, unicodectype, _codecsmodule, and unicodedata if Unicode is disabled - checks for Py_Unicode in all places that use Unicode functions - disables unicode literals, the builtin functions, and the string encode and decode methods, - avoids Unicode literals in a few places in the libraries - adds the types.StringTypes list Most of the test suite passes with these changes. A number of tests fail, mostly because they use Unicode literals. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:09 Message: Logged In: YES user_id=21627 Updated patch after merger with descr_branch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:56 Message: Logged In: YES user_id=21627 Replaced patch, since it contained unrelated fragments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:48 Message: Logged In: YES user_id=21627 The new version of the patch implements all features that have been discussed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 07:39 Message: Logged In: YES user_id=38388 Ok, I see your point about the API references. About the PyString_Encode/Decode: on platforms without Unicode, the encoding should not have a default, so passing NULL as encoding should result in an error. I am not even sure, whether it should have a default on Unicode builds... probably not. Trimming down the _codecmodule.c to register and lookup is OK; there are a few codecs in 2.2 which don't use Unicode at all. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 07:30 Message: Logged In: YES user_id=21627 This patch already makes use of the assumption that PyUnicode_Check will always return 0. In all the remaining cases, the code will also call some function of the Unicode module, which will result in a compile time error since the functions are not declared anymore. Even if it was declared, it would probably result in a linker error since not all compilers will remove the entire code block. Only in cases where the if-block does not call any Unicode functions directly, that approach can be used. I can try to re-enable the _codecs module, although only register and lookup would remain. I cannot re-enable PyString_Decode/Encode, since they use PyUnicode_GetDefaultEncoding, which is not available since unicodeobject.c is not compiled. I will try to have the tokenizer generate more specific error messages. Support for "es", "et" is still there; they only work for strings, though, and they never call any codecs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 06:06 Message: Logged In: YES user_id=38388 Nice work, Martin ! Some comments: - I think that we could save some of the #ifdefs by simply assuming that an optimizing will not generate code for "if (0)" == "if (PyUnicode_Check(obj))"; this would make the code more readable - the _codecmodule.c should not be disabled by the configure option... codecs are useful for non-Unicode applications as well - the PyString_Encode/Decode() APIs should not be disabled for the same reason - the tokenizer/compiler should generate errors with an explicit message stating that the Python version was compiled without Unicode support - dito for the Unicode parser markers (I think that open() on Windows will fail without "es"... ?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 From noreply@sourceforge.net Thu Aug 2 07:31:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 23:31:17 -0700 Subject: [Patches] [ python-Patches-446899 ] Permit import of .pyw under Windows Message-ID: Patches item #446899, was opened at 2001-08-01 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Bolen (db3l) Assigned to: Nobody/Anonymous (nobody) Summary: Permit import of .pyw under Windows Initial Comment: Under windows, the extension .pyw is provided (in the default installation registry settings) to map scripts to pythonw.exe (no console) rather than python.exe. While scripts thus named are generally top level scripts, in some cases even top level scripts are imported by other code (particularly with test harnesses). However, Python itself does not recognize the pyw extension for import purposes. While an explicit compilation of the pyw file can work around this, it is error prone and manual - and subject to failure if multiple Python releases are in use. This patch adds .pyw as a possible source extension, on Windows only. (With slight modification, it could permit the extension on any platform if desired). The .pyw extension is secondary in the table to .py, so should both extensions exist (which is not a logical thing to do, but someone could do it), the import will find the .py prior to the .pyw. The attached patch is against the CVS tree main branch as of 8/1. -- David ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:31 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-01 12:25 Message: Logged In: YES user_id=53196 I can't seem to delete the first diff file (even though it's my own patch submission), but please use the later version (SF file id 9138). Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 From noreply@sourceforge.net Thu Aug 2 08:16:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 00:16:03 -0700 Subject: [Patches] [ python-Patches-444359 ] Remove unused imports Message-ID: Patches item #444359, was opened at 2001-07-24 23:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Remove unused imports Initial Comment: This patch removes a number of unneeded import statements from the standard library. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-02 00:16 Message: Logged In: YES user_id=21627 I have committed it now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 15:37 Message: Logged In: YES user_id=6380 I think MvL still needs to check them in. Go ahead, Martin! ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-01 15:23 Message: Logged In: YES user_id=31392 Can this be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-25 07:40 Message: Logged In: YES user_id=21627 Yes, I've checked them all; I still may have made a mistake. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-25 07:20 Message: Logged In: YES user_id=6380 Note: pychecker sometimes lies about unised imports, e.g. when the import is only used during module initialization. Did you check that these are really unneeded? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 From noreply@sourceforge.net Thu Aug 2 11:13:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 03:13:57 -0700 Subject: [Patches] [ python-Patches-445717 ] Detect UCS2/4 incompatibilities Message-ID: Patches item #445717, was opened at 2001-07-29 10:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445717&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Detect UCS2/4 incompatibilities Initial Comment: This patch introduces the LSB of PYTHON_API_VERSION to indicate whether we have a wide or a narrow build. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 03:13 Message: Logged In: YES user_id=38388 I've checked in a different approach using API name mangling after the discussion on python-dev. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:54 Message: Logged In: YES user_id=21627 This version of the patch implements a function PyUnicode_Wide in unicodemodule, and offers a helper macro PyUnicode_WidthCheck for use in extension modules. It also demonstrates its use in pyexpat. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 05:55 Message: Logged In: YES user_id=38388 Thanks for the patch. I would like to discuss this on python-dev first though... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445717&group_id=5470 From noreply@sourceforge.net Thu Aug 2 13:42:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 05:42:10 -0700 Subject: [Patches] [ python-Patches-446899 ] Permit import of .pyw under Windows Message-ID: Patches item #446899, was opened at 2001-08-01 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Bolen (db3l) Assigned to: Nobody/Anonymous (nobody) Summary: Permit import of .pyw under Windows Initial Comment: Under windows, the extension .pyw is provided (in the default installation registry settings) to map scripts to pythonw.exe (no console) rather than python.exe. While scripts thus named are generally top level scripts, in some cases even top level scripts are imported by other code (particularly with test harnesses). However, Python itself does not recognize the pyw extension for import purposes. While an explicit compilation of the pyw file can work around this, it is error prone and manual - and subject to failure if multiple Python releases are in use. This patch adds .pyw as a possible source extension, on Windows only. (With slight modification, it could permit the extension on any platform if desired). The .pyw extension is secondary in the table to .py, so should both extensions exist (which is not a logical thing to do, but someone could do it), the import will find the .py prior to the .pyw. The attached patch is against the CVS tree main branch as of 8/1. -- David ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-02 05:42 Message: Logged In: YES user_id=6380 I'm deleting the old patch for you. I approve, except that it seems it would break if the extension was ".Pyw" or ".pYw" etc. Sooner or later some bozo will run into this, so better fix it now (or prove it can't happen). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:31 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-01 12:25 Message: Logged In: YES user_id=53196 I can't seem to delete the first diff file (even though it's my own patch submission), but please use the later version (SF file id 9138). Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 From noreply@sourceforge.net Thu Aug 2 15:14:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 07:14:49 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Guido van Rossum (gvanrossum) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-02 07:14 Message: Logged In: YES user_id=6380 I've converted your unit test to the standard regression test suite and checked it in. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-23 06:30 Message: Logged In: YES user_id=6380 Alex, I've checked in my version of the patch. Would you mind converting the unittest to something that I can drop into the test package? ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-20 14:54 Message: Logged In: YES user_id=49686 Thanks for the corrections. For what it's worth, here's the unit test I have in my code for this change, along with something to catch the SyntaxError error, not that anyone else is likely to make that mistake:) Alex ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:47 Message: Logged In: YES user_id=6380 Notice that when the module fails with a SyntaxError, my patch does nothing. propagating the SyntaxError normally, while the original error raised a SystemError, masking the SyntaxError. Clearly that was wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:41 Message: Logged In: YES user_id=6380 I've added a streamlined version that deals with the error handling a bit differently, and conforms to the C style guide (PEP 7). ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-19 15:21 Message: Logged In: YES user_id=49686 Hi, I've looked for pertinent thread in the python-dev archive, but I've been unable to find one. I've searched for keywords "import.c", "import_submodule", "reload", and lastly "package import", although I might have missed a thread matching that, as there were over a hundred hits. Could you point me at a thread? Alex. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-17 02:00 Message: Logged In: YES user_id=34209 This is not a 2.0.1 bugfix candidate, or any bugfix candidate. Group changed. This is also a subject of occasional discussion on python-dev, see the archives ;P ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-16 12:42 Message: Logged In: YES user_id=49686 a) Sorry about the duplicate submission b) I attached the patch I'm proposing to it, but can't see it on this page. Here it is, just in case: Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.178 diff -c -r2.178 import.c *** Python/import.c 2001/07/05 03:47:53 2.178 --- Python/import.c 2001/07/16 19:04:05 *************** *** 1789,1795 **** import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m; /* Require: if mod == None: subname == fullname --- 1789,1795 ---- import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m, *resulting_module=NULL; /* Require: if mod == None: subname == fullname *************** *** 1829,1839 **** m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (m != NULL && mod != Py_None) { ! if (PyObject_SetAttrString(mod, subname, m) < 0) { ! Py_DECREF(m); ! m = NULL; ! } } } --- 1829,1864 ---- m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (mod != Py_None) { ! ! /* Irrespective of the success of this load, make a ! reference to it in the parent package module. */ ! ! /* ...a copy gets saved in the modules dictionary ! under the full name, so get a reference from ! there, if need be. */ ! if (m == NULL) { ! resulting_module = PyDict_GetItemString(modules, ! fullname); ! if (resulting_module == NULL) { ! ! /* ...failed to find the module under its full ! name; oops */ ! PyErr_Format(PyExc_SystemError, ! "Failed to create a sys.modules " \ ! "entry under %.200s", fullname); ! return NULL; ! } ! } else { ! resulting_module = m; ! } ! ! if (PyObject_SetAttrString(mod, subname, resulting_module) < 0) { ! if (m != NULL) { ! Py_DECREF(m); ! m = NULL; ! } ! } } } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Thu Aug 2 15:23:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 07:23:37 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Guido van Rossum (gvanrossum) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- >Comment By: Alex Coventry (alex_coventry) Date: 2001-08-02 07:23 Message: Logged In: YES user_id=49686 Hmm, I'm not sure how I missed your request for that. I'm sorry I didn't respond. Alex. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-02 07:14 Message: Logged In: YES user_id=6380 I've converted your unit test to the standard regression test suite and checked it in. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-23 06:30 Message: Logged In: YES user_id=6380 Alex, I've checked in my version of the patch. Would you mind converting the unittest to something that I can drop into the test package? ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-20 14:54 Message: Logged In: YES user_id=49686 Thanks for the corrections. For what it's worth, here's the unit test I have in my code for this change, along with something to catch the SyntaxError error, not that anyone else is likely to make that mistake:) Alex ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:47 Message: Logged In: YES user_id=6380 Notice that when the module fails with a SyntaxError, my patch does nothing. propagating the SyntaxError normally, while the original error raised a SystemError, masking the SyntaxError. Clearly that was wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:41 Message: Logged In: YES user_id=6380 I've added a streamlined version that deals with the error handling a bit differently, and conforms to the C style guide (PEP 7). ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-19 15:21 Message: Logged In: YES user_id=49686 Hi, I've looked for pertinent thread in the python-dev archive, but I've been unable to find one. I've searched for keywords "import.c", "import_submodule", "reload", and lastly "package import", although I might have missed a thread matching that, as there were over a hundred hits. Could you point me at a thread? Alex. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-17 02:00 Message: Logged In: YES user_id=34209 This is not a 2.0.1 bugfix candidate, or any bugfix candidate. Group changed. This is also a subject of occasional discussion on python-dev, see the archives ;P ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-16 12:42 Message: Logged In: YES user_id=49686 a) Sorry about the duplicate submission b) I attached the patch I'm proposing to it, but can't see it on this page. Here it is, just in case: Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.178 diff -c -r2.178 import.c *** Python/import.c 2001/07/05 03:47:53 2.178 --- Python/import.c 2001/07/16 19:04:05 *************** *** 1789,1795 **** import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m; /* Require: if mod == None: subname == fullname --- 1789,1795 ---- import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m, *resulting_module=NULL; /* Require: if mod == None: subname == fullname *************** *** 1829,1839 **** m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (m != NULL && mod != Py_None) { ! if (PyObject_SetAttrString(mod, subname, m) < 0) { ! Py_DECREF(m); ! m = NULL; ! } } } --- 1829,1864 ---- m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (mod != Py_None) { ! ! /* Irrespective of the success of this load, make a ! reference to it in the parent package module. */ ! ! /* ...a copy gets saved in the modules dictionary ! under the full name, so get a reference from ! there, if need be. */ ! if (m == NULL) { ! resulting_module = PyDict_GetItemString(modules, ! fullname); ! if (resulting_module == NULL) { ! ! /* ...failed to find the module under its full ! name; oops */ ! PyErr_Format(PyExc_SystemError, ! "Failed to create a sys.modules " \ ! "entry under %.200s", fullname); ! return NULL; ! } ! } else { ! resulting_module = m; ! } ! ! if (PyObject_SetAttrString(mod, subname, resulting_module) < 0) { ! if (m != NULL) { ! Py_DECREF(m); ! m = NULL; ! } ! } } } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Thu Aug 2 16:09:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 08:09:13 -0700 Subject: [Patches] [ python-Patches-446912 ] Recursive object detection in xmlrpclib Message-ID: Patches item #446912, was opened at 2001-08-01 12:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446912&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Fredrik Lundh (effbot) Summary: Recursive object detection in xmlrpclib Initial Comment: The current implementation of xmlrpclib.Marshaller is a little inaccurate, in that it identifies as recursive any container object that has more than one reference to a given object. E.g. >>> import xmlrpclib >>> m = xmlrpclib.Marshaller() >>> a = (1,) >>> m.dumps((a, a)) Traceback (most recent call last): File "", line 1, in ? File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 393, in dumps self.__dump(v) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 406, in __dump f(self, value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 438, in dump_array self.__dump(v) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 406, in __dump f(self, value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 434, in dump_array self.container(value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 430, in container raise TypeError, "cannot marshal recursive data structures" TypeError: cannot marshal recursive data structures >>> The attached patch corrects this by first getting the reference graph of the object to be marshalled, and topsort'ing it to check that it's not cyclic. I'm not sure whether this is better behaviour than the current implementation's, as it could lead to massive duplication in the xml response that gets generated. However, at least the error message "cannot marshal recursive data" should be changed if the current implementation is left unchanged, as it misleadingly implies that the object it was passed is recursive. The attached testing script works with python from the CVS repository. A bunch of other tests are failing, but I don't think they're related to xmlrpc. HTH. Alex. ---------------------------------------------------------------------- >Comment By: Alex Coventry (alex_coventry) Date: 2001-08-02 08:09 Message: Logged In: YES user_id=49686 There were errors in my code for iterating over the object to be marshalled. I'm deleting the old versions and submitting new patch and test files. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446912&group_id=5470 From noreply@sourceforge.net Thu Aug 2 16:12:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 08:12:12 -0700 Subject: [Patches] [ python-Patches-446912 ] Recursive object detection in xmlrpclib Message-ID: Patches item #446912, was opened at 2001-08-01 12:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446912&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Fredrik Lundh (effbot) Summary: Recursive object detection in xmlrpclib Initial Comment: The current implementation of xmlrpclib.Marshaller is a little inaccurate, in that it identifies as recursive any container object that has more than one reference to a given object. E.g. >>> import xmlrpclib >>> m = xmlrpclib.Marshaller() >>> a = (1,) >>> m.dumps((a, a)) Traceback (most recent call last): File "", line 1, in ? File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 393, in dumps self.__dump(v) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 406, in __dump f(self, value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 438, in dump_array self.__dump(v) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 406, in __dump f(self, value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 434, in dump_array self.container(value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 430, in container raise TypeError, "cannot marshal recursive data structures" TypeError: cannot marshal recursive data structures >>> The attached patch corrects this by first getting the reference graph of the object to be marshalled, and topsort'ing it to check that it's not cyclic. I'm not sure whether this is better behaviour than the current implementation's, as it could lead to massive duplication in the xml response that gets generated. However, at least the error message "cannot marshal recursive data" should be changed if the current implementation is left unchanged, as it misleadingly implies that the object it was passed is recursive. The attached testing script works with python from the CVS repository. A bunch of other tests are failing, but I don't think they're related to xmlrpc. HTH. Alex. ---------------------------------------------------------------------- >Comment By: Alex Coventry (alex_coventry) Date: 2001-08-02 08:12 Message: Logged In: YES user_id=49686 So I can't delete the old files, which makes sense. Please disregard them. ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-08-02 08:09 Message: Logged In: YES user_id=49686 There were errors in my code for iterating over the object to be marshalled. I'm deleting the old versions and submitting new patch and test files. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446912&group_id=5470 From noreply@sourceforge.net Thu Aug 2 17:29:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 09:29:03 -0700 Subject: [Patches] [ python-Patches-445762 ] Support --disable-unicode Message-ID: Patches item #445762, was opened at 2001-07-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support --disable-unicode Initial Comment: This patch implements the option --disable-unicode. In particular, it: - does not compile unicodeobject, unicodectype, _codecsmodule, and unicodedata if Unicode is disabled - checks for Py_Unicode in all places that use Unicode functions - disables unicode literals, the builtin functions, and the string encode and decode methods, - avoids Unicode literals in a few places in the libraries - adds the types.StringTypes list Most of the test suite passes with these changes. A number of tests fail, mostly because they use Unicode literals. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:29 Message: Logged In: YES user_id=38388 Uploaded a revised patch. The test suite still fails -- it would be nice if you could work this out; I don't want to check the patch in before the test suite runs through without failures. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:09 Message: Logged In: YES user_id=21627 Updated patch after merger with descr_branch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:56 Message: Logged In: YES user_id=21627 Replaced patch, since it contained unrelated fragments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:48 Message: Logged In: YES user_id=21627 The new version of the patch implements all features that have been discussed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 07:39 Message: Logged In: YES user_id=38388 Ok, I see your point about the API references. About the PyString_Encode/Decode: on platforms without Unicode, the encoding should not have a default, so passing NULL as encoding should result in an error. I am not even sure, whether it should have a default on Unicode builds... probably not. Trimming down the _codecmodule.c to register and lookup is OK; there are a few codecs in 2.2 which don't use Unicode at all. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 07:30 Message: Logged In: YES user_id=21627 This patch already makes use of the assumption that PyUnicode_Check will always return 0. In all the remaining cases, the code will also call some function of the Unicode module, which will result in a compile time error since the functions are not declared anymore. Even if it was declared, it would probably result in a linker error since not all compilers will remove the entire code block. Only in cases where the if-block does not call any Unicode functions directly, that approach can be used. I can try to re-enable the _codecs module, although only register and lookup would remain. I cannot re-enable PyString_Decode/Encode, since they use PyUnicode_GetDefaultEncoding, which is not available since unicodeobject.c is not compiled. I will try to have the tokenizer generate more specific error messages. Support for "es", "et" is still there; they only work for strings, though, and they never call any codecs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 06:06 Message: Logged In: YES user_id=38388 Nice work, Martin ! Some comments: - I think that we could save some of the #ifdefs by simply assuming that an optimizing will not generate code for "if (0)" == "if (PyUnicode_Check(obj))"; this would make the code more readable - the _codecmodule.c should not be disabled by the configure option... codecs are useful for non-Unicode applications as well - the PyString_Encode/Decode() APIs should not be disabled for the same reason - the tokenizer/compiler should generate errors with an explicit message stating that the Python version was compiled without Unicode support - dito for the Unicode parser markers (I think that open() on Windows will fail without "es"... ?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 From noreply@sourceforge.net Thu Aug 2 17:39:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 09:39:32 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: M.-A. Lemburg (lemburg) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:39 Message: Logged In: YES user_id=38388 Tim, please resubmit the patch -- it no longer applies to the current CVS tree. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From zdanie@europe.com Thu Aug 2 15:47:41 2001 From: zdanie@europe.com (=?windows-1251?Q?=CF=EE=F0=F2=EE=E2=E0=FF,_19?=) Date: Thu, 2 Aug 2001 18:47:41 +0400 Subject: [Patches] =?windows-1251?Q?=CF=F0=EE=E4=E0=E5=F2=F1=FF_=E0=E4=EC=E8=ED=E8=F1=F2=F0=E0=F2=E8=E2=ED=EE=E5_=E7=E4=E0=ED=E8=E5_=E2_=CA=E0=E7=E0=ED=E8?= Message-ID: <211312001842144741216@dr.com> Çäðàâñòâóéòå! Íàøå ïî÷òåíèå. Ïðåäëàãàåì ïðèîáðåñòè â ñîáñòâåííîñòü àäìèíèñòðàòèâíîå çäàíèå â Êàçàíè (Òàòàðñòàí, Ðîññèÿ): - Îáùàÿ ïëîùàäü 910 êâ. ì; - 2 ýòàæà; - Áîëüøîå êîëè÷åñòâî ïîìåùåíèé îò 7 äî 200 êâ.ì; - Ñîáñòâåííàÿ òåððèòîðèÿ - çåìåëüíûé ó÷àñòîê 0,101 Ãà. Çäàíèå - áûâøàÿ ñòîëîâàÿ ðå÷íîãî ïîðòà. Èìååò âûãîäíîå ðàñïîëîæåíèå: - íàïðîòèâ çäàíèÿ - âòîðîé ïî âåëè÷èíå îïòîâûé ïðîäóêòîâûé ãîðîäñêîé ðûíîê; - óäîáíûå ïîäúåçäíûå ïóòè; - áëèçêî ê öåíòðó ãîðîäà - 5 ìèí. åçäû; - áëèçêî ê æ/ä âîêçàëó - 5 ìèí. åçäû; - ðÿäîì ðå÷íîé ïîðò; - ðÿäîì æ/ä ïóòè. Çäàíèå èäåàëüíî ïîäõîäèò äëÿ ðàçìåùåíèÿ îôèñà ïðåäñòàâèòåëüñòâà Âàøåé êîìïàíèè â Òàòàðñòàíå èëè Ïîâîëæüå. Âîçìîæíà êîìïîíîâêà "îôèñ/ñêëàä". Âñå êîììóíèêàöèè ïîäâåäåíû. Çäàíèå òðåáóåò ðåìîíòà (ïîëíàÿ âíóòðåííÿÿ îòäåëêà, âêëþ÷àÿ íîâûå îêîííûå è äâåðíûå áëîêè). Çäàíèå íàõîäèòñÿ â ÷àñòíîé ñîáñòâåííîñòè. Çåìëÿ - â áåññðî÷íîì ïîëüçîâàíèè. Öåíà çäàíèÿ - ÁÎËÅÅ ×ÅÌ ÄÎÑÒÓÏÍÀ. Åñëè âû çàèíòåðåñîâàíû â ïîëó÷åíèè îò íàñ áîëåå ïîäðîáíîé èíôîðìàöèè î äàííîì îáúåêòå, îòïðàâüòå ïóñòîå ïèñüìî ïî àäðåñó: zdanie@europe.com. Ïðè ýòîì â "Òåìå" ñîîáùåíèÿ ÎÁßÇÀÒÅËÜÍÎ íàïèøèòå: "Ïðèøëèòå ïîäðîáíóþ èíôîðìàöèþ". From noreply@sourceforge.net Thu Aug 2 20:16:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 12:16:47 -0700 Subject: [Patches] [ python-Patches-446899 ] Permit import of .pyw under Windows Message-ID: Patches item #446899, was opened at 2001-08-01 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Bolen (db3l) Assigned to: Nobody/Anonymous (nobody) Summary: Permit import of .pyw under Windows Initial Comment: Under windows, the extension .pyw is provided (in the default installation registry settings) to map scripts to pythonw.exe (no console) rather than python.exe. While scripts thus named are generally top level scripts, in some cases even top level scripts are imported by other code (particularly with test harnesses). However, Python itself does not recognize the pyw extension for import purposes. While an explicit compilation of the pyw file can work around this, it is error prone and manual - and subject to failure if multiple Python releases are in use. This patch adds .pyw as a possible source extension, on Windows only. (With slight modification, it could permit the extension on any platform if desired). The .pyw extension is secondary in the table to .py, so should both extensions exist (which is not a logical thing to do, but someone could do it), the import will find the .py prior to the .pyw. The attached patch is against the CVS tree main branch as of 8/1. -- David ---------------------------------------------------------------------- >Comment By: David Bolen (db3l) Date: 2001-08-02 12:16 Message: Logged In: YES user_id=53196 It appears that I was being too conservative (I put in the extra PYW case check thinking of a FAT filesystem). After studying it further (and running some tests), make_compiled_pathname will always receive a path whose extension matches the case of that in _PyImport_StandardFiletab since it is Python itself that adds the extension (in find_module) that adds the extension when testing for the file. I have attached a simplified patch to reflect that the case must simply be consistent between _PyImport_StandardFiletab and the code in make_compiled_pathname. The code was tested on an NTFS filesystem using all lower, mixed case, and all upper. -- David ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-02 05:42 Message: Logged In: YES user_id=6380 I'm deleting the old patch for you. I approve, except that it seems it would break if the extension was ".Pyw" or ".pYw" etc. Sooner or later some bozo will run into this, so better fix it now (or prove it can't happen). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:31 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-01 12:25 Message: Logged In: YES user_id=53196 I can't seem to delete the first diff file (even though it's my own patch submission), but please use the later version (SF file id 9138). Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 From noreply@sourceforge.net Thu Aug 2 20:47:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 12:47:02 -0700 Subject: [Patches] [ python-Patches-446899 ] Permit import of .pyw under Windows Message-ID: Patches item #446899, was opened at 2001-08-01 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Bolen (db3l) >Assigned to: Tim Peters (tim_one) Summary: Permit import of .pyw under Windows Initial Comment: Under windows, the extension .pyw is provided (in the default installation registry settings) to map scripts to pythonw.exe (no console) rather than python.exe. While scripts thus named are generally top level scripts, in some cases even top level scripts are imported by other code (particularly with test harnesses). However, Python itself does not recognize the pyw extension for import purposes. While an explicit compilation of the pyw file can work around this, it is error prone and manual - and subject to failure if multiple Python releases are in use. This patch adds .pyw as a possible source extension, on Windows only. (With slight modification, it could permit the extension on any platform if desired). The .pyw extension is secondary in the table to .py, so should both extensions exist (which is not a logical thing to do, but someone could do it), the import will find the .py prior to the .pyw. The attached patch is against the CVS tree main branch as of 8/1. -- David ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-02 12:16 Message: Logged In: YES user_id=53196 It appears that I was being too conservative (I put in the extra PYW case check thinking of a FAT filesystem). After studying it further (and running some tests), make_compiled_pathname will always receive a path whose extension matches the case of that in _PyImport_StandardFiletab since it is Python itself that adds the extension (in find_module) that adds the extension when testing for the file. I have attached a simplified patch to reflect that the case must simply be consistent between _PyImport_StandardFiletab and the code in make_compiled_pathname. The code was tested on an NTFS filesystem using all lower, mixed case, and all upper. -- David ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-02 05:42 Message: Logged In: YES user_id=6380 I'm deleting the old patch for you. I approve, except that it seems it would break if the extension was ".Pyw" or ".pYw" etc. Sooner or later some bozo will run into this, so better fix it now (or prove it can't happen). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:31 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-01 12:25 Message: Logged In: YES user_id=53196 I can't seem to delete the first diff file (even though it's my own patch submission), but please use the later version (SF file id 9138). Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 From noreply@sourceforge.net Thu Aug 2 20:48:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 12:48:00 -0700 Subject: [Patches] [ python-Patches-446899 ] Permit import of .pyw under Windows Message-ID: Patches item #446899, was opened at 2001-08-01 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Bolen (db3l) Assigned to: Tim Peters (tim_one) Summary: Permit import of .pyw under Windows Initial Comment: Under windows, the extension .pyw is provided (in the default installation registry settings) to map scripts to pythonw.exe (no console) rather than python.exe. While scripts thus named are generally top level scripts, in some cases even top level scripts are imported by other code (particularly with test harnesses). However, Python itself does not recognize the pyw extension for import purposes. While an explicit compilation of the pyw file can work around this, it is error prone and manual - and subject to failure if multiple Python releases are in use. This patch adds .pyw as a possible source extension, on Windows only. (With slight modification, it could permit the extension on any platform if desired). The .pyw extension is secondary in the table to .py, so should both extensions exist (which is not a logical thing to do, but someone could do it), the import will find the .py prior to the .pyw. The attached patch is against the CVS tree main branch as of 8/1. -- David ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-02 12:48 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-02 12:16 Message: Logged In: YES user_id=53196 It appears that I was being too conservative (I put in the extra PYW case check thinking of a FAT filesystem). After studying it further (and running some tests), make_compiled_pathname will always receive a path whose extension matches the case of that in _PyImport_StandardFiletab since it is Python itself that adds the extension (in find_module) that adds the extension when testing for the file. I have attached a simplified patch to reflect that the case must simply be consistent between _PyImport_StandardFiletab and the code in make_compiled_pathname. The code was tested on an NTFS filesystem using all lower, mixed case, and all upper. -- David ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-02 05:42 Message: Logged In: YES user_id=6380 I'm deleting the old patch for you. I approve, except that it seems it would break if the extension was ".Pyw" or ".pYw" etc. Sooner or later some bozo will run into this, so better fix it now (or prove it can't happen). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:31 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-01 12:25 Message: Logged In: YES user_id=53196 I can't seem to delete the first diff file (even though it's my own patch submission), but please use the later version (SF file id 9138). Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 From noreply@sourceforge.net Fri Aug 3 06:58:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 22:58:20 -0700 Subject: [Patches] [ python-Patches-446907 ] Allow jython to complete test_import Message-ID: Patches item #446907, was opened at 2001-08-01 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 Category: library Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Tim Peters (tim_one) Summary: Allow jython to complete test_import Initial Comment: Adds cleanup of the jython .class files after this test. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-02 22:58 Message: Logged In: YES user_id=31435 Should have closed this before. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-01 13:24 Message: Logged In: YES user_id=31435 Oops! Good point. Repaired in Lib/test/test_import.py; new revision: 1.6 ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-08-01 13:18 Message: Logged In: YES user_id=4201 Jython also have startswith() and I think that is what you wanted to use in this case. Jython 2.1a3 on java1.4.0-beta (JIT: null) Type "copyright", "credits" or "license" for more information. >>> import sys >>> sys.platform 'java1.4.0-beta' ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-01 12:40 Message: Logged In: YES user_id=31435 Checked in, but changed the code to if sys.platform.endswith('java'): . pyc = TESTFN + "$py.class" else: . pyc = TESTFN + ".pyc" for clarity. Please don't tell me that Jython doesn't implement .endswith() -- that would be too ironic to bear . Lib/test/test_import.py; new revision: 1.5 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-01 12:34 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446907&group_id=5470 From noreply@sourceforge.net Fri Aug 3 06:59:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 22:59:35 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-02 22:59 Message: Logged In: YES user_id=31435 Marked Out of Date as per MAL's remark, and assigned back to me. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:39 Message: Logged In: YES user_id=38388 Tim, please resubmit the patch -- it no longer applies to the current CVS tree. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From penisgrowthnow@uep.com Fri Aug 3 07:04:09 2001 From: penisgrowthnow@uep.com (penisgrowthnow@uep.com) Date: Fri, 3 Aug 2001 01:04:09 -0500 Subject: [Patches] Increase Penis size 1-4 inches! Message-ID: <200108030604.BAA07172@castor.host4u.net> Below is the result of your feedback form. It was submitted by (penisgrowthnow@uep.com) on Friday, August 3, 2001 at 01:04:09 --------------------------------------------------------------------------- : Hey guys, did you know that you can ENLARGE your penis in both length and width using nothing but a few simple exercises and techniques? All it takes is a few minutes a day and the results are permanent! Sounds hard to believe, doesn't it? Well, believe it or not it really does work! And guess what? There is no pumps to pump, pills to swallow or needles to be shot for painful operations. Our program will help you add inches to your penis 100% NATURALLY!

click here to do it! --------------------------------------------------------------------------- From noreply@sourceforge.net Fri Aug 3 08:45:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Aug 2001 00:45:52 -0700 Subject: [Patches] [ python-Patches-445762 ] Support --disable-unicode Message-ID: Patches item #445762, was opened at 2001-07-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support --disable-unicode Initial Comment: This patch implements the option --disable-unicode. In particular, it: - does not compile unicodeobject, unicodectype, _codecsmodule, and unicodedata if Unicode is disabled - checks for Py_Unicode in all places that use Unicode functions - disables unicode literals, the builtin functions, and the string encode and decode methods, - avoids Unicode literals in a few places in the libraries - adds the types.StringTypes list Most of the test suite passes with these changes. A number of tests fail, mostly because they use Unicode literals. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-03 00:45 Message: Logged In: YES user_id=21627 I've added an additional test.patch file, which only records the changes to Lib/test. With this patch, I get the following failures: test_grammar test___all__ test_charmapcodec test_codecs test_gettext test_minidom test_pyexpat test_sax test_string test_ucn test_unicode test_unicodedata test_urllib test_zipfile1 I don't think this list cannot be reduced much further without seriously impacting the strength of the test suite. To reduce the number of failures to this list, I also had to modify pickle.py to not use Unicode literals anymore. I'm not sure whether this is a good idea, as it impacts performance; the pickle.patch is attached separately. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:29 Message: Logged In: YES user_id=38388 Uploaded a revised patch. The test suite still fails -- it would be nice if you could work this out; I don't want to check the patch in before the test suite runs through without failures. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:09 Message: Logged In: YES user_id=21627 Updated patch after merger with descr_branch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:56 Message: Logged In: YES user_id=21627 Replaced patch, since it contained unrelated fragments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:48 Message: Logged In: YES user_id=21627 The new version of the patch implements all features that have been discussed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 07:39 Message: Logged In: YES user_id=38388 Ok, I see your point about the API references. About the PyString_Encode/Decode: on platforms without Unicode, the encoding should not have a default, so passing NULL as encoding should result in an error. I am not even sure, whether it should have a default on Unicode builds... probably not. Trimming down the _codecmodule.c to register and lookup is OK; there are a few codecs in 2.2 which don't use Unicode at all. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 07:30 Message: Logged In: YES user_id=21627 This patch already makes use of the assumption that PyUnicode_Check will always return 0. In all the remaining cases, the code will also call some function of the Unicode module, which will result in a compile time error since the functions are not declared anymore. Even if it was declared, it would probably result in a linker error since not all compilers will remove the entire code block. Only in cases where the if-block does not call any Unicode functions directly, that approach can be used. I can try to re-enable the _codecs module, although only register and lookup would remain. I cannot re-enable PyString_Decode/Encode, since they use PyUnicode_GetDefaultEncoding, which is not available since unicodeobject.c is not compiled. I will try to have the tokenizer generate more specific error messages. Support for "es", "et" is still there; they only work for strings, though, and they never call any codecs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 06:06 Message: Logged In: YES user_id=38388 Nice work, Martin ! Some comments: - I think that we could save some of the #ifdefs by simply assuming that an optimizing will not generate code for "if (0)" == "if (PyUnicode_Check(obj))"; this would make the code more readable - the _codecmodule.c should not be disabled by the configure option... codecs are useful for non-Unicode applications as well - the PyString_Encode/Decode() APIs should not be disabled for the same reason - the tokenizer/compiler should generate errors with an explicit message stating that the Python version was compiled without Unicode support - dito for the Unicode parser markers (I think that open() on Windows will fail without "es"... ?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 From noreply@sourceforge.net Fri Aug 3 16:18:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Aug 2001 08:18:51 -0700 Subject: [Patches] [ python-Patches-447476 ] Fixes to setup.py for including OSX modules Message-ID: Patches item #447476, was opened at 2001-08-03 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=447476&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes to setup.py for including OSX modules Initial Comment: I'm submitting this here in stead of checking it in directly so that it gets some peer review (i.e. I can't check that it doesn't break anything on Windows). These fixes to setup.py replace moddir and incdir by moddirlist and incdirlist, lists of source and include directories that are searched for modules. This is needed because the Mac modules and include files live in the Mac subtree. In addition (and that's actually what the mod is all about) on OSX we build all the Mac extension modules. I'd be grateful if this fix could make it into 2.2a2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=447476&group_id=5470 From noreply@sourceforge.net Fri Aug 3 18:57:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Aug 2001 10:57:02 -0700 Subject: [Patches] [ python-Patches-447476 ] Fixes to setup.py for including OSX modules Message-ID: Patches item #447476, was opened at 2001-08-03 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=447476&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes to setup.py for including OSX modules Initial Comment: I'm submitting this here in stead of checking it in directly so that it gets some peer review (i.e. I can't check that it doesn't break anything on Windows). These fixes to setup.py replace moddir and incdir by moddirlist and incdirlist, lists of source and include directories that are searched for modules. This is needed because the Mac modules and include files live in the Mac subtree. In addition (and that's actually what the mod is all about) on OSX we build all the Mac extension modules. I'd be grateful if this fix could make it into 2.2a2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-03 10:57 Message: Logged In: YES user_id=31435 No need to worry about Windows -- we don't use setup.py there at all (at least not yet). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=447476&group_id=5470 From noreply@sourceforge.net Fri Aug 3 20:36:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Aug 2001 12:36:33 -0700 Subject: [Patches] [ python-Patches-447476 ] Fixes to setup.py for including OSX modules Message-ID: Patches item #447476, was opened at 2001-08-03 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=447476&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: Fixes to setup.py for including OSX modules Initial Comment: I'm submitting this here in stead of checking it in directly so that it gets some peer review (i.e. I can't check that it doesn't break anything on Windows). These fixes to setup.py replace moddir and incdir by moddirlist and incdirlist, lists of source and include directories that are searched for modules. This is needed because the Mac modules and include files live in the Mac subtree. In addition (and that's actually what the mod is all about) on OSX we build all the Mac extension modules. I'd be grateful if this fix could make it into 2.2a2. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-03 12:36 Message: Logged In: YES user_id=6380 Works fine for me on Linux. There are a few long lines; fix these and check it in, I'd say. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-03 10:57 Message: Logged In: YES user_id=31435 No need to worry about Windows -- we don't use setup.py there at all (at least not yet). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=447476&group_id=5470 From noreply@sourceforge.net Sat Aug 4 00:56:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Aug 2001 16:56:19 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: M.-A. Lemburg (lemburg) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-03 16:56 Message: Logged In: YES user_id=31435 New patch attached, and back to MAL. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 22:59 Message: Logged In: YES user_id=31435 Marked Out of Date as per MAL's remark, and assigned back to me. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:39 Message: Logged In: YES user_id=38388 Tim, please resubmit the patch -- it no longer applies to the current CVS tree. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Sat Aug 4 08:33:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 Aug 2001 00:33:03 -0700 Subject: [Patches] [ python-Patches-446899 ] Permit import of .pyw under Windows Message-ID: Patches item #446899, was opened at 2001-08-01 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Bolen (db3l) Assigned to: Tim Peters (tim_one) Summary: Permit import of .pyw under Windows Initial Comment: Under windows, the extension .pyw is provided (in the default installation registry settings) to map scripts to pythonw.exe (no console) rather than python.exe. While scripts thus named are generally top level scripts, in some cases even top level scripts are imported by other code (particularly with test harnesses). However, Python itself does not recognize the pyw extension for import purposes. While an explicit compilation of the pyw file can work around this, it is error prone and manual - and subject to failure if multiple Python releases are in use. This patch adds .pyw as a possible source extension, on Windows only. (With slight modification, it could permit the extension on any platform if desired). The .pyw extension is secondary in the table to .py, so should both extensions exist (which is not a logical thing to do, but someone could do it), the import will find the .py prior to the .pyw. The attached patch is against the CVS tree main branch as of 8/1. -- David ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-04 00:33 Message: Logged In: YES user_id=31435 Just deleting the 2nd patch in the sequence. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 12:48 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-02 12:16 Message: Logged In: YES user_id=53196 It appears that I was being too conservative (I put in the extra PYW case check thinking of a FAT filesystem). After studying it further (and running some tests), make_compiled_pathname will always receive a path whose extension matches the case of that in _PyImport_StandardFiletab since it is Python itself that adds the extension (in find_module) that adds the extension when testing for the file. I have attached a simplified patch to reflect that the case must simply be consistent between _PyImport_StandardFiletab and the code in make_compiled_pathname. The code was tested on an NTFS filesystem using all lower, mixed case, and all upper. -- David ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-02 05:42 Message: Logged In: YES user_id=6380 I'm deleting the old patch for you. I approve, except that it seems it would break if the extension was ".Pyw" or ".pYw" etc. Sooner or later some bozo will run into this, so better fix it now (or prove it can't happen). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:31 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-01 12:25 Message: Logged In: YES user_id=53196 I can't seem to delete the first diff file (even though it's my own patch submission), but please use the later version (SF file id 9138). Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 From noreply@sourceforge.net Sat Aug 4 09:14:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 Aug 2001 01:14:40 -0700 Subject: [Patches] [ python-Patches-446899 ] Permit import of .pyw under Windows Message-ID: Patches item #446899, was opened at 2001-08-01 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted >Priority: 5 Submitted By: David Bolen (db3l) Assigned to: Tim Peters (tim_one) Summary: Permit import of .pyw under Windows Initial Comment: Under windows, the extension .pyw is provided (in the default installation registry settings) to map scripts to pythonw.exe (no console) rather than python.exe. While scripts thus named are generally top level scripts, in some cases even top level scripts are imported by other code (particularly with test harnesses). However, Python itself does not recognize the pyw extension for import purposes. While an explicit compilation of the pyw file can work around this, it is error prone and manual - and subject to failure if multiple Python releases are in use. This patch adds .pyw as a possible source extension, on Windows only. (With slight modification, it could permit the extension on any platform if desired). The .pyw extension is secondary in the table to .py, so should both extensions exist (which is not a logical thing to do, but someone could do it), the import will find the .py prior to the .pyw. The attached patch is against the CVS tree main branch as of 8/1. -- David ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-04 01:14 Message: Logged In: YES user_id=31435 Accepted and Closed. Applied a derived patch to: Lib/test/test_import.py, new revision: 1.7 Misc/ACKS, new revision: 1.101 Misc/NEWS, new revision: 1.201 Python/import.c, new revision: 2.182 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-04 00:33 Message: Logged In: YES user_id=31435 Just deleting the 2nd patch in the sequence. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 12:48 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-02 12:16 Message: Logged In: YES user_id=53196 It appears that I was being too conservative (I put in the extra PYW case check thinking of a FAT filesystem). After studying it further (and running some tests), make_compiled_pathname will always receive a path whose extension matches the case of that in _PyImport_StandardFiletab since it is Python itself that adds the extension (in find_module) that adds the extension when testing for the file. I have attached a simplified patch to reflect that the case must simply be consistent between _PyImport_StandardFiletab and the code in make_compiled_pathname. The code was tested on an NTFS filesystem using all lower, mixed case, and all upper. -- David ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-02 05:42 Message: Logged In: YES user_id=6380 I'm deleting the old patch for you. I approve, except that it seems it would break if the extension was ".Pyw" or ".pYw" etc. Sooner or later some bozo will run into this, so better fix it now (or prove it can't happen). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:31 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2001-08-01 12:25 Message: Logged In: YES user_id=53196 I can't seem to delete the first diff file (even though it's my own patch submission), but please use the later version (SF file id 9138). Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446899&group_id=5470 From noreply@sourceforge.net Sun Aug 5 01:08:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 Aug 2001 17:08:05 -0700 Subject: [Patches] [ python-Patches-448038 ] a move function for shutil.py Message-ID: Patches item #448038, was opened at 2001-08-04 17:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448038&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: William McVey (wamcvey) Assigned to: Nobody/Anonymous (nobody) Summary: a move function for shutil.py Initial Comment: Although shutil.py has some nice copy functions but no real equivalent of mv(1). This is a very simple implimentation (as in not a whole lot of stuff has been implimented) but it's functional. Simply calls rename, and if that fails tries to copy and unlink. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448038&group_id=5470 From noreply@sourceforge.net Sun Aug 5 16:38:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 08:38:51 -0700 Subject: [Patches] [ python-Patches-448171 ] Allow jython to complete test_exceptions Message-ID: Patches item #448171, was opened at 2001-08-05 08:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448171&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow jython to complete test_exceptions Initial Comment: The behavior of continue in a try clause is a known difference between CPython and Jython. This patch will jython to skip that test. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448171&group_id=5470 From noreply@sourceforge.net Sun Aug 5 18:52:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 10:52:26 -0700 Subject: [Patches] [ python-Patches-448194 ] Debuging negative reference counts Message-ID: Patches item #448194, was opened at 2001-08-05 10:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448194&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: Debuging negative reference counts Initial Comment: I'm giving the patch below as a 'time-saver' for extension writters suffering crashes (memory-related in most cases). The patch is activated only under compilation with the Py_DEBUG flag (hint: production code is unchanged, this is only of concerns to Py_DEBUG-aware developpers). The new behavior is as follows (under Py_DEBUG): After decrementing: if 0 < do_nothing; elseif 0 == refcount release_memory; else print_warning; #instead of: if 0 < do_nothing else release-memory; In effect, in the present python code, releasing a memory segment already released (negative ref count will at best crash the application, or further corrupts it). With the patch, in the situations (the very large majority of cases) where the memory has not already been overwritten with a positive value, the negative ref count is recognized, and an appropriate action is taken (currently: print the Py_DECREF location to stderr, instead of releasing [erroneously] the memory segment). Note that the only penalty to this is some small code bloat under Py_DEBUG compilation. The feature has been tested on two project, and demonstrated to directly pinpoint almost directly to the culprit in situations where a Py_INCREF has been missing somewhere (as an alternate to teh traditional application crash further down the application :((( Frederic Giacometti diff -c -r1.1.1.1 object.h *** Include/object.h 2001/05/27 15:36:16 1.1.1.1 --- Include/object.h 2001/07/05 22:10:54 *************** *** 429,439 **** #endif /* !Py_TRACE_REFS */ #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) ! #define Py_DECREF(op) \ ! if (--_Py_RefTotal, (--((op)->ob_refcnt) != 0)) \ ! ; \ ! else \ ! _Py_Dealloc((PyObject *)(op)) #else /* !Py_REF_DEBUG */ #ifdef COUNT_ALLOCS --- 429,440 ---- #endif /* !Py_TRACE_REFS */ #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) ! /* under Py_REF_DEBUG: also log negative ref counts after Py_DECREF() !! */ ! #define Py_DECREF(op) \ ! if (--_Py_RefTotal, 0 < (--((op)->ob_refcnt))) ; \ ! else if (0 == (op)->ob_refcnt) _Py_Dealloc( (PyObject*)(op)); \ ! else (void)fprintf( stderr, "%s:%i negative ref count %i\n", \ ! __FILE__, __LINE__, (op)->ob_refcnt) #else /* !Py_REF_DEBUG */ #ifdef COUNT_ALLOCS ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448194&group_id=5470 From noreply@sourceforge.net Sun Aug 5 20:15:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 12:15:34 -0700 Subject: [Patches] [ python-Patches-448194 ] Debuging negative reference counts Message-ID: Patches item #448194, was opened at 2001-08-05 10:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448194&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: Debuging negative reference counts Initial Comment: I'm giving the patch below as a 'time-saver' for extension writters suffering crashes (memory-related in most cases). The patch is activated only under compilation with the Py_DEBUG flag (hint: production code is unchanged, this is only of concerns to Py_DEBUG-aware developpers). The new behavior is as follows (under Py_DEBUG): After decrementing: if 0 < do_nothing; elseif 0 == refcount release_memory; else print_warning; #instead of: if 0 < do_nothing else release-memory; In effect, in the present python code, releasing a memory segment already released (negative ref count will at best crash the application, or further corrupts it). With the patch, in the situations (the very large majority of cases) where the memory has not already been overwritten with a positive value, the negative ref count is recognized, and an appropriate action is taken (currently: print the Py_DECREF location to stderr, instead of releasing [erroneously] the memory segment). Note that the only penalty to this is some small code bloat under Py_DEBUG compilation. The feature has been tested on two project, and demonstrated to directly pinpoint almost directly to the culprit in situations where a Py_INCREF has been missing somewhere (as an alternate to teh traditional application crash further down the application :((( Frederic Giacometti diff -c -r1.1.1.1 object.h *** Include/object.h 2001/05/27 15:36:16 1.1.1.1 --- Include/object.h 2001/07/05 22:10:54 *************** *** 429,439 **** #endif /* !Py_TRACE_REFS */ #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) ! #define Py_DECREF(op) \ ! if (--_Py_RefTotal, (--((op)->ob_refcnt) != 0)) \ ! ; \ ! else \ ! _Py_Dealloc((PyObject *)(op)) #else /* !Py_REF_DEBUG */ #ifdef COUNT_ALLOCS --- 429,440 ---- #endif /* !Py_TRACE_REFS */ #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) ! /* under Py_REF_DEBUG: also log negative ref counts after Py_DECREF() !! */ ! #define Py_DECREF(op) \ ! if (--_Py_RefTotal, 0 < (--((op)->ob_refcnt))) ; \ ! else if (0 == (op)->ob_refcnt) _Py_Dealloc( (PyObject*)(op)); \ ! else (void)fprintf( stderr, "%s:%i negative ref count %i\n", \ ! __FILE__, __LINE__, (op)->ob_refcnt) #else /* !Py_REF_DEBUG */ #ifdef COUNT_ALLOCS ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-05 12:15 Message: Logged In: YES user_id=31435 +0 as-is, +1 if changed to call PyFatal_Error. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448194&group_id=5470 From noreply@sourceforge.net Sun Aug 5 21:05:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 13:05:31 -0700 Subject: [Patches] [ python-Patches-448227 ] execfile(dir) no longer works Message-ID: Patches item #448227, was opened at 2001-08-05 13:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: execfile(dir) no longer works Initial Comment: 'execfile(".")' succeeds w/o an error in the current implementation. I'm not sure why the _parse itself_ succeeds, but because a directory can be opened by fopen() for reading, the check in execfile itself succeeds. I added in a check (via stat()) to see if the filename given is a directory. If it is, execfile raises an IOError (same as for filename not existing). I'm perfectly willing to admit that this may not be the best solution ;), but it's less nonintuitive than the current behavior. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 From noreply@sourceforge.net Sun Aug 5 21:05:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 13:05:59 -0700 Subject: [Patches] [ python-Patches-448227 ] execfile(dir) no longer works Message-ID: Patches item #448227, was opened at 2001-08-05 13:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 2 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: execfile(dir) no longer works Initial Comment: 'execfile(".")' succeeds w/o an error in the current implementation. I'm not sure why the _parse itself_ succeeds, but because a directory can be opened by fopen() for reading, the check in execfile itself succeeds. I added in a check (via stat()) to see if the filename given is a directory. If it is, execfile raises an IOError (same as for filename not existing). I'm perfectly willing to admit that this may not be the best solution ;), but it's less nonintuitive than the current behavior. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 From noreply@sourceforge.net Sun Aug 5 22:15:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 14:15:15 -0700 Subject: [Patches] [ python-Patches-448227 ] execfile(dir) no longer works Message-ID: Patches item #448227, was opened at 2001-08-05 13:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: execfile(dir) no longer works Initial Comment: 'execfile(".")' succeeds w/o an error in the current implementation. I'm not sure why the _parse itself_ succeeds, but because a directory can be opened by fopen() for reading, the check in execfile itself succeeds. I added in a check (via stat()) to see if the filename given is a directory. If it is, execfile raises an IOError (same as for filename not existing). I'm perfectly willing to admit that this may not be the best solution ;), but it's less nonintuitive than the current behavior. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-05 14:15 Message: Logged In: YES user_id=21627 Can you please submit unified (-u) or context (-c) diffs in the future? Plain diffs, without context, are hard to integrated once the underlying file changes. As for the IOError, I think you should make sure you get a specific errno code, e.g. EISDIR. Would you be willing to revise your patch in that direction? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 From noreply@sourceforge.net Sun Aug 5 22:23:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 14:23:38 -0700 Subject: [Patches] [ python-Patches-448194 ] Debuging negative reference counts Message-ID: Patches item #448194, was opened at 2001-08-05 10:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448194&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: Debuging negative reference counts Initial Comment: I'm giving the patch below as a 'time-saver' for extension writters suffering crashes (memory-related in most cases). The patch is activated only under compilation with the Py_DEBUG flag (hint: production code is unchanged, this is only of concerns to Py_DEBUG-aware developpers). The new behavior is as follows (under Py_DEBUG): After decrementing: if 0 < do_nothing; elseif 0 == refcount release_memory; else print_warning; #instead of: if 0 < do_nothing else release-memory; In effect, in the present python code, releasing a memory segment already released (negative ref count will at best crash the application, or further corrupts it). With the patch, in the situations (the very large majority of cases) where the memory has not already been overwritten with a positive value, the negative ref count is recognized, and an appropriate action is taken (currently: print the Py_DECREF location to stderr, instead of releasing [erroneously] the memory segment). Note that the only penalty to this is some small code bloat under Py_DEBUG compilation. The feature has been tested on two project, and demonstrated to directly pinpoint almost directly to the culprit in situations where a Py_INCREF has been missing somewhere (as an alternate to teh traditional application crash further down the application :((( Frederic Giacometti diff -c -r1.1.1.1 object.h *** Include/object.h 2001/05/27 15:36:16 1.1.1.1 --- Include/object.h 2001/07/05 22:10:54 *************** *** 429,439 **** #endif /* !Py_TRACE_REFS */ #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) ! #define Py_DECREF(op) \ ! if (--_Py_RefTotal, (--((op)->ob_refcnt) != 0)) \ ! ; \ ! else \ ! _Py_Dealloc((PyObject *)(op)) #else /* !Py_REF_DEBUG */ #ifdef COUNT_ALLOCS --- 429,440 ---- #endif /* !Py_TRACE_REFS */ #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) ! /* under Py_REF_DEBUG: also log negative ref counts after Py_DECREF() !! */ ! #define Py_DECREF(op) \ ! if (--_Py_RefTotal, 0 < (--((op)->ob_refcnt))) ; \ ! else if (0 == (op)->ob_refcnt) _Py_Dealloc( (PyObject*)(op)); \ ! else (void)fprintf( stderr, "%s:%i negative ref count %i\n", \ ! __FILE__, __LINE__, (op)->ob_refcnt) #else /* !Py_REF_DEBUG */ #ifdef COUNT_ALLOCS ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-05 14:23 Message: Logged In: YES user_id=21627 Thanks for your contribution, committed as object.h 2.81. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-05 12:15 Message: Logged In: YES user_id=31435 +0 as-is, +1 if changed to call PyFatal_Error. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448194&group_id=5470 From noreply@sourceforge.net Sun Aug 5 22:54:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 14:54:44 -0700 Subject: [Patches] [ python-Patches-448227 ] execfile(dir) no longer works Message-ID: Patches item #448227, was opened at 2001-08-05 13:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: execfile(dir) no longer works Initial Comment: 'execfile(".")' succeeds w/o an error in the current implementation. I'm not sure why the _parse itself_ succeeds, but because a directory can be opened by fopen() for reading, the check in execfile itself succeeds. I added in a check (via stat()) to see if the filename given is a directory. If it is, execfile raises an IOError (same as for filename not existing). I'm perfectly willing to admit that this may not be the best solution ;), but it's less nonintuitive than the current behavior. ---------------------------------------------------------------------- >Comment By: Titus Brown (titus) Date: 2001-08-05 14:54 Message: Logged In: YES user_id=23486 errno is now correctly set to EISDIR. I've also modified it a bit more so it doesn't try to fopen it if the stat fails, since I can think of no situation in which stat fails & an fopen will succeed. New context (-c) diff attached. N.B. that the Python @ Sourceforge FAQ should be modified to reflect the desire for -c or -u diffs ;). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-05 14:15 Message: Logged In: YES user_id=21627 Can you please submit unified (-u) or context (-c) diffs in the future? Plain diffs, without context, are hard to integrated once the underlying file changes. As for the IOError, I think you should make sure you get a specific errno code, e.g. EISDIR. Would you be willing to revise your patch in that direction? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 From noreply@sourceforge.net Sun Aug 5 23:15:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 15:15:05 -0700 Subject: [Patches] [ python-Patches-448227 ] execfile(dir) no longer works Message-ID: Patches item #448227, was opened at 2001-08-05 13:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: execfile(dir) no longer works Initial Comment: 'execfile(".")' succeeds w/o an error in the current implementation. I'm not sure why the _parse itself_ succeeds, but because a directory can be opened by fopen() for reading, the check in execfile itself succeeds. I added in a check (via stat()) to see if the filename given is a directory. If it is, execfile raises an IOError (same as for filename not existing). I'm perfectly willing to admit that this may not be the best solution ;), but it's less nonintuitive than the current behavior. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-05 15:15 Message: Logged In: YES user_id=31435 The Python @ SF FAQ already says: """ We like context diffs. We grudgingly accept unified diffs. Straight ("ed-style") diffs are right out! If you don't know how to generate context diffs, you're probably not qualified to produce high-quality patches anyway <0.5 wink>. """ ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-05 14:54 Message: Logged In: YES user_id=23486 errno is now correctly set to EISDIR. I've also modified it a bit more so it doesn't try to fopen it if the stat fails, since I can think of no situation in which stat fails & an fopen will succeed. New context (-c) diff attached. N.B. that the Python @ Sourceforge FAQ should be modified to reflect the desire for -c or -u diffs ;). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-05 14:15 Message: Logged In: YES user_id=21627 Can you please submit unified (-u) or context (-c) diffs in the future? Plain diffs, without context, are hard to integrated once the underlying file changes. As for the IOError, I think you should make sure you get a specific errno code, e.g. EISDIR. Would you be willing to revise your patch in that direction? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 From noreply@sourceforge.net Sun Aug 5 23:17:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 15:17:21 -0700 Subject: [Patches] [ python-Patches-448261 ] OSX patches - review wanted Message-ID: Patches item #448261, was opened at 2001-08-05 15:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448261&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: OSX patches - review wanted Initial Comment: I'm posting these here because I'm not a configure-guru and I'd like someone to check that I'm doing reasonable things. The patch does three things: - Warn if you haven't specified --with-suffix and a directory "python" with lowercase p exists (you're probably on a non-case-sensitive filesystem and building python will fail) - Force --with-dyld on OSX (there is no alternative as on NextStep). - If you're building in a subdir also create the directories Mac and Mac/Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448261&group_id=5470 From noreply@sourceforge.net Sun Aug 5 23:24:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 15:24:48 -0700 Subject: [Patches] [ python-Patches-448227 ] execfile(dir) no longer works Message-ID: Patches item #448227, was opened at 2001-08-05 13:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: execfile(dir) no longer works Initial Comment: 'execfile(".")' succeeds w/o an error in the current implementation. I'm not sure why the _parse itself_ succeeds, but because a directory can be opened by fopen() for reading, the check in execfile itself succeeds. I added in a check (via stat()) to see if the filename given is a directory. If it is, execfile raises an IOError (same as for filename not existing). I'm perfectly willing to admit that this may not be the best solution ;), but it's less nonintuitive than the current behavior. ---------------------------------------------------------------------- >Comment By: Titus Brown (titus) Date: 2001-08-05 15:24 Message: Logged In: YES user_id=23486 Section 3.1 of the FAQ: If you are using CVS (anonymous or developer) you can use CVS to make the patches for you. Just edit your local copy and enter the following command: cvs diff | tee ~/name_of_the_patch.diff So that should be 'cvs diff -c | ...' ;). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-05 15:15 Message: Logged In: YES user_id=31435 The Python @ SF FAQ already says: """ We like context diffs. We grudgingly accept unified diffs. Straight ("ed-style") diffs are right out! If you don't know how to generate context diffs, you're probably not qualified to produce high-quality patches anyway <0.5 wink>. """ ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-05 14:54 Message: Logged In: YES user_id=23486 errno is now correctly set to EISDIR. I've also modified it a bit more so it doesn't try to fopen it if the stat fails, since I can think of no situation in which stat fails & an fopen will succeed. New context (-c) diff attached. N.B. that the Python @ Sourceforge FAQ should be modified to reflect the desire for -c or -u diffs ;). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-05 14:15 Message: Logged In: YES user_id=21627 Can you please submit unified (-u) or context (-c) diffs in the future? Plain diffs, without context, are hard to integrated once the underlying file changes. As for the IOError, I think you should make sure you get a specific errno code, e.g. EISDIR. Would you be willing to revise your patch in that direction? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 From noreply@sourceforge.net Sun Aug 5 23:32:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 15:32:19 -0700 Subject: [Patches] [ python-Patches-447476 ] Fixes to setup.py for including OSX modules Message-ID: Patches item #447476, was opened at 2001-08-03 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=447476&group_id=5470 Category: Build Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Fixes to setup.py for including OSX modules Initial Comment: I'm submitting this here in stead of checking it in directly so that it gets some peer review (i.e. I can't check that it doesn't break anything on Windows). These fixes to setup.py replace moddir and incdir by moddirlist and incdirlist, lists of source and include directories that are searched for modules. This is needed because the Mac modules and include files live in the Mac subtree. In addition (and that's actually what the mod is all about) on OSX we build all the Mac extension modules. I'd be grateful if this fix could make it into 2.2a2. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-08-05 15:32 Message: Logged In: YES user_id=45365 Mods checked in (rev 1.45) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-03 12:36 Message: Logged In: YES user_id=6380 Works fine for me on Linux. There are a few long lines; fix these and check it in, I'd say. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-03 10:57 Message: Logged In: YES user_id=31435 No need to worry about Windows -- we don't use setup.py there at all (at least not yet). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=447476&group_id=5470 From noreply@sourceforge.net Mon Aug 6 00:08:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 16:08:45 -0700 Subject: [Patches] [ python-Patches-448227 ] execfile(dir) no longer works Message-ID: Patches item #448227, was opened at 2001-08-05 13:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: execfile(dir) no longer works Initial Comment: 'execfile(".")' succeeds w/o an error in the current implementation. I'm not sure why the _parse itself_ succeeds, but because a directory can be opened by fopen() for reading, the check in execfile itself succeeds. I added in a check (via stat()) to see if the filename given is a directory. If it is, execfile raises an IOError (same as for filename not existing). I'm perfectly willing to admit that this may not be the best solution ;), but it's less nonintuitive than the current behavior. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-05 16:08 Message: Logged In: YES user_id=31435 In context, it assumes you read the earlier: """ 2.3.: Q: What setting should I use? A: That is, of course, hard to answer in the general case. I use the following .cvsrc file: diff -c update -d This defaults diff to context diffs (almost a requirement as everything else is harder to read) and tells update to automatically checkout new subdirectories. """ Nevertheless, you managed to find the only place the FAQ doesn't punch you in throat about context diffs , so I changed it as you suggested. Thanks! ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-05 15:24 Message: Logged In: YES user_id=23486 Section 3.1 of the FAQ: If you are using CVS (anonymous or developer) you can use CVS to make the patches for you. Just edit your local copy and enter the following command: cvs diff | tee ~/name_of_the_patch.diff So that should be 'cvs diff -c | ...' ;). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-05 15:15 Message: Logged In: YES user_id=31435 The Python @ SF FAQ already says: """ We like context diffs. We grudgingly accept unified diffs. Straight ("ed-style") diffs are right out! If you don't know how to generate context diffs, you're probably not qualified to produce high-quality patches anyway <0.5 wink>. """ ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-05 14:54 Message: Logged In: YES user_id=23486 errno is now correctly set to EISDIR. I've also modified it a bit more so it doesn't try to fopen it if the stat fails, since I can think of no situation in which stat fails & an fopen will succeed. New context (-c) diff attached. N.B. that the Python @ Sourceforge FAQ should be modified to reflect the desire for -c or -u diffs ;). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-05 14:15 Message: Logged In: YES user_id=21627 Can you please submit unified (-u) or context (-c) diffs in the future? Plain diffs, without context, are hard to integrated once the underlying file changes. As for the IOError, I think you should make sure you get a specific errno code, e.g. EISDIR. Would you be willing to revise your patch in that direction? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 From noreply@sourceforge.net Mon Aug 6 03:11:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 19:11:32 -0700 Subject: [Patches] [ python-Patches-448305 ] Additions to the C API Message-ID: Patches item #448305, was opened at 2001-08-05 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: Additions to the C API Initial Comment: I'm not sure a PEP is required for this patch, but these functions are pre-requisiste for two other PEP in the pipe... I have not always had easy access to news posting, so I'll be the happier this can go through without all the PEP overhead, otherwise, I'll try to follow up the PEP. I'm submitting this as a PEP in the same time, to the Director of PEP Affairs, as indicated in the PEP meta PEP 000 (barry), with a reference to this patch (file attached). Frederic Giacometti --------------------------- PEP XXX: Additions to the C API fred@arakne.com (Frederic Giacometti) Abstract This PEP defines a couple of C functions. The first two functions are for raising exceptions with multiple arguments; the third one is for calling a method when an arg tuple is given; and the other ones programmatically define sys.path and the optimization level in embedded python context, before initialization of the global Python engine. Copyright: This document is published under the Open Publication License. Specification: PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) Raise the exception created by applying args to exctype. This is equivalent to the Python expression raise apply( exctype, args). Always set the error state and return NULL. PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) This function is similar to PyErr_RaiseArgs(), but defines the arguments using the same convention as Py_BuildValue(). Always set the error state and return NULL. PyObject* PyObject_CallMethodArgs( PyObject* o, char const* method, PyObject* args) Call the method named 'method' with arguments given by the tuple args, using for args the same convention as PyObject_CallObject(). This is the equivalent of the Python expression o.method( args). Note that special method names, such as __add__(), __getitem__(), and so on are not supported. The specific abstract-object routines for these must be used. void Py_SetPythonPath( char const* path) This function should be called before Py_Initialize() is called for the first time, if it is called at all. It defines the PYTHONPATH value to be used by the interpreter. Calling Py_SetPythonPath() will override the PYTHONPATH value from the environment. The argument should be NULL, or point to a zero-terminated character string which will not change for the duration of the program's execution. char const* Py_GetPythonPath() If Py_SetPythonPath() was never called, getenv( "PYTHONPATH") is returned, otherwise the argument of Py_SetPythonPath() is returned. The returned string points into static storage. void Py_SetOptimizeLevel( int level) This function should be called before Py_Initialize() is called for the first time. Legal optimization levels are listed below. \begin{tableii}{c|l}{character}{Character}{Meaning} \lineii{0}{No optimization (use \code{.pyc} files by default)} \lineii{1}{Same as \code{python -O}} \lineii{2}{Same as \code{python -OO}} \end{tableii} int Py_GetOptimizeLevel() Return the interpreter optimization level. Reference Implementation: See attached patch (concatenation of 2 patch files). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 From noreply@sourceforge.net Mon Aug 6 04:37:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 20:37:09 -0700 Subject: [Patches] [ python-Patches-429614 ] pythonpath and optimize def. before init Message-ID: Patches item #429614, was opened at 2001-06-02 08:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 Category: core (C code) Group: None >Status: Pending Resolution: Postponed Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: pythonpath and optimize def. before init Initial Comment: A) Addition of four functions ===================== Py_{Set, Get}{PythonPath, OptimizeLevel}() with the same semantics as Py_{Set, Get}ProgramName() (Note: the C ANSI type 'char const*' is used to describe non-modifiable strings) These four functions are needed in the next JPE runtime (Python 2.1 patch included in the distribution); this allows setting the PYTHONPATH and optimize level from Java property values. B) Option '-P pythonpath' on the Python command line: ======================================== This option defines 'pythonpath' from the command line (and override the PYTHONPATH environment variable if necessary). Usefullness: Sometimes, one does not want to rely on the environment variables, or modify them. Sample application: Running build and test scripts in full control of the environment, and with different PYTHONPATH values. This option is needed by the build and test scripts of the next JPE source distribution (Python 2.1 patch included in the distribution. Frederic Giacometti fred@arakne.com ---------------------------------------------------------------------- >Comment By: Frederic Giacometti (giacometti) Date: 2001-08-05 20:37 Message: Logged In: YES user_id=93657 I apologize for the delay, but I have been travelling a lot for the last 2 months, and I could not have followed up a PEP. I'm now stabilized, so here is the PEP proposal I just mailed to Barry. Regards, Frederic Giacometti -------------------------------------- PEP XXX: Addition of an option for completing sys.path from the commandline fred@arakne.com (Frederic Giacometti) Abstract At present, the PYTHONPATH environment variable is the only method for defining additional Python module directories. This PEP introduce the '-P' valued option to the python command as an alternative to PYTHONPATH. Copyright: This document is published under the Open Publication License. Specification: On Unix: python -P $SOMEVALUE will be equivalent to env PYTHONPATH=$SOMEVALUE python On Windows 2K: python -P $SOMEVALUE will (almost, humm) be equivalent to set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE% && python && set PYTHONPATH=__%PYTHONPATH% Reference Implementation and PEP pre-history: See patch http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:29 Message: Logged In: YES user_id=3066 Flagged this patch as postponed pending the availability of a suitable or at least a publically archived discussion that indicates this is a useful and non-controversial change. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-10 22:53 Message: Logged In: YES user_id=21627 You can find the PEP guidelines in PEP 1: http://python.sourceforge.net/peps/pep-0001.html ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-06-08 14:37 Message: Logged In: YES user_id=93657 1) PEP: I am not in python-dev. What is the procedure for opening the PEP? 2) Override: I though about the question. My response was: If you wnat concatenation, use: python -P "something:$PYTHONPATH" or python -P "$PYTHONPATH:something" That's for all the better... 3) I renamed Py_{Set,Get}OptimizeFlag to Py_{Set,Get}OtimizeLevel after I wrote the documentation. Glad you caught the typo :)), sorry :(( I changed 'Flag' to 'Level' because 'Flag' normally designates a binary variable (2 states) whereas what we are doing is actually defining a debuging level (3 levels as of now, but who knows that some more levels might be addes). 'OptimizeLevel' is more accurate and less ambiguous than 'OptimizeFlag'. Frederic Giacometti ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-07 12:58 Message: Logged In: YES user_id=21627 I think a PEP describing the exact rationale and nature of the change is required here. For example, why is it good that -P overrides PYTHONPATH, instead of combining both somehow? Also, the documentation talks about Py_GetOptimizeLevel, whereas the header declares Py_GetOptimizeFlag. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 From noreply@sourceforge.net Mon Aug 6 19:15:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 Aug 2001 11:15:01 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFil Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for 'tell()' to gzip.GzipFil Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Mon Aug 6 19:17:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 Aug 2001 11:17:47 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) >Summary: Add support for 'tell()' to gzip.GzipFile Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Mon Aug 6 19:51:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 Aug 2001 11:51:18 -0700 Subject: [Patches] [ python-Patches-448488 ] Implemenation of ImportNotFoundError PEP Message-ID: Patches item #448488, was opened at 2001-08-06 11:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448488&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: Implemenation of ImportNotFoundError PEP Initial Comment: This is a reference implementation for the PEP proposal. Here, the patch has existed before the PEP, therefore the PEP refers to the patch... I need to create the patch before I submit the PEP :))) Frederic Giacometti ----------------------- PEP XXX: ImportNotFoundError Exception fred@arakne.com (Frederic Giacometti) Abstract The object of this proposal is the definition of a specific ImportNotFoundError error, along with its association to a new import exception trapping mechanism that will enable the extension of the import mechanism to generic global/static objects. Part 1: The ImportNotFoundError exception. In the present code, the ImportError string exception is used for all import failures; this does not permit us to catch efficiently import failures caused specifically by a 'component not found' situation. To fix this, we introduce a new exception, that we call ImportNotFoundError. This exception is designed for use in the very specific situation where an import string cannot be found by the import mechanism (as opposed to 'found' but 'failed to open', failed to load', 'failed to initialize'...). ImportNotFoundError instance raised within execution of an import statement will have two attributes as follows: - 'parent': the element of sys.modules where the next import failed, or None if top-level import. - 'name': the string of the next .-separated component which failed A formal Python definition of ImportErrorNotFound could be: class ImportNotFoundError( ImportError): def __init__( self, parent, name): assert( hasattr( parent, '__name__')) assert( sys.modules.has_key( parent.__name__)) assert( sys.modules[ parent.__name__] is parent) assert( not hasattr( parent, name)) ImportError.__init__( self, parent, name) self.parent = parent self.name = name 2) Alternative import customization hook in the module global scope (__altimp__) 2.a: Why in the module global scope? (or: Why not overwrite builtins.__import__?) Use of builtins.__import__ is not a preferred integration practice: Only one __import__ value can be defined; and if you're integrating two components with each its own __import__ version, you'll be stuck... Furthermore, if one insists on overwriting __import__, one can still do it. Meanwhile, if an application requires overwriting __import__, and one does not want to, one is stuck again... Since we want to keep options open, we're proposing to enhance the import procedure defining a trapping mechanism based on the presence of a globals()[ '__altimp__'] object, which is called if present upon trigger of an ImportNotFoundError within an import statement. In doing so, those who don't want (rightfully) to be bothered won't be, unless they define __altimp__ in their module global scope, and a module's usage of a certain implementation of __altimp__ won't bother other modules, at all. 2.b Definition If present, globals()[ '__altimp__'] will refer to a callable object specified as follows: def importextended( failedparent, failedname, name, globs=None, locs=None, fromlist=None): failedparent: 'parent' attribute from the ImportnotFoundError exception failedname: 'name' attribute from the ImportnotFoundError exception (name, globs, locs, fromlist): same arguments as in __import__() return: same as in __import__() [object for insertion in sys.modules...] Effect on existing code There should be no effect on existing code, other than when code like exc.__class__ == ImportError has been meant for isinstance( exc, ImportError) (hopeless anyway? :(() Applications: Given that importext.py contains: __all__ = ('importextended') import sys def importextended( failedparent, failedname, name, globs=None, locs=None, fromlist=None): curmod = failedparent remainder = name[ len( curmod.__name__) + 1:].split( '.') while remainder: curname = remainder.pop( 0) curmod = getattr( curmod, curname) sys.modules[ curmod.__name__] = curmod return curmod A JPE file may contain: # import Java's javax.swing package in global scope from importext import importextended as __altimport__ from java import Jstring from java.system.javax import swing frame = swing.JFrame( Jstring( 'HelloWorldSwing')) label = swing.JLabel( Jstring( 'Hello World')) frame.getContentPane().add(label) frame.setDefaultCloseOperation( swing.JFrame.EXIT_ON_CLOSE) frame.pack() frame.setVisible( 1) A Metadynamic Python file can contain: # User is a Metaphase persistant class from importext import importextended as __altimport__ from metadyn.mclass import User users = mclass.User.QueryDbItem( some_query) ... Based on this feature, applications can easily be programmed on the client side for any client/server situation, including pulling Python modules from remote repository... Reference Implementation: A sample implementation of ImportErrorNotFoundError in the current import mechanism, with the __altimp__ hook is provided in patch href:attached_file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448488&group_id=5470 From noreply@sourceforge.net Tue Aug 7 18:14:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 10:14:59 -0700 Subject: [Patches] [ python-Patches-448841 ] Patch for PEP 249 Message-ID: Patches item #448841, was opened at 2001-08-07 10:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for PEP 249 Initial Comment: This patch is submitted to clarify the usage of the executemany() method of the Cursor class. Language is added to make it clear that use of this method for an operation which results in one or more result sets constitutes undefined behavior, and that in such a case the implementation is permitted (but not required) to raise an exception. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 From noreply@sourceforge.net Tue Aug 7 23:10:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 15:10:34 -0700 Subject: [Patches] [ python-Patches-431848 ] mathmodule.c: doc strings & conversion Message-ID: Patches item #431848, was opened at 2001-06-08 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=431848&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Peter Schneider-Kamp (nowonder) Assigned to: Tim Peters (tim_one) Summary: mathmodule.c: doc strings & conversion Initial Comment: * more informative doc strings for mathmodule.c * methods math.radians and math.degrees to convert between radians and degrees This addresses feature request #426539. Suggestions for better names (deg2rad instead of radians?) or better doc strings will be met enthusiastically. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-07 15:10 Message: Logged In: YES user_id=31435 Partly accepted, partly rejected. I checked in the docstring changes (and thanks!) with modifications: + For the arc trig functions, it's not the argument but the return value that's measured in radians. + For the hyperbolic "trig" functions, degrees-vs-radians isn't relevant (these aren't functions of angles, despite the "sin" etc parts of their names -- sinh etc are really in the exponential/log family). I didn't check in the degrees() or radians() functions. I'm not opposed to the idea, but contemporary good practice for math libraries is to guarantee worst-case error strictly less than 1 ULP, and these don't even try. If a user is happy with sloppy results, they can very easily get the results computed here with simple Python 1-liners. If the functions here met the < 1 ULP worst-case error bound, then they'd be offering something of real value. Modules/mathmodule.c; new revision: 2.60 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=431848&group_id=5470 From noreply@sourceforge.net Wed Aug 8 05:34:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 21:34:02 -0700 Subject: [Patches] [ python-Patches-448261 ] OSX patches - review wanted Message-ID: Patches item #448261, was opened at 2001-08-05 15:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448261&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: OSX patches - review wanted Initial Comment: I'm posting these here because I'm not a configure-guru and I'd like someone to check that I'm doing reasonable things. The patch does three things: - Warn if you haven't specified --with-suffix and a directory "python" with lowercase p exists (you're probably on a non-case-sensitive filesystem and building python will fail) - Force --with-dyld on OSX (there is no alternative as on NextStep). - If you're building in a subdir also create the directories Mac and Mac/Python. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:34 Message: Logged In: YES user_id=21627 On --with-dyld: If --with-dyld is the only choice on the Mac, then it should not be set implicitly. Instead, support for not having it should be removed. I.e. in all places that check for with_dyld, the Darwin case should be split out, and the resulting features should be automatically activated. E.g. Darwin/*|next/*) if test "$ns_dyld" then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; fi if test "$with_next_framework" ; then LDSHARED="$LDSHARED \" fi ;; should change to Darwin/*)LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' next/*) if test "$ns_dyld" then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; fi if test "$with_next_framework" ; then LDSHARED="$LDSHARED \" fi ;; As a result, --with-dyld becomes a next-only thing. It may be that --with-next-framework is also meaningless on Darwin, in which case the support for specifying it on Darwin should be removed. So I disapprove the part of the patch that just sets with_dyld. On Mac/Python, I think the hierarchy is backwards, it should be Python/Mac instead. It also appears that only macglue.c is actually used on Darwin (I don't know whether the others are ever used). If that is the case, macglue.c should be moved to Python/, in which case the SRCDIRS change is not needed anymore, either. In any case, I think Mac should not be in SRCDIRS, since it does not contain any sources. It appears you listed it only to get Mac created before Mac/Python is created. Instead, mkdir -p should be used to create SRCDIRS. While you are at it, you should carefully review the other Next stuff whether it really applies to Darwin. E.g. why is it that we check for -f /System/Library/CoreServices/software_version Is this for Darwin only, or was there a NeXT release that had this but not /usr/lib/NextStep/software_version? If this is for Darwin only, I think the test should be removed, with the Darwin code in it. I suppose that --with-next-arch is not supported on Darwin, is it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448261&group_id=5470 From noreply@sourceforge.net Wed Aug 8 05:47:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 21:47:21 -0700 Subject: [Patches] [ python-Patches-448841 ] Patch for PEP 249 Message-ID: Patches item #448841, was opened at 2001-08-07 10:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) >Assigned to: M.-A. Lemburg (lemburg) Summary: Patch for PEP 249 Initial Comment: This patch is submitted to clarify the usage of the executemany() method of the Cursor class. Language is added to make it clear that use of this method for an operation which results in one or more result sets constitutes undefined behavior, and that in such a case the implementation is permitted (but not required) to raise an exception. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:47 Message: Logged In: YES user_id=21627 Patches to PEPs normally would not need to go through the patch manager. According to PEP1, you are supposed to send them directly to the PEP author in the initial discussion, or sent it as a comment to the PEP in the public discussion fora, such as comp.lang.python. The PEP author is than supposed to integrate it into the PEP - even if he disagrees with the proposal, he is somehow to record in the PEP that people have raised this opinion. Anyway, since this is Marc-Andre's PEP, I'm assigning the patch to him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 From noreply@sourceforge.net Wed Aug 8 05:54:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 21:54:48 -0700 Subject: [Patches] [ python-Patches-448488 ] Implemenation of ImportNotFoundError PEP Message-ID: Patches item #448488, was opened at 2001-08-06 11:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448488&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: Implemenation of ImportNotFoundError PEP Initial Comment: This is a reference implementation for the PEP proposal. Here, the patch has existed before the PEP, therefore the PEP refers to the patch... I need to create the patch before I submit the PEP :))) Frederic Giacometti ----------------------- PEP XXX: ImportNotFoundError Exception fred@arakne.com (Frederic Giacometti) Abstract The object of this proposal is the definition of a specific ImportNotFoundError error, along with its association to a new import exception trapping mechanism that will enable the extension of the import mechanism to generic global/static objects. Part 1: The ImportNotFoundError exception. In the present code, the ImportError string exception is used for all import failures; this does not permit us to catch efficiently import failures caused specifically by a 'component not found' situation. To fix this, we introduce a new exception, that we call ImportNotFoundError. This exception is designed for use in the very specific situation where an import string cannot be found by the import mechanism (as opposed to 'found' but 'failed to open', failed to load', 'failed to initialize'...). ImportNotFoundError instance raised within execution of an import statement will have two attributes as follows: - 'parent': the element of sys.modules where the next import failed, or None if top-level import. - 'name': the string of the next .-separated component which failed A formal Python definition of ImportErrorNotFound could be: class ImportNotFoundError( ImportError): def __init__( self, parent, name): assert( hasattr( parent, '__name__')) assert( sys.modules.has_key( parent.__name__)) assert( sys.modules[ parent.__name__] is parent) assert( not hasattr( parent, name)) ImportError.__init__( self, parent, name) self.parent = parent self.name = name 2) Alternative import customization hook in the module global scope (__altimp__) 2.a: Why in the module global scope? (or: Why not overwrite builtins.__import__?) Use of builtins.__import__ is not a preferred integration practice: Only one __import__ value can be defined; and if you're integrating two components with each its own __import__ version, you'll be stuck... Furthermore, if one insists on overwriting __import__, one can still do it. Meanwhile, if an application requires overwriting __import__, and one does not want to, one is stuck again... Since we want to keep options open, we're proposing to enhance the import procedure defining a trapping mechanism based on the presence of a globals()[ '__altimp__'] object, which is called if present upon trigger of an ImportNotFoundError within an import statement. In doing so, those who don't want (rightfully) to be bothered won't be, unless they define __altimp__ in their module global scope, and a module's usage of a certain implementation of __altimp__ won't bother other modules, at all. 2.b Definition If present, globals()[ '__altimp__'] will refer to a callable object specified as follows: def importextended( failedparent, failedname, name, globs=None, locs=None, fromlist=None): failedparent: 'parent' attribute from the ImportnotFoundError exception failedname: 'name' attribute from the ImportnotFoundError exception (name, globs, locs, fromlist): same arguments as in __import__() return: same as in __import__() [object for insertion in sys.modules...] Effect on existing code There should be no effect on existing code, other than when code like exc.__class__ == ImportError has been meant for isinstance( exc, ImportError) (hopeless anyway? :(() Applications: Given that importext.py contains: __all__ = ('importextended') import sys def importextended( failedparent, failedname, name, globs=None, locs=None, fromlist=None): curmod = failedparent remainder = name[ len( curmod.__name__) + 1:].split( '.') while remainder: curname = remainder.pop( 0) curmod = getattr( curmod, curname) sys.modules[ curmod.__name__] = curmod return curmod A JPE file may contain: # import Java's javax.swing package in global scope from importext import importextended as __altimport__ from java import Jstring from java.system.javax import swing frame = swing.JFrame( Jstring( 'HelloWorldSwing')) label = swing.JLabel( Jstring( 'Hello World')) frame.getContentPane().add(label) frame.setDefaultCloseOperation( swing.JFrame.EXIT_ON_CLOSE) frame.pack() frame.setVisible( 1) A Metadynamic Python file can contain: # User is a Metaphase persistant class from importext import importextended as __altimport__ from metadyn.mclass import User users = mclass.User.QueryDbItem( some_query) ... Based on this feature, applications can easily be programmed on the client side for any client/server situation, including pulling Python modules from remote repository... Reference Implementation: A sample implementation of ImportErrorNotFoundError in the current import mechanism, with the __altimp__ hook is provided in patch href:attached_file. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:54 Message: Logged In: YES user_id=21627 There is in general no need to put the PEP into the SF comment. Just send it to the PEP editor, who should assign a PEP number and commit it into CVS in a timely manner. I have a number of comments on this PEP, but I'll send them directly to you once the PEP is on python.sf.net/peps. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448488&group_id=5470 From noreply@sourceforge.net Wed Aug 8 06:02:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 22:02:20 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for 'tell()' to gzip.GzipFile Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:02 Message: Logged In: YES user_id=21627 Please use context (-c) or unified (-u) patch following the SF FAQ (http://python.sourceforge.net/sf-faq.html#patches). As for the patch itself: It seems not so clear that tell() should really give the position in the uncompressed stream; why is that more useful than the position in the compressed stream? Also, it seems that .tell() is useless without .seek. However, I pretty much doubt you can do .seek on top of zlib: to seek to a certain position, you would need the state of the compression engine at this position, no? Unless I'm missing something here, I would therefore recommend to reject this patch, and advise you to derive a class from GzipFile that has the tell semantics you desire, for use in your application. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Wed Aug 8 06:04:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 22:04:18 -0700 Subject: [Patches] [ python-Patches-443474 ] from __future__ import division Message-ID: Patches item #443474, was opened at 2001-07-21 21:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443474&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: from __future__ import division Initial Comment: This patch is a quick hack to implement one way of doing PEP 238 (non-integer division). There are two parts to it. Part 1: the // operator implements integer division. Part 2: when "from __future__ import division" is in effect, the / operator implements float division. The //= and /= operators are also affected. (This is part of why I chose // over the keyword 'div'; also because that would require a new keyword.) The implementation now has three division operations (of each variation: regular and inplace, and corresponding opcodes) where it used to have one: - Division for / without future statement - FloatDivision for / with future statement - IntDivision for // The actual implementations for IntDivision and FloatDivision are a bit lame: - (old) Division is unchanged (using nb_division) - IntDivision just calls Division, so only does the right thing for ints and longs - FloatDivision adds 0.0 to the second operand At some point in the future, to keep NumPy happy, the "as number" struct should grow extra slots for the additional operations, and the above operations should only be used as fallbacks. (Maybe the fallback for IntDivision should use the nb_divmod slot as fallback.) Enjoy! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-31 12:33 Message: Logged In: YES user_id=6380 Uploading a new version. This includes the patch for graminit.c. This follows the revised PEP: terminology changed to true and floor division, actual slots in type objects used. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-21 21:39 Message: Logged In: YES user_id=6380 Note, the patch doesn't include the changes for graminit.c (because they were big). This may cause problems on Windows, where that file is not automatically recreated when the grammar changes. I'm including the new graminit.c just in case. (graminit.h is unchanged.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443474&group_id=5470 From noreply@sourceforge.net Wed Aug 8 06:16:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 22:16:16 -0700 Subject: [Patches] [ python-Patches-448305 ] Additions to the C API Message-ID: Patches item #448305, was opened at 2001-08-05 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: Additions to the C API Initial Comment: I'm not sure a PEP is required for this patch, but these functions are pre-requisiste for two other PEP in the pipe... I have not always had easy access to news posting, so I'll be the happier this can go through without all the PEP overhead, otherwise, I'll try to follow up the PEP. I'm submitting this as a PEP in the same time, to the Director of PEP Affairs, as indicated in the PEP meta PEP 000 (barry), with a reference to this patch (file attached). Frederic Giacometti --------------------------- PEP XXX: Additions to the C API fred@arakne.com (Frederic Giacometti) Abstract This PEP defines a couple of C functions. The first two functions are for raising exceptions with multiple arguments; the third one is for calling a method when an arg tuple is given; and the other ones programmatically define sys.path and the optimization level in embedded python context, before initialization of the global Python engine. Copyright: This document is published under the Open Publication License. Specification: PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) Raise the exception created by applying args to exctype. This is equivalent to the Python expression raise apply( exctype, args). Always set the error state and return NULL. PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) This function is similar to PyErr_RaiseArgs(), but defines the arguments using the same convention as Py_BuildValue(). Always set the error state and return NULL. PyObject* PyObject_CallMethodArgs( PyObject* o, char const* method, PyObject* args) Call the method named 'method' with arguments given by the tuple args, using for args the same convention as PyObject_CallObject(). This is the equivalent of the Python expression o.method( args). Note that special method names, such as __add__(), __getitem__(), and so on are not supported. The specific abstract-object routines for these must be used. void Py_SetPythonPath( char const* path) This function should be called before Py_Initialize() is called for the first time, if it is called at all. It defines the PYTHONPATH value to be used by the interpreter. Calling Py_SetPythonPath() will override the PYTHONPATH value from the environment. The argument should be NULL, or point to a zero-terminated character string which will not change for the duration of the program's execution. char const* Py_GetPythonPath() If Py_SetPythonPath() was never called, getenv( "PYTHONPATH") is returned, otherwise the argument of Py_SetPythonPath() is returned. The returned string points into static storage. void Py_SetOptimizeLevel( int level) This function should be called before Py_Initialize() is called for the first time. Legal optimization levels are listed below. \begin{tableii}{c|l}{character}{Character}{Meaning} \lineii{0}{No optimization (use \code{.pyc} files by default)} \lineii{1}{Same as \code{python -O}} \lineii{2}{Same as \code{python -OO}} \end{tableii} int Py_GetOptimizeLevel() Return the interpreter optimization level. Reference Implementation: See attached patch (concatenation of 2 patch files). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:16 Message: Logged In: YES user_id=21627 It seems that your patch is somewhat confused: It contains fragments of the SetPythonPath code, but fails to include the implementation of PyErr_Raise[Args]. I think the patch should also identify the places in the code that could make use of the offered simplifications (and change them to the new API), to get an impression of how general this API is. I'm +1 on the _Raise functions and -0 on the CallMethodArgs (why does it not support keyword arguments?). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 From noreply@sourceforge.net Wed Aug 8 06:31:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 22:31:14 -0700 Subject: [Patches] [ python-Patches-448227 ] execfile(dir) no longer works Message-ID: Patches item #448227, was opened at 2001-08-05 13:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 2 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: execfile(dir) no longer works Initial Comment: 'execfile(".")' succeeds w/o an error in the current implementation. I'm not sure why the _parse itself_ succeeds, but because a directory can be opened by fopen() for reading, the check in execfile itself succeeds. I added in a check (via stat()) to see if the filename given is a directory. If it is, execfile raises an IOError (same as for filename not existing). I'm perfectly willing to admit that this may not be the best solution ;), but it's less nonintuitive than the current behavior. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:31 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as bltinmodule.c 2.223. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-05 16:08 Message: Logged In: YES user_id=31435 In context, it assumes you read the earlier: """ 2.3.: Q: What setting should I use? A: That is, of course, hard to answer in the general case. I use the following .cvsrc file: diff -c update -d This defaults diff to context diffs (almost a requirement as everything else is harder to read) and tells update to automatically checkout new subdirectories. """ Nevertheless, you managed to find the only place the FAQ doesn't punch you in throat about context diffs , so I changed it as you suggested. Thanks! ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-05 15:24 Message: Logged In: YES user_id=23486 Section 3.1 of the FAQ: If you are using CVS (anonymous or developer) you can use CVS to make the patches for you. Just edit your local copy and enter the following command: cvs diff | tee ~/name_of_the_patch.diff So that should be 'cvs diff -c | ...' ;). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-05 15:15 Message: Logged In: YES user_id=31435 The Python @ SF FAQ already says: """ We like context diffs. We grudgingly accept unified diffs. Straight ("ed-style") diffs are right out! If you don't know how to generate context diffs, you're probably not qualified to produce high-quality patches anyway <0.5 wink>. """ ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-05 14:54 Message: Logged In: YES user_id=23486 errno is now correctly set to EISDIR. I've also modified it a bit more so it doesn't try to fopen it if the stat fails, since I can think of no situation in which stat fails & an fopen will succeed. New context (-c) diff attached. N.B. that the Python @ Sourceforge FAQ should be modified to reflect the desire for -c or -u diffs ;). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-05 14:15 Message: Logged In: YES user_id=21627 Can you please submit unified (-u) or context (-c) diffs in the future? Plain diffs, without context, are hard to integrated once the underlying file changes. As for the IOError, I think you should make sure you get a specific errno code, e.g. EISDIR. Would you be willing to revise your patch in that direction? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448227&group_id=5470 From noreply@sourceforge.net Wed Aug 8 06:34:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 22:34:20 -0700 Subject: [Patches] [ python-Patches-448171 ] Allow jython to complete test_exceptions Message-ID: Patches item #448171, was opened at 2001-08-05 08:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448171&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow jython to complete test_exceptions Initial Comment: The behavior of continue in a try clause is a known difference between CPython and Jython. This patch will jython to skip that test. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:34 Message: Logged In: YES user_id=21627 Why is it desirable for Jython to pass this test? It looks like a bug in Jython to me... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448171&group_id=5470 From noreply@sourceforge.net Wed Aug 8 06:47:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 Aug 2001 22:47:25 -0700 Subject: [Patches] [ python-Patches-448841 ] Patch for PEP 249 Message-ID: Patches item #448841, was opened at 2001-08-07 10:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: M.-A. Lemburg (lemburg) Summary: Patch for PEP 249 Initial Comment: This patch is submitted to clarify the usage of the executemany() method of the Cursor class. Language is added to make it clear that use of this method for an operation which results in one or more result sets constitutes undefined behavior, and that in such a case the implementation is permitted (but not required) to raise an exception. ---------------------------------------------------------------------- >Comment By: Bob Kline (bkline) Date: 2001-08-07 22:47 Message: Logged In: YES user_id=291529 loewis: OK, I'm very confused. I originally posted the suggestion for this enhancement to the PEP to the DB-SIG, which surely qualifies as a public Python forum. A discussion ensued, I asked what the best way to submit the suggested modification would be, and Marc-André himself replied asking that I submit a patch against the PEP to SourceForge. I then read PEP1, which says, "Please use the SourceForge bug manager[6] if you want to report problems with PEPs, or better yet, the SourceForge patch manager[2] for submitting patches to PEPs." I followed the link at [2], which took me here, where I uploaded the patch and reported back to Marc-André letting him know I had done so (and provided him with a copy of the patch). So, where exactly did I screw up, please? [2] http://sourceforge.net/tracker/? group_id=5470&atid=305470 [6] http://sourceforge.net/tracker/? group_id=5470&atid=305470 Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:47 Message: Logged In: YES user_id=21627 Patches to PEPs normally would not need to go through the patch manager. According to PEP1, you are supposed to send them directly to the PEP author in the initial discussion, or sent it as a comment to the PEP in the public discussion fora, such as comp.lang.python. The PEP author is than supposed to integrate it into the PEP - even if he disagrees with the proposal, he is somehow to record in the PEP that people have raised this opinion. Anyway, since this is Marc-Andre's PEP, I'm assigning the patch to him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 From noreply@sourceforge.net Wed Aug 8 08:08:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 00:08:43 -0700 Subject: [Patches] [ python-Patches-448841 ] Patch for PEP 249 Message-ID: Patches item #448841, was opened at 2001-08-07 10:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: M.-A. Lemburg (lemburg) Summary: Patch for PEP 249 Initial Comment: This patch is submitted to clarify the usage of the executemany() method of the Cursor class. Language is added to make it clear that use of this method for an operation which results in one or more result sets constitutes undefined behavior, and that in such a case the implementation is permitted (but not required) to raise an exception. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 00:08 Message: Logged In: YES user_id=21627 I wasn't aware that PEP 1 actually suggests to use the patch manager; it is alright then that you did so. I had the sentence A better strategy is to encourage public feedback directly to the PEP author, who collects and integrates the comments back into the PEP. from the PEP in mind; my apologies. ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-07 22:47 Message: Logged In: YES user_id=291529 loewis: OK, I'm very confused. I originally posted the suggestion for this enhancement to the PEP to the DB-SIG, which surely qualifies as a public Python forum. A discussion ensued, I asked what the best way to submit the suggested modification would be, and Marc-André himself replied asking that I submit a patch against the PEP to SourceForge. I then read PEP1, which says, "Please use the SourceForge bug manager[6] if you want to report problems with PEPs, or better yet, the SourceForge patch manager[2] for submitting patches to PEPs." I followed the link at [2], which took me here, where I uploaded the patch and reported back to Marc-André letting him know I had done so (and provided him with a copy of the patch). So, where exactly did I screw up, please? [2] http://sourceforge.net/tracker/? group_id=5470&atid=305470 [6] http://sourceforge.net/tracker/? group_id=5470&atid=305470 Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:47 Message: Logged In: YES user_id=21627 Patches to PEPs normally would not need to go through the patch manager. According to PEP1, you are supposed to send them directly to the PEP author in the initial discussion, or sent it as a comment to the PEP in the public discussion fora, such as comp.lang.python. The PEP author is than supposed to integrate it into the PEP - even if he disagrees with the proposal, he is somehow to record in the PEP that people have raised this opinion. Anyway, since this is Marc-Andre's PEP, I'm assigning the patch to him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 From noreply@sourceforge.net Wed Aug 8 08:26:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 00:26:04 -0700 Subject: [Patches] [ python-Patches-448841 ] Patch for PEP 249 Message-ID: Patches item #448841, was opened at 2001-08-07 10:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: M.-A. Lemburg (lemburg) Summary: Patch for PEP 249 Initial Comment: This patch is submitted to clarify the usage of the executemany() method of the Cursor class. Language is added to make it clear that use of this method for an operation which results in one or more result sets constitutes undefined behavior, and that in such a case the implementation is permitted (but not required) to raise an exception. ---------------------------------------------------------------------- >Comment By: Bob Kline (bkline) Date: 2001-08-08 00:26 Message: Logged In: YES user_id=291529 No problem. :->} Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 00:08 Message: Logged In: YES user_id=21627 I wasn't aware that PEP 1 actually suggests to use the patch manager; it is alright then that you did so. I had the sentence A better strategy is to encourage public feedback directly to the PEP author, who collects and integrates the comments back into the PEP. from the PEP in mind; my apologies. ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-07 22:47 Message: Logged In: YES user_id=291529 loewis: OK, I'm very confused. I originally posted the suggestion for this enhancement to the PEP to the DB-SIG, which surely qualifies as a public Python forum. A discussion ensued, I asked what the best way to submit the suggested modification would be, and Marc-André himself replied asking that I submit a patch against the PEP to SourceForge. I then read PEP1, which says, "Please use the SourceForge bug manager[6] if you want to report problems with PEPs, or better yet, the SourceForge patch manager[2] for submitting patches to PEPs." I followed the link at [2], which took me here, where I uploaded the patch and reported back to Marc-André letting him know I had done so (and provided him with a copy of the patch). So, where exactly did I screw up, please? [2] http://sourceforge.net/tracker/? group_id=5470&atid=305470 [6] http://sourceforge.net/tracker/? group_id=5470&atid=305470 Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:47 Message: Logged In: YES user_id=21627 Patches to PEPs normally would not need to go through the patch manager. According to PEP1, you are supposed to send them directly to the PEP author in the initial discussion, or sent it as a comment to the PEP in the public discussion fora, such as comp.lang.python. The PEP author is than supposed to integrate it into the PEP - even if he disagrees with the proposal, he is somehow to record in the PEP that people have raised this opinion. Anyway, since this is Marc-Andre's PEP, I'm assigning the patch to him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 From noreply@sourceforge.net Wed Aug 8 08:54:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 00:54:52 -0700 Subject: [Patches] [ python-Patches-448841 ] Patch for PEP 249 Message-ID: Patches item #448841, was opened at 2001-08-07 10:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: M.-A. Lemburg (lemburg) Summary: Patch for PEP 249 Initial Comment: This patch is submitted to clarify the usage of the executemany() method of the Cursor class. Language is added to make it clear that use of this method for an operation which results in one or more result sets constitutes undefined behavior, and that in such a case the implementation is permitted (but not required) to raise an exception. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 00:54 Message: Logged In: YES user_id=38388 Everything's fine Bob :-) I'll check in your patch today. Thanks. ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-08 00:26 Message: Logged In: YES user_id=291529 No problem. :->} Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 00:08 Message: Logged In: YES user_id=21627 I wasn't aware that PEP 1 actually suggests to use the patch manager; it is alright then that you did so. I had the sentence A better strategy is to encourage public feedback directly to the PEP author, who collects and integrates the comments back into the PEP. from the PEP in mind; my apologies. ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-07 22:47 Message: Logged In: YES user_id=291529 loewis: OK, I'm very confused. I originally posted the suggestion for this enhancement to the PEP to the DB-SIG, which surely qualifies as a public Python forum. A discussion ensued, I asked what the best way to submit the suggested modification would be, and Marc-André himself replied asking that I submit a patch against the PEP to SourceForge. I then read PEP1, which says, "Please use the SourceForge bug manager[6] if you want to report problems with PEPs, or better yet, the SourceForge patch manager[2] for submitting patches to PEPs." I followed the link at [2], which took me here, where I uploaded the patch and reported back to Marc-André letting him know I had done so (and provided him with a copy of the patch). So, where exactly did I screw up, please? [2] http://sourceforge.net/tracker/? group_id=5470&atid=305470 [6] http://sourceforge.net/tracker/? group_id=5470&atid=305470 Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:47 Message: Logged In: YES user_id=21627 Patches to PEPs normally would not need to go through the patch manager. According to PEP1, you are supposed to send them directly to the PEP author in the initial discussion, or sent it as a comment to the PEP in the public discussion fora, such as comp.lang.python. The PEP author is than supposed to integrate it into the PEP - even if he disagrees with the proposal, he is somehow to record in the PEP that people have raised this opinion. Anyway, since this is Marc-Andre's PEP, I'm assigning the patch to him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 From noreply@sourceforge.net Wed Aug 8 09:43:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 01:43:42 -0700 Subject: [Patches] [ python-Patches-448841 ] Patch for PEP 249 Message-ID: Patches item #448841, was opened at 2001-08-07 10:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: M.-A. Lemburg (lemburg) Summary: Patch for PEP 249 Initial Comment: This patch is submitted to clarify the usage of the executemany() method of the Cursor class. Language is added to make it clear that use of this method for an operation which results in one or more result sets constitutes undefined behavior, and that in such a case the implementation is permitted (but not required) to raise an exception. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 01:43 Message: Logged In: YES user_id=38388 Checked in the patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 00:54 Message: Logged In: YES user_id=38388 Everything's fine Bob :-) I'll check in your patch today. Thanks. ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-08 00:26 Message: Logged In: YES user_id=291529 No problem. :->} Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 00:08 Message: Logged In: YES user_id=21627 I wasn't aware that PEP 1 actually suggests to use the patch manager; it is alright then that you did so. I had the sentence A better strategy is to encourage public feedback directly to the PEP author, who collects and integrates the comments back into the PEP. from the PEP in mind; my apologies. ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-07 22:47 Message: Logged In: YES user_id=291529 loewis: OK, I'm very confused. I originally posted the suggestion for this enhancement to the PEP to the DB-SIG, which surely qualifies as a public Python forum. A discussion ensued, I asked what the best way to submit the suggested modification would be, and Marc-André himself replied asking that I submit a patch against the PEP to SourceForge. I then read PEP1, which says, "Please use the SourceForge bug manager[6] if you want to report problems with PEPs, or better yet, the SourceForge patch manager[2] for submitting patches to PEPs." I followed the link at [2], which took me here, where I uploaded the patch and reported back to Marc-André letting him know I had done so (and provided him with a copy of the patch). So, where exactly did I screw up, please? [2] http://sourceforge.net/tracker/? group_id=5470&atid=305470 [6] http://sourceforge.net/tracker/? group_id=5470&atid=305470 Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:47 Message: Logged In: YES user_id=21627 Patches to PEPs normally would not need to go through the patch manager. According to PEP1, you are supposed to send them directly to the PEP author in the initial discussion, or sent it as a comment to the PEP in the public discussion fora, such as comp.lang.python. The PEP author is than supposed to integrate it into the PEP - even if he disagrees with the proposal, he is somehow to record in the PEP that people have raised this opinion. Anyway, since this is Marc-Andre's PEP, I'm assigning the patch to him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 From noreply@sourceforge.net Wed Aug 8 09:58:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 01:58:44 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: M.-A. Lemburg (lemburg) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 01:58 Message: Logged In: YES user_id=38388 It seems that you have replaced Py_UCS2 with "unsigned char" in the latest patch. This won't work for obvious reasons (maybe on Crays, don't know ;-). Shouldn't this have been "unsigned int" ?! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-03 16:56 Message: Logged In: YES user_id=31435 New patch attached, and back to MAL. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 22:59 Message: Logged In: YES user_id=31435 Marked Out of Date as per MAL's remark, and assigned back to me. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:39 Message: Logged In: YES user_id=38388 Tim, please resubmit the patch -- it no longer applies to the current CVS tree. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Wed Aug 8 10:05:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 02:05:33 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Wed Aug 8 10:37:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 02:37:13 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Wed Aug 8 11:19:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 03:19:15 -0700 Subject: [Patches] [ python-Patches-448261 ] OSX patches - review wanted Message-ID: Patches item #448261, was opened at 2001-08-05 15:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448261&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: OSX patches - review wanted Initial Comment: I'm posting these here because I'm not a configure-guru and I'd like someone to check that I'm doing reasonable things. The patch does three things: - Warn if you haven't specified --with-suffix and a directory "python" with lowercase p exists (you're probably on a non-case-sensitive filesystem and building python will fail) - Force --with-dyld on OSX (there is no alternative as on NextStep). - If you're building in a subdir also create the directories Mac and Mac/Python. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-08-08 03:19 Message: Logged In: YES user_id=45365 I'll get rid of the --with-dyld on Darwin, and I'll split macglue.c into two files, one for both OSX and OS9 going into Python, the other (only OS9) remaining in Mac/Python. 1 or 2 .h files will also move from Mac/Include to Include. That means that for unix-Python the whole Mac subtree will only be used for builds of extension modules. Eventually this subtree should probably be split into a section that is MacPython-only and a section that is used for both MacPython and unix-Python. --with-next-framework is definitely important on OSX, and also optional. After this patch is checked in there'll be a lot more coming that actually creates the frameworks. As to --with-next-arg: it is currently unused on OSX, but all the infrastructure is still there, so I'd say we leave it in. As to the other NeXT stuff: I haven't a clue. It's been 10 years since I saw a next machine, and that only from 2m distance. I try to be as conservative as I can, and not break NeXT support with the stuff I do for OSX, but I have no way of checking. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:34 Message: Logged In: YES user_id=21627 On --with-dyld: If --with-dyld is the only choice on the Mac, then it should not be set implicitly. Instead, support for not having it should be removed. I.e. in all places that check for with_dyld, the Darwin case should be split out, and the resulting features should be automatically activated. E.g. Darwin/*|next/*) if test "$ns_dyld" then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; fi if test "$with_next_framework" ; then LDSHARED="$LDSHARED \" fi ;; should change to Darwin/*)LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' next/*) if test "$ns_dyld" then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; fi if test "$with_next_framework" ; then LDSHARED="$LDSHARED \" fi ;; As a result, --with-dyld becomes a next-only thing. It may be that --with-next-framework is also meaningless on Darwin, in which case the support for specifying it on Darwin should be removed. So I disapprove the part of the patch that just sets with_dyld. On Mac/Python, I think the hierarchy is backwards, it should be Python/Mac instead. It also appears that only macglue.c is actually used on Darwin (I don't know whether the others are ever used). If that is the case, macglue.c should be moved to Python/, in which case the SRCDIRS change is not needed anymore, either. In any case, I think Mac should not be in SRCDIRS, since it does not contain any sources. It appears you listed it only to get Mac created before Mac/Python is created. Instead, mkdir -p should be used to create SRCDIRS. While you are at it, you should carefully review the other Next stuff whether it really applies to Darwin. E.g. why is it that we check for -f /System/Library/CoreServices/software_version Is this for Darwin only, or was there a NeXT release that had this but not /usr/lib/NextStep/software_version? If this is for Darwin only, I think the test should be removed, with the Darwin code in it. I suppose that --with-next-arch is not supported on Darwin, is it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448261&group_id=5470 From noreply@sourceforge.net Wed Aug 8 12:57:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 04:57:52 -0700 Subject: [Patches] [ python-Patches-449083 ] Use builtins to create types Message-ID: Patches item #449083, was opened at 2001-08-08 04:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449083&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Use builtins to create types Initial Comment: This patch uses a number of builtin names directly to create types.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449083&group_id=5470 From noreply@sourceforge.net Wed Aug 8 13:00:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 05:00:38 -0700 Subject: [Patches] [ python-Patches-449085 ] Exception iterators Message-ID: Patches item #449085, was opened at 2001-08-08 05:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449085&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Exception iterators Initial Comment: This patch adds an __iter__ to exceptions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449085&group_id=5470 From noreply@sourceforge.net Wed Aug 8 13:01:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 05:01:28 -0700 Subject: [Patches] [ python-Patches-449083 ] Use builtins to create types Message-ID: Patches item #449083, was opened at 2001-08-08 04:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449083&group_id=5470 >Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Use builtins to create types Initial Comment: This patch uses a number of builtin names directly to create types.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449083&group_id=5470 From noreply@sourceforge.net Wed Aug 8 13:18:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 05:18:47 -0700 Subject: [Patches] [ python-Patches-448841 ] Patch for PEP 249 Message-ID: Patches item #448841, was opened at 2001-08-07 10:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 Category: Modules Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: M.-A. Lemburg (lemburg) Summary: Patch for PEP 249 Initial Comment: This patch is submitted to clarify the usage of the executemany() method of the Cursor class. Language is added to make it clear that use of this method for an operation which results in one or more result sets constitutes undefined behavior, and that in such a case the implementation is permitted (but not required) to raise an exception. ---------------------------------------------------------------------- >Comment By: Bob Kline (bkline) Date: 2001-08-08 05:18 Message: Logged In: YES user_id=291529 Thanks very much! Bob ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 01:43 Message: Logged In: YES user_id=38388 Checked in the patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 00:54 Message: Logged In: YES user_id=38388 Everything's fine Bob :-) I'll check in your patch today. Thanks. ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-08 00:26 Message: Logged In: YES user_id=291529 No problem. :->} Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 00:08 Message: Logged In: YES user_id=21627 I wasn't aware that PEP 1 actually suggests to use the patch manager; it is alright then that you did so. I had the sentence A better strategy is to encourage public feedback directly to the PEP author, who collects and integrates the comments back into the PEP. from the PEP in mind; my apologies. ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-07 22:47 Message: Logged In: YES user_id=291529 loewis: OK, I'm very confused. I originally posted the suggestion for this enhancement to the PEP to the DB-SIG, which surely qualifies as a public Python forum. A discussion ensued, I asked what the best way to submit the suggested modification would be, and Marc-André himself replied asking that I submit a patch against the PEP to SourceForge. I then read PEP1, which says, "Please use the SourceForge bug manager[6] if you want to report problems with PEPs, or better yet, the SourceForge patch manager[2] for submitting patches to PEPs." I followed the link at [2], which took me here, where I uploaded the patch and reported back to Marc-André letting him know I had done so (and provided him with a copy of the patch). So, where exactly did I screw up, please? [2] http://sourceforge.net/tracker/? group_id=5470&atid=305470 [6] http://sourceforge.net/tracker/? group_id=5470&atid=305470 Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:47 Message: Logged In: YES user_id=21627 Patches to PEPs normally would not need to go through the patch manager. According to PEP1, you are supposed to send them directly to the PEP author in the initial discussion, or sent it as a comment to the PEP in the public discussion fora, such as comp.lang.python. The PEP author is than supposed to integrate it into the PEP - even if he disagrees with the proposal, he is somehow to record in the PEP that people have raised this opinion. Anyway, since this is Marc-Andre's PEP, I'm assigning the patch to him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 From noreply@sourceforge.net Wed Aug 8 13:19:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 05:19:11 -0700 Subject: [Patches] [ python-Patches-448841 ] Patch for PEP 249 Message-ID: Patches item #448841, was opened at 2001-08-07 10:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 Category: Modules Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: M.-A. Lemburg (lemburg) Summary: Patch for PEP 249 Initial Comment: This patch is submitted to clarify the usage of the executemany() method of the Cursor class. Language is added to make it clear that use of this method for an operation which results in one or more result sets constitutes undefined behavior, and that in such a case the implementation is permitted (but not required) to raise an exception. ---------------------------------------------------------------------- >Comment By: Bob Kline (bkline) Date: 2001-08-08 05:19 Message: Logged In: YES user_id=291529 Thanks very much! Bob ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-08 05:18 Message: Logged In: YES user_id=291529 Thanks very much! Bob ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 01:43 Message: Logged In: YES user_id=38388 Checked in the patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 00:54 Message: Logged In: YES user_id=38388 Everything's fine Bob :-) I'll check in your patch today. Thanks. ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-08 00:26 Message: Logged In: YES user_id=291529 No problem. :->} Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 00:08 Message: Logged In: YES user_id=21627 I wasn't aware that PEP 1 actually suggests to use the patch manager; it is alright then that you did so. I had the sentence A better strategy is to encourage public feedback directly to the PEP author, who collects and integrates the comments back into the PEP. from the PEP in mind; my apologies. ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2001-08-07 22:47 Message: Logged In: YES user_id=291529 loewis: OK, I'm very confused. I originally posted the suggestion for this enhancement to the PEP to the DB-SIG, which surely qualifies as a public Python forum. A discussion ensued, I asked what the best way to submit the suggested modification would be, and Marc-André himself replied asking that I submit a patch against the PEP to SourceForge. I then read PEP1, which says, "Please use the SourceForge bug manager[6] if you want to report problems with PEPs, or better yet, the SourceForge patch manager[2] for submitting patches to PEPs." I followed the link at [2], which took me here, where I uploaded the patch and reported back to Marc-André letting him know I had done so (and provided him with a copy of the patch). So, where exactly did I screw up, please? [2] http://sourceforge.net/tracker/? group_id=5470&atid=305470 [6] http://sourceforge.net/tracker/? group_id=5470&atid=305470 Bob Kline mailto:bkline@rksystems.com ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:47 Message: Logged In: YES user_id=21627 Patches to PEPs normally would not need to go through the patch manager. According to PEP1, you are supposed to send them directly to the PEP author in the initial discussion, or sent it as a comment to the PEP in the public discussion fora, such as comp.lang.python. The PEP author is than supposed to integrate it into the PEP - even if he disagrees with the proposal, he is somehow to record in the PEP that people have raised this opinion. Anyway, since this is Marc-Andre's PEP, I'm assigning the patch to him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448841&group_id=5470 From noreply@sourceforge.net Wed Aug 8 14:35:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 06:35:34 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for 'tell()' to gzip.GzipFile Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- >Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 06:35 Message: Logged In: YES user_id=71210 tell() should return the position in the uncompressed stream because gzipFile.fileobj.tell() already gives the position in the compressed stream and these are the same semantics that the GNU zlib library on which this is based uses. The file object like functions in GNU zlib support tell and seek. It seems easonable that the python wrappers for it should provide them as well. Just in case I've managed to sway your position, I am attaching a fixed patch. I had done `cvs diff gzip.py -u` instead of `cvs diff -u gzip.py` by accident. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:02 Message: Logged In: YES user_id=21627 Please use context (-c) or unified (-u) patch following the SF FAQ (http://python.sourceforge.net/sf-faq.html#patches). As for the patch itself: It seems not so clear that tell() should really give the position in the uncompressed stream; why is that more useful than the position in the compressed stream? Also, it seems that .tell() is useless without .seek. However, I pretty much doubt you can do .seek on top of zlib: to seek to a certain position, you would need the state of the compression engine at this position, no? Unless I'm missing something here, I would therefore recommend to reject this patch, and advise you to derive a class from GzipFile that has the tell semantics you desire, for use in your application. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Wed Aug 8 15:19:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 07:19:56 -0700 Subject: [Patches] [ python-Patches-448171 ] Allow jython to complete test_exceptions Message-ID: Patches item #448171, was opened at 2001-08-05 08:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448171&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow jython to complete test_exceptions Initial Comment: The behavior of continue in a try clause is a known difference between CPython and Jython. This patch will jython to skip that test. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:19 Message: Logged In: YES user_id=6380 I understand Finn's motivation: It's a known difference that won't be fixed any time soon. You don't want to have persistently failing tests in your standard test suite. Q. for Finn: does Jython balk on all three test cases, or only one? I'd prefer not to skip the test completely. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:34 Message: Logged In: YES user_id=21627 Why is it desirable for Jython to pass this test? It looks like a bug in Jython to me... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448171&group_id=5470 From noreply@sourceforge.net Wed Aug 8 15:26:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 07:26:31 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Wed Aug 8 15:28:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 07:28:18 -0700 Subject: [Patches] [ python-Patches-449083 ] Use builtins to create types Message-ID: Patches item #449083, was opened at 2001-08-08 04:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449083&group_id=5470 Category: library Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: Use builtins to create types Initial Comment: This patch uses a number of builtin names directly to create types.py. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:28 Message: Logged In: YES user_id=6380 Looks good to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449083&group_id=5470 From noreply@sourceforge.net Wed Aug 8 15:32:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 07:32:07 -0700 Subject: [Patches] [ python-Patches-449085 ] Exception iterators Message-ID: Patches item #449085, was opened at 2001-08-08 05:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449085&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Exception iterators Initial Comment: This patch adds an __iter__ to exceptions. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:32 Message: Logged In: YES user_id=6380 Hm, is this really necessary? You can iterate over an exception already using the __getitem__ method. I don't see why adding the __iter__ method makes a difference. This is only used occasionally anyway (treating an exception object as a sequence is a backwards compatibility thing dating back to the time of string exceptions). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449085&group_id=5470 From noreply@sourceforge.net Wed Aug 8 16:01:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 08:01:49 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for 'tell()' to gzip.GzipFile Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:01 Message: Logged In: YES user_id=6380 I don't see the point of supporting tell() without seek(). Why is this useful? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 06:35 Message: Logged In: YES user_id=71210 tell() should return the position in the uncompressed stream because gzipFile.fileobj.tell() already gives the position in the compressed stream and these are the same semantics that the GNU zlib library on which this is based uses. The file object like functions in GNU zlib support tell and seek. It seems easonable that the python wrappers for it should provide them as well. Just in case I've managed to sway your position, I am attaching a fixed patch. I had done `cvs diff gzip.py -u` instead of `cvs diff -u gzip.py` by accident. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:02 Message: Logged In: YES user_id=21627 Please use context (-c) or unified (-u) patch following the SF FAQ (http://python.sourceforge.net/sf-faq.html#patches). As for the patch itself: It seems not so clear that tell() should really give the position in the uncompressed stream; why is that more useful than the position in the compressed stream? Also, it seems that .tell() is useless without .seek. However, I pretty much doubt you can do .seek on top of zlib: to seek to a certain position, you would need the state of the compression engine at this position, no? Unless I'm missing something here, I would therefore recommend to reject this patch, and advise you to derive a class from GzipFile that has the tell semantics you desire, for use in your application. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Wed Aug 8 16:10:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 08:10:00 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for 'tell()' to gzip.GzipFile Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:10 Message: Logged In: YES user_id=6380 Are you offering to implement seek() as well? That would be useful then. I don't see the point of fileno(), and readinto() might not be doable without writing C code. But just seek() and tell() are a laudable goal. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:01 Message: Logged In: YES user_id=6380 I don't see the point of supporting tell() without seek(). Why is this useful? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 06:35 Message: Logged In: YES user_id=71210 tell() should return the position in the uncompressed stream because gzipFile.fileobj.tell() already gives the position in the compressed stream and these are the same semantics that the GNU zlib library on which this is based uses. The file object like functions in GNU zlib support tell and seek. It seems easonable that the python wrappers for it should provide them as well. Just in case I've managed to sway your position, I am attaching a fixed patch. I had done `cvs diff gzip.py -u` instead of `cvs diff -u gzip.py` by accident. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:02 Message: Logged In: YES user_id=21627 Please use context (-c) or unified (-u) patch following the SF FAQ (http://python.sourceforge.net/sf-faq.html#patches). As for the patch itself: It seems not so clear that tell() should really give the position in the uncompressed stream; why is that more useful than the position in the compressed stream? Also, it seems that .tell() is useless without .seek. However, I pretty much doubt you can do .seek on top of zlib: to seek to a certain position, you would need the state of the compression engine at this position, no? Unless I'm missing something here, I would therefore recommend to reject this patch, and advise you to derive a class from GzipFile that has the tell semantics you desire, for use in your application. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Wed Aug 8 16:14:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 08:14:56 -0700 Subject: [Patches] [ python-Patches-448261 ] OSX patches - review wanted Message-ID: Patches item #448261, was opened at 2001-08-05 15:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448261&group_id=5470 Category: Build Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: OSX patches - review wanted Initial Comment: I'm posting these here because I'm not a configure-guru and I'd like someone to check that I'm doing reasonable things. The patch does three things: - Warn if you haven't specified --with-suffix and a directory "python" with lowercase p exists (you're probably on a non-case-sensitive filesystem and building python will fail) - Force --with-dyld on OSX (there is no alternative as on NextStep). - If you're building in a subdir also create the directories Mac and Mac/Python. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-08-08 08:14 Message: Logged In: YES user_id=45365 Checked it in with Martin's suggestions. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-08-08 03:19 Message: Logged In: YES user_id=45365 I'll get rid of the --with-dyld on Darwin, and I'll split macglue.c into two files, one for both OSX and OS9 going into Python, the other (only OS9) remaining in Mac/Python. 1 or 2 .h files will also move from Mac/Include to Include. That means that for unix-Python the whole Mac subtree will only be used for builds of extension modules. Eventually this subtree should probably be split into a section that is MacPython-only and a section that is used for both MacPython and unix-Python. --with-next-framework is definitely important on OSX, and also optional. After this patch is checked in there'll be a lot more coming that actually creates the frameworks. As to --with-next-arg: it is currently unused on OSX, but all the infrastructure is still there, so I'd say we leave it in. As to the other NeXT stuff: I haven't a clue. It's been 10 years since I saw a next machine, and that only from 2m distance. I try to be as conservative as I can, and not break NeXT support with the stuff I do for OSX, but I have no way of checking. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 21:34 Message: Logged In: YES user_id=21627 On --with-dyld: If --with-dyld is the only choice on the Mac, then it should not be set implicitly. Instead, support for not having it should be removed. I.e. in all places that check for with_dyld, the Darwin case should be split out, and the resulting features should be automatically activated. E.g. Darwin/*|next/*) if test "$ns_dyld" then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; fi if test "$with_next_framework" ; then LDSHARED="$LDSHARED \" fi ;; should change to Darwin/*)LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' next/*) if test "$ns_dyld" then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; fi if test "$with_next_framework" ; then LDSHARED="$LDSHARED \" fi ;; As a result, --with-dyld becomes a next-only thing. It may be that --with-next-framework is also meaningless on Darwin, in which case the support for specifying it on Darwin should be removed. So I disapprove the part of the patch that just sets with_dyld. On Mac/Python, I think the hierarchy is backwards, it should be Python/Mac instead. It also appears that only macglue.c is actually used on Darwin (I don't know whether the others are ever used). If that is the case, macglue.c should be moved to Python/, in which case the SRCDIRS change is not needed anymore, either. In any case, I think Mac should not be in SRCDIRS, since it does not contain any sources. It appears you listed it only to get Mac created before Mac/Python is created. Instead, mkdir -p should be used to create SRCDIRS. While you are at it, you should carefully review the other Next stuff whether it really applies to Darwin. E.g. why is it that we check for -f /System/Library/CoreServices/software_version Is this for Darwin only, or was there a NeXT release that had this but not /usr/lib/NextStep/software_version? If this is for Darwin only, I think the test should be removed, with the Darwin code in it. I suppose that --with-next-arch is not supported on Darwin, is it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448261&group_id=5470 From noreply@sourceforge.net Wed Aug 8 16:41:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 08:41:38 -0700 Subject: [Patches] [ python-Patches-448038 ] a move function for shutil.py Message-ID: Patches item #448038, was opened at 2001-08-04 17:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448038&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: William McVey (wamcvey) Assigned to: Nobody/Anonymous (nobody) Summary: a move function for shutil.py Initial Comment: Although shutil.py has some nice copy functions but no real equivalent of mv(1). This is a very simple implimentation (as in not a whole lot of stuff has been implimented) but it's functional. Simply calls rename, and if that fails tries to copy and unlink. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:41 Message: Logged In: YES user_id=6380 This is OK, but only perpetuates the problem with this module -- it doesn't have a decent error handling strategy (prints to stdout!?!?!?!). If someone wants to put some more effort in this, I would recommend at least adding an option to copytree() to control error handling. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448038&group_id=5470 From noreply@sourceforge.net Wed Aug 8 16:57:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 08:57:13 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for 'tell()' to gzip.GzipFile Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- >Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 08:57 Message: Logged In: YES user_id=71210 Yes, I have already written seek() for GzipFile. I needed both seek() and tell() for the tarfile module I am writing. I didn't include it at first since it is more to wade through. My seek() uses the same slow procedure as zlib's gzseek. I'm attaching the updated patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:10 Message: Logged In: YES user_id=6380 Are you offering to implement seek() as well? That would be useful then. I don't see the point of fileno(), and readinto() might not be doable without writing C code. But just seek() and tell() are a laudable goal. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:01 Message: Logged In: YES user_id=6380 I don't see the point of supporting tell() without seek(). Why is this useful? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 06:35 Message: Logged In: YES user_id=71210 tell() should return the position in the uncompressed stream because gzipFile.fileobj.tell() already gives the position in the compressed stream and these are the same semantics that the GNU zlib library on which this is based uses. The file object like functions in GNU zlib support tell and seek. It seems easonable that the python wrappers for it should provide them as well. Just in case I've managed to sway your position, I am attaching a fixed patch. I had done `cvs diff gzip.py -u` instead of `cvs diff -u gzip.py` by accident. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:02 Message: Logged In: YES user_id=21627 Please use context (-c) or unified (-u) patch following the SF FAQ (http://python.sourceforge.net/sf-faq.html#patches). As for the patch itself: It seems not so clear that tell() should really give the position in the uncompressed stream; why is that more useful than the position in the compressed stream? Also, it seems that .tell() is useless without .seek. However, I pretty much doubt you can do .seek on top of zlib: to seek to a certain position, you would need the state of the compression engine at this position, no? Unless I'm missing something here, I would therefore recommend to reject this patch, and advise you to derive a class from GzipFile that has the tell semantics you desire, for use in your application. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Wed Aug 8 16:59:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 08:59:57 -0700 Subject: [Patches] [ python-Patches-449085 ] Exception iterators Message-ID: Patches item #449085, was opened at 2001-08-08 05:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449085&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Exception iterators Initial Comment: This patch adds an __iter__ to exceptions. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 08:59 Message: Logged In: YES user_id=21627 It's not necessary to have it. I guess it would give a mild difference in speed, but i haven't even measured it. I withdraw this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:32 Message: Logged In: YES user_id=6380 Hm, is this really necessary? You can iterate over an exception already using the __getitem__ method. I don't see why adding the __iter__ method makes a difference. This is only used occasionally anyway (treating an exception object as a sequence is a backwards compatibility thing dating back to the time of string exceptions). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449085&group_id=5470 From noreply@sourceforge.net Wed Aug 8 17:00:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 09:00:28 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for 'tell()' to gzip.GzipFile Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 09:00 Message: Logged In: YES user_id=6380 OK, now it makes sense. Martin, what do you think? Anybody else? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 08:57 Message: Logged In: YES user_id=71210 Yes, I have already written seek() for GzipFile. I needed both seek() and tell() for the tarfile module I am writing. I didn't include it at first since it is more to wade through. My seek() uses the same slow procedure as zlib's gzseek. I'm attaching the updated patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:10 Message: Logged In: YES user_id=6380 Are you offering to implement seek() as well? That would be useful then. I don't see the point of fileno(), and readinto() might not be doable without writing C code. But just seek() and tell() are a laudable goal. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:01 Message: Logged In: YES user_id=6380 I don't see the point of supporting tell() without seek(). Why is this useful? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 06:35 Message: Logged In: YES user_id=71210 tell() should return the position in the uncompressed stream because gzipFile.fileobj.tell() already gives the position in the compressed stream and these are the same semantics that the GNU zlib library on which this is based uses. The file object like functions in GNU zlib support tell and seek. It seems easonable that the python wrappers for it should provide them as well. Just in case I've managed to sway your position, I am attaching a fixed patch. I had done `cvs diff gzip.py -u` instead of `cvs diff -u gzip.py` by accident. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:02 Message: Logged In: YES user_id=21627 Please use context (-c) or unified (-u) patch following the SF FAQ (http://python.sourceforge.net/sf-faq.html#patches). As for the patch itself: It seems not so clear that tell() should really give the position in the uncompressed stream; why is that more useful than the position in the compressed stream? Also, it seems that .tell() is useless without .seek. However, I pretty much doubt you can do .seek on top of zlib: to seek to a certain position, you would need the state of the compression engine at this position, no? Unless I'm missing something here, I would therefore recommend to reject this patch, and advise you to derive a class from GzipFile that has the tell semantics you desire, for use in your application. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Wed Aug 8 17:02:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 09:02:26 -0700 Subject: [Patches] [ python-Patches-449083 ] Use builtins to create types Message-ID: Patches item #449083, was opened at 2001-08-08 04:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449083&group_id=5470 Category: library Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Use builtins to create types Initial Comment: This patch uses a number of builtin names directly to create types.py. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 09:02 Message: Logged In: YES user_id=21627 Committed as types.py 1.18. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:28 Message: Logged In: YES user_id=6380 Looks good to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449083&group_id=5470 From noreply@sourceforge.net Wed Aug 8 17:12:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 09:12:13 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for 'tell()' to gzip.GzipFile Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 09:12 Message: Logged In: YES user_id=21627 The patch looks good to me now, as well. I was about to check it in when I remembered one thing: Would you volunteer to write documentation for the new methods, or otherwise update libgzip.tex? Don't worry about the tex mechanics too much; I will adjust the markup before checking it in - but it would help if you could draft the text. Ideally, test cases would be appreciated as well... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 09:00 Message: Logged In: YES user_id=6380 OK, now it makes sense. Martin, what do you think? Anybody else? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 08:57 Message: Logged In: YES user_id=71210 Yes, I have already written seek() for GzipFile. I needed both seek() and tell() for the tarfile module I am writing. I didn't include it at first since it is more to wade through. My seek() uses the same slow procedure as zlib's gzseek. I'm attaching the updated patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:10 Message: Logged In: YES user_id=6380 Are you offering to implement seek() as well? That would be useful then. I don't see the point of fileno(), and readinto() might not be doable without writing C code. But just seek() and tell() are a laudable goal. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:01 Message: Logged In: YES user_id=6380 I don't see the point of supporting tell() without seek(). Why is this useful? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 06:35 Message: Logged In: YES user_id=71210 tell() should return the position in the uncompressed stream because gzipFile.fileobj.tell() already gives the position in the compressed stream and these are the same semantics that the GNU zlib library on which this is based uses. The file object like functions in GNU zlib support tell and seek. It seems easonable that the python wrappers for it should provide them as well. Just in case I've managed to sway your position, I am attaching a fixed patch. I had done `cvs diff gzip.py -u` instead of `cvs diff -u gzip.py` by accident. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:02 Message: Logged In: YES user_id=21627 Please use context (-c) or unified (-u) patch following the SF FAQ (http://python.sourceforge.net/sf-faq.html#patches). As for the patch itself: It seems not so clear that tell() should really give the position in the uncompressed stream; why is that more useful than the position in the compressed stream? Also, it seems that .tell() is useless without .seek. However, I pretty much doubt you can do .seek on top of zlib: to seek to a certain position, you would need the state of the compression engine at this position, no? Unless I'm missing something here, I would therefore recommend to reject this patch, and advise you to derive a class from GzipFile that has the tell semantics you desire, for use in your application. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Wed Aug 8 17:25:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 09:25:51 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: M.-A. Lemburg (lemburg) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-08 09:25 Message: Logged In: YES user_id=31435 The switch to unsigned char is coupled with code to read and write one byte at a time; it should work fine on any box where an unsigned char is 8 bits (incl. Palm Pilots and Crays); and on any box where it's larger than 8 bits (I don't of any such box) provided input routines arrange to store only 8 bits per native machine byte. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 01:58 Message: Logged In: YES user_id=38388 It seems that you have replaced Py_UCS2 with "unsigned char" in the latest patch. This won't work for obvious reasons (maybe on Crays, don't know ;-). Shouldn't this have been "unsigned int" ?! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-03 16:56 Message: Logged In: YES user_id=31435 New patch attached, and back to MAL. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 22:59 Message: Logged In: YES user_id=31435 Marked Out of Date as per MAL's remark, and assigned back to me. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:39 Message: Logged In: YES user_id=38388 Tim, please resubmit the patch -- it no longer applies to the current CVS tree. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Wed Aug 8 18:39:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 10:39:58 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for 'tell()' to gzip.GzipFile Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- >Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 10:39 Message: Logged In: YES user_id=71210 I've attached a new patch for gzip.py with tests for the new functionality. It also includes a few other minor changes I did while writing the tests. I've also attached a patch for libgzip.tex. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 09:12 Message: Logged In: YES user_id=21627 The patch looks good to me now, as well. I was about to check it in when I remembered one thing: Would you volunteer to write documentation for the new methods, or otherwise update libgzip.tex? Don't worry about the tex mechanics too much; I will adjust the markup before checking it in - but it would help if you could draft the text. Ideally, test cases would be appreciated as well... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 09:00 Message: Logged In: YES user_id=6380 OK, now it makes sense. Martin, what do you think? Anybody else? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 08:57 Message: Logged In: YES user_id=71210 Yes, I have already written seek() for GzipFile. I needed both seek() and tell() for the tarfile module I am writing. I didn't include it at first since it is more to wade through. My seek() uses the same slow procedure as zlib's gzseek. I'm attaching the updated patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:10 Message: Logged In: YES user_id=6380 Are you offering to implement seek() as well? That would be useful then. I don't see the point of fileno(), and readinto() might not be doable without writing C code. But just seek() and tell() are a laudable goal. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:01 Message: Logged In: YES user_id=6380 I don't see the point of supporting tell() without seek(). Why is this useful? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 06:35 Message: Logged In: YES user_id=71210 tell() should return the position in the uncompressed stream because gzipFile.fileobj.tell() already gives the position in the compressed stream and these are the same semantics that the GNU zlib library on which this is based uses. The file object like functions in GNU zlib support tell and seek. It seems easonable that the python wrappers for it should provide them as well. Just in case I've managed to sway your position, I am attaching a fixed patch. I had done `cvs diff gzip.py -u` instead of `cvs diff -u gzip.py` by accident. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:02 Message: Logged In: YES user_id=21627 Please use context (-c) or unified (-u) patch following the SF FAQ (http://python.sourceforge.net/sf-faq.html#patches). As for the patch itself: It seems not so clear that tell() should really give the position in the uncompressed stream; why is that more useful than the position in the compressed stream? Also, it seems that .tell() is useless without .seek. However, I pretty much doubt you can do .seek on top of zlib: to seek to a certain position, you would need the state of the compression engine at this position, no? Unless I'm missing something here, I would therefore recommend to reject this patch, and advise you to derive a class from GzipFile that has the tell semantics you desire, for use in your application. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Wed Aug 8 18:56:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 10:56:41 -0700 Subject: [Patches] [ python-Patches-448171 ] Allow jython to complete test_exceptions Message-ID: Patches item #448171, was opened at 2001-08-05 08:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448171&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow jython to complete test_exceptions Initial Comment: The behavior of continue in a try clause is a known difference between CPython and Jython. This patch will jython to skip that test. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-08-08 10:56 Message: Logged In: YES user_id=4201 Jython failed all three, but when I double checked, I see that two of them is because the wording of the exception text is a little different. I'll fix the wording and come up with a new patch that only skips the first of the tests on jython. Until then, I'll close the report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:19 Message: Logged In: YES user_id=6380 I understand Finn's motivation: It's a known difference that won't be fixed any time soon. You don't want to have persistently failing tests in your standard test suite. Q. for Finn: does Jython balk on all three test cases, or only one? I'd prefer not to skip the test completely. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:34 Message: Logged In: YES user_id=21627 Why is it desirable for Jython to pass this test? It looks like a bug in Jython to me... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448171&group_id=5470 From noreply@sourceforge.net Wed Aug 8 21:26:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 13:26:48 -0700 Subject: [Patches] [ python-Patches-422471 ] Install IDLE Help File Message-ID: Patches item #422471, was opened at 2001-05-08 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422471&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Install IDLE Help File Initial Comment: Installing Idle to site-packages via Distutils does not copy the Idle help.txt file. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:26 Message: Logged In: YES user_id=21627 Thanks for your patch, I have committed it as setup.y 1.3. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-07-13 08:42 Message: Logged In: YES user_id=149084 I had uploaded twice because the first time I had the wrong MIME type. The second (lower) file is text/plain. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422471&group_id=5470 From noreply@sourceforge.net Wed Aug 8 21:32:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 13:32:20 -0700 Subject: [Patches] [ python-Patches-428326 ] Timer class for threading Message-ID: Patches item #428326, was opened at 2001-05-29 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: Timer class for threading Initial Comment: The Timer class allows you to schedule an action to happen at some time in the future, using a thread. For example: def f(): print "30 seconds have passed" t = Timer(30.0, f) t.start() # after 30 seconds f will be called try: # .... other stuff except SystemExit: t.cancel() # cancel the timer since we are shutting down It allows passing arguments and keyword arguments to the function that is called. It also allows *cancelling* the timer. That is, if the timer is still waiting, we can tell it to stop its operation. Why should this be in the standard library? 1. Timers are a standard, useful programming idiom. 2. It can be used as an example of how to: a. create subclasses of threading.Thread b. make threads that can be "stopped" If this patch is approved I will then write documentation. I'm not sure how to go about writing tests for it. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:32 Message: Logged In: YES user_id=21627 I'm in favour of approving this patch, as an extension to the threading module. Are you willing to draft a patch to the documentation (libthreading.tex) as well? Ideally, there would also be a set of regression tests in a test_threading file; it would be acceptable if this only tests your feature for the moment. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 09:40 Message: Logged In: YES user_id=32065 There was a licensing discussion on python-dev which no one bothered to CC me on :). Yes, this can be relicensed under the PSF license. I suggest someone write up some sort of guidelines for submitted patches and improvement explain the whole licensing and copyright issues. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 02:16 Message: Logged In: YES user_id=32065 OK, I'm un-withdrawing this patch. Just had to get things straight with our lawyer. The patch is released under the following license (the X11 license with 4 extra paragraphs of disclaimers :): http://www.zoteca.com/opensource/LICENSE.txt ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-29 09:45 Message: Logged In: YES user_id=32065 I'm withdrawing this patch for a short period of time for non-technical reasons, hopefully I can put it back soon. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 From noreply@sourceforge.net Wed Aug 8 21:43:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 13:43:45 -0700 Subject: [Patches] [ python-Patches-430706 ] Persistent connections in BaseHTTPServer Message-ID: Patches item #430706, was opened at 2001-06-06 08:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) Assigned to: Nobody/Anonymous (nobody) Summary: Persistent connections in BaseHTTPServer Initial Comment: This patch provides HTTP/1.1 persistent connection support in BaseHTTPServer.py. It is not enabled by default (for backwards compatibility) because Content-Length headers must be supplied for persistent connections to work correctly. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:43 Message: Logged In: YES user_id=21627 I haven't studied the patch in detail, yet, but I have a few comments on the style: - there is no need to quote all authors of the RFC. Also, the reference to long-ago expired HTTP draft should go; just replace it with a single reference to the RFC number (giving an URL for the RFC might be convenient) - Where is the documentation? A patch to Doc/lib/libbasehttp.tex would be appreciated. If you don't speak TeX, don't worry: Just write plain text, we'll do the mark-up. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 From noreply@sourceforge.net Wed Aug 8 21:45:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 13:45:39 -0700 Subject: [Patches] [ python-Patches-433537 ] better cross-compilation support Message-ID: Patches item #433537, was opened at 2001-06-15 12:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=433537&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: michael shiplett (walrusmonkey) >Assigned to: Martin v. Löwis (loewis) Summary: better cross-compilation support Initial Comment: configure.in uses AC_TRY_RUN in several places without allowing for cached values to allow for cross-compilation. this patch uses the same approach as other parts of configure.in use. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:45 Message: Logged In: YES user_id=21627 Looks good to me; I'll review it in detail and check it in unless I find problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-28 11:24 Message: Logged In: NO Useful patch. I used it to compile python 2.0.1 for the Agenda VR3 PDA. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=433537&group_id=5470 From noreply@sourceforge.net Wed Aug 8 21:53:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 13:53:59 -0700 Subject: [Patches] [ python-Patches-428326 ] Timer class for threading Message-ID: Patches item #428326, was opened at 2001-05-29 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: Timer class for threading Initial Comment: The Timer class allows you to schedule an action to happen at some time in the future, using a thread. For example: def f(): print "30 seconds have passed" t = Timer(30.0, f) t.start() # after 30 seconds f will be called try: # .... other stuff except SystemExit: t.cancel() # cancel the timer since we are shutting down It allows passing arguments and keyword arguments to the function that is called. It also allows *cancelling* the timer. That is, if the timer is still waiting, we can tell it to stop its operation. Why should this be in the standard library? 1. Timers are a standard, useful programming idiom. 2. It can be used as an example of how to: a. create subclasses of threading.Thread b. make threads that can be "stopped" If this patch is approved I will then write documentation. I'm not sure how to go about writing tests for it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 13:53 Message: Logged In: YES user_id=6380 I like it too. But I don't want itamar's license anywhere in the distribution -- too wordy. I agree that the PSF should clear up the licensing situation; we're working on that but it's slow going (nobody likes this work :-( ). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:32 Message: Logged In: YES user_id=21627 I'm in favour of approving this patch, as an extension to the threading module. Are you willing to draft a patch to the documentation (libthreading.tex) as well? Ideally, there would also be a set of regression tests in a test_threading file; it would be acceptable if this only tests your feature for the moment. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 09:40 Message: Logged In: YES user_id=32065 There was a licensing discussion on python-dev which no one bothered to CC me on :). Yes, this can be relicensed under the PSF license. I suggest someone write up some sort of guidelines for submitted patches and improvement explain the whole licensing and copyright issues. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 02:16 Message: Logged In: YES user_id=32065 OK, I'm un-withdrawing this patch. Just had to get things straight with our lawyer. The patch is released under the following license (the X11 license with 4 extra paragraphs of disclaimers :): http://www.zoteca.com/opensource/LICENSE.txt ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-29 09:45 Message: Logged In: YES user_id=32065 I'm withdrawing this patch for a short period of time for non-technical reasons, hopefully I can put it back soon. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 From noreply@sourceforge.net Wed Aug 8 21:57:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 13:57:06 -0700 Subject: [Patches] [ python-Patches-433537 ] better cross-compilation support Message-ID: Patches item #433537, was opened at 2001-06-15 12:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=433537&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: michael shiplett (walrusmonkey) Assigned to: Martin v. Löwis (loewis) Summary: better cross-compilation support Initial Comment: configure.in uses AC_TRY_RUN in several places without allowing for cached values to allow for cross-compilation. this patch uses the same approach as other parts of configure.in use. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 13:57 Message: Logged In: YES user_id=6380 I appreciate this work! Note that it currently doesn't apply cleanly. configure.in is always changing... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:45 Message: Logged In: YES user_id=21627 Looks good to me; I'll review it in detail and check it in unless I find problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-28 11:24 Message: Logged In: NO Useful patch. I used it to compile python 2.0.1 for the Agenda VR3 PDA. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=433537&group_id=5470 From noreply@sourceforge.net Thu Aug 9 03:14:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 19:14:10 -0700 Subject: [Patches] [ python-Patches-449367 ] HTTPS client authentication in httplib Message-ID: Patches item #449367, was opened at 2001-08-08 19:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449367&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: George Yang (gyang) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPS client authentication in httplib Initial Comment: HTTPS is different from HTTP only by: --connection_class In HTTP.__Init__: the old code use self._connection_class(host, port) It fails to pass the x509 argument to the HTTPSConnection, which makes SSL client authentication fails. So, it should be self._connection_class(host, port, **x509) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449367&group_id=5470 From newsreport@stockrage.com Thu Aug 9 05:41:55 2001 From: newsreport@stockrage.com (newsreport@stockrage.com) Date: Wed, 8 Aug 2001 23:41:55 -0500 Subject: [Patches] SPECIAL INVESTMENT REPORT on CMNW Message-ID: <200108090441.XAA12651@ns1.canadawebhouse.com> SPECIAL INVESTMENT REPORT on CMNW IMPORTANT MESSAGE FROM SENDER!
To subscribe to our mailing list, go to www.stockrage.com to apply at our online form.

SPECIAL INVESTMENT REPORT

COMMUNICATENOW.COM. - (BB:CMNW) - $1.15

Common Stock Authorized:100,000,000
Common Stock Issued:22,998,820

 The “dot-com” that’s Not

Company Description: CommunicateNow.com Inc. and its wholly owned subsidiaries, bizfinders.com™ and Cellular Directory Assistance began as the dream child of David Hancock, President and CEO and Dennis Bash, Vice President of Operations and Technology while they were still working for Wilsonart International, a billion dollar corporation which we all know as the producer of the kitchen counter top materials.  “It was time for a change in my life,” recounts Hancock.  “I wanted to do something different, something innovative.  I wanted to develop a product that I could sell to every business in the world, regardless of their size or level of sophistication.” 

Bizfinders.com™: From this desire, bizfinders.com™ was born.  Bizfinders.com™ is an Internet directory of businesses throughout the United States.  The directory provides a businesses’ name, address, telephone number, mapping feature, and a Net2 phone link™ with each listing.  The difference between bizfinders.com™ and any other type of business directory is that the sales representatives, who sell the Internet advertising that enhances the businesses’ listing on the directory, meet their clients face to face, build the ads on site and to the customer’s exact specifications. This philosophy of doing business comes from CEO, David Hancock’s own extensive sales and marketing experience in the United States and abroad. 

While responsible for technical sales at Wilsonart International, Mr. Hancock successfully sold laminate in many of the 140 countries serviced by Wilsonart International using the tried and true, “Old Fashioned Style” of doing business; the sleeves rolled up, door-to-door direct marketing approach.  Because of this “back-to-the basics” style, Mr. Hancock was extremely successful in some of the most unsophisticated markets, including China

When it comes to bizfinders.com™ , the same philosophy applies. “We are a ‘brick-and-mortar’ dot-com.  Unlike that mysterious voice on the end of a phone line or unseen email respondent that many consumers are forced to deal with when it comes to advertising on the Internet, we are out there on the street.  We meet with our clients, at their place of business, at a time that is convenient for them.  Old-fashioned principles, old-fashioned customer service, in an ever increasingly “techno” society – that’s what makes us different.”

An ad on bizfinders.com™ provides digital images of the business, text areas to describe the business and its services, coupon features, email links, and web links in as little as 24 hours after purchase.  Another exciting feature is that the electronic display ad can be printed from any home or business computer and used as a flier, mailer, or brochure.  “Many small business owners can not afford the costs of printing promotional materials for their businesses.  With a simple click of the mouse, beautiful, full color ads can be printed out in any quantity for the cost of the paper and an ink cartridge.”  said Dennis Bash, who has been the brains behind the creation of the company’s software program.

“We wanted to provide the small business owner the opportunity to advertise on the Internet.  Major companies and corporations have their own web sites, spend hundreds of thousands of dollars developing these sites, and employ their own webmasters.  The typical small business owner does not have the time, the money, nor the expertise to do so.  We try to level the playing field a bit by providing Internet advertising that is less expensive than the typical yellow pages ad and gives so much more for the money.” Bash stated.

bizfinders.com™ brings Internet advertising within reach for the ordinary business owner while providing them with global opportunities for exposure.  Due to the large international and Asian contacts that Mr. Hancock made while working in the laminate industry, bizfinders.com™’s business plan calls for them to move into China within the first quarter of next year.  “Anyone in China will have the same opportunity to advertise and receive the benefits from Internet exposure that we afford our customers here in the United States.  Even better, those in China who access our database will have direct exposure to the end user of many of their products, bypassing the typical “middle-man”. In turn, U.S. businesses and consumers will have direct exposure to manufacturers and their capabilities.” Mr. Hancock said.

bizfinders.com™ is a wholly owned subsidiary of CommunicateNow.com Inc. which started trading in May, OTCBB symbol CMNW.  “We started trading long before anyone expected us to.  It is almost unheard of for a company to be taken public in five short months, but we did it through careful planning, long hours, and a dedicated staff.  While we are continually in the development stage when it comes to CommunicateNow.com Inc., bizfinders.com™ is our main focus at this time.” stated Mr. Hancock.

bizfinders.com™ recently announced their appointment of the Southern District Sales Manager, Mr. Roger Petter and have brought on board Mr. Ruben Trevino as Director of Sales, North America.  The Central Texas, Houston, and Rio Grande Valley markets have been launched and the launch of the San Antonio market is expected later this summer.

Cellular Directory Assistance: The second division of CMNW is Cellular Directory Assistance Operations. Millions of cell phones all over the world, but how do you find that one important cell phone number for that person with whom you just have to get in touch this very minute?  The answer was to create a worldwide cell phone database that could be turned into”Directory Assistance” for cell phones!  Anyone, anywhere, anytime, could call this cellular directory assistance, and for a fee, obtain the number of the person they are trying to reach.

To date there is no directory, and therefore no directory service assistance provider for the over 84 million cell phones and estimated fax machines.  China has an estimated 30 million cell phones with a projected growth to over 100 million cell phones by 2003.  Additionally, China represents an incredible opportunity as a country ready to be introduced to Internet Technology.

In a recent interview with StreamingNews.net, President and CEO, David Hancock projected that worldwide cellular database should be able to established within a 4-8 year time period.  To listen to the entire interview, the following website can be accessed at: http://www.streamingnews.net.

 

BUSINESS GROWTH: Since Jan. 1, 2001 approximately 5,100 new businesses listings have been added to the bizfinders.com™ database including fax numbers, web addresses, email addresses, and the coveted cell phone numbers. CommunicateNow.com Inc. plans to develop additional databases using this information to establish a worldwide cell phone database and directory.  In 2006 it is forecast that there will be 1.79 billion users of cellular services worldwide.  Alex Green, a senior analyst for IMS, says that by 2006, increases in users in developed countries are forecast to have started to peak. However, take up of cellular in less-developed countries, such as China, and regular handset replacements by users worldwide will mean that the market for cellular terminals will continue to experience significant growth.  The cell phone directory is designed to be a pay-per-access directory thereby allowing CommunicateNow.com Inc. to enter into the $3 billion directory assistance market.

On June 15, 2001, The Cellular Telecommunications & Internet Association announced it signed a Memorandum of Understanding with the Chinese Institute of Communications (CIC), the pre-eminent telecommunications trade association in China. The agreement, signed in Beijing, recognizes that, “a close cooperative relationship between the two organizations will contribute to the sound growth of the wireless communications industries of the United States and China, the two largest wireless markets in the world.”

With five million new subscribers per month the size of the Chinese wireless industry will soon pass that of North America,” said Tom Wheeler, President and CEO of CTIA. “This agreement establishes strong cooperative ties between these two powerhouse markets and pledges that CIC and CTIA will work to build successful relationships between the carriers and suppliers of the two countries. It is the foundation for opening even more doors and advancing the wireless industry to benefit both regions[1][1]

 

The Cellular industry has grown dramatically.  There were 92,000 subscribers in 1984, as compared with almost 70 million as of December 1998.  CTIA reports that as of January 2000 there were 83,823,071 users in the United States and estimates there are over 200 million users worldwide.[2][2]  China has an estimated 30 million[3][3] cell phones with a projected growth of over 100 million cell phones by 2003.

 

Once the database of cellular numbers is captured, a 3% daily response rate to the cell phone directory assistance service (3% is the minimum typical response rate to an advertised offer) would give the company approximately 6 million revenue generating data requests per day, approximately 180 million revenue generating data requests per month, and approximately 2.1 billion revenue generating data requests per year.

 

CommunicateNow.com Inc. plans to make cellular directory assistance available worldwide so that soon every cellular phone, no matter their location will truly be as accessible as “What Country Please…”

 

For more information about CommunicateNow.com Inc., visit their web site at: http://www.communicate-now-usa.com 


 
DISCLAIMER
This material is being provided by stockrage.com, an electronic newsletter paid for publishing the information contained in this report. stockrage.com has been paid a consideration of $20,000 (US) by a third party as payment for the publication of the information contained in this report. The information contained in this publication is for informational purposes only, and not to be construed as an offer to sell or solicitation of an offer to buy any security. Please be advised that CommunicateNow.Com Inc. securities may not be available for sale to persons in certain states where CommunicateNow.Com Inc. is not licensed to sell securities. stockrage.com makes no representation or warrant relating to the validity of the facts presented nor does stockrage.com represent or warrant that all material facts necessary to make an investment decision are presented above. All statements of opinions are those of stockrage.com. stockrage.com relies exclusively on information gathered from public filings on featured companies, as well as, in certain circumstances, interviews conducted by stockrage.com of management of featured companies. Investors should not rely solely on the information contained in this publication. Rather, investors should use the information contained in this publication as a starting point for conducting additional research on the featured companies in order to allow the investor to form his or her own opinion regarding the featured companies. Factual statements contained in this publication are made as of the date stated and they are subject to change without notice. stockrage.com is not a registered investment adviser, broker or a dealer. Investment in the companies reviewed is speculative and extremely high-risk and may result in the loss of some or all of any investment made in CommunicateNow.Com Inc. Projections of future financial results are provided solely by CommunicateNow.Com Inc. No assurances are given that CommunicateNow.Com Inc. will achieve said projections. This publication contains forward-looking statements that are subject to risk and uncertainties that could cause results to differ materially from those set forth in the forward-looking statements. These forward-looking statements represent the judgment of CommunicateNow.Com Inc. as of the date of this publication. CommunicateNow.Com Inc. disclaims any intent or obligation to update these forward-looking statements.

 

 

IMPORTANT MESSAGE!

This message is sent in compliance of the new e-mail bill section 301. Per section 301, Paragraph (a) (2) (C) of S. 1618, further transmissions to you by the sender of this e-mail will be stopped at no cost to you. This message is not intended for residents in the state of WA, NV, CA & VA. Screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia or California resident please remove yourself. We respect all removal requests.

To discontinue receipt of further notice and to be removed from our database, please go to the bottom of this email and click on the link to unsubscribe. Any attempts to disrupt the removal e-mail address etc., will not allow us to be able to retrieve and process the removal requests.

---------------------------------------------------------------------------
To be unsubscribed from the mailing list, simply click on the link below:
Unsubscribe patches@python.org


From noreply@sourceforge.net Thu Aug 9 09:34:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 01:34:50 -0700 Subject: [Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile Message-ID: Patches item #448474, was opened at 2001-08-06 11:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for 'tell()' to gzip.GzipFile Initial Comment: The GzipFile class is missing a couple important attributes that normal fileobjs expose(tell, seek, fileno, readinto). tell() is a trivial one that I really needed for a project, so I added. Here's the patch against current cvs(8/6/01) If this is seen as a useful addition, let me know, and I will do the rest. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-09 01:34 Message: Logged In: YES user_id=21627 I've committed this patch as gzip.py 1.23, libgzip.tex 1.13 and test_gzip.py 1.6. I made a few slight modifications, such as moving the text into test_gzip, and fixing an f.read into self.read. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 10:39 Message: Logged In: YES user_id=71210 I've attached a new patch for gzip.py with tests for the new functionality. It also includes a few other minor changes I did while writing the tests. I've also attached a patch for libgzip.tex. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 09:12 Message: Logged In: YES user_id=21627 The patch looks good to me now, as well. I was about to check it in when I remembered one thing: Would you volunteer to write documentation for the new methods, or otherwise update libgzip.tex? Don't worry about the tex mechanics too much; I will adjust the markup before checking it in - but it would help if you could draft the text. Ideally, test cases would be appreciated as well... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 09:00 Message: Logged In: YES user_id=6380 OK, now it makes sense. Martin, what do you think? Anybody else? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 08:57 Message: Logged In: YES user_id=71210 Yes, I have already written seek() for GzipFile. I needed both seek() and tell() for the tarfile module I am writing. I didn't include it at first since it is more to wade through. My seek() uses the same slow procedure as zlib's gzseek. I'm attaching the updated patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:10 Message: Logged In: YES user_id=6380 Are you offering to implement seek() as well? That would be useful then. I don't see the point of fileno(), and readinto() might not be doable without writing C code. But just seek() and tell() are a laudable goal. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:01 Message: Logged In: YES user_id=6380 I don't see the point of supporting tell() without seek(). Why is this useful? ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-08 06:35 Message: Logged In: YES user_id=71210 tell() should return the position in the uncompressed stream because gzipFile.fileobj.tell() already gives the position in the compressed stream and these are the same semantics that the GNU zlib library on which this is based uses. The file object like functions in GNU zlib support tell and seek. It seems easonable that the python wrappers for it should provide them as well. Just in case I've managed to sway your position, I am attaching a fixed patch. I had done `cvs diff gzip.py -u` instead of `cvs diff -u gzip.py` by accident. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:02 Message: Logged In: YES user_id=21627 Please use context (-c) or unified (-u) patch following the SF FAQ (http://python.sourceforge.net/sf-faq.html#patches). As for the patch itself: It seems not so clear that tell() should really give the position in the uncompressed stream; why is that more useful than the position in the compressed stream? Also, it seems that .tell() is useless without .seek. However, I pretty much doubt you can do .seek on top of zlib: to seek to a certain position, you would need the state of the compression engine at this position, no? Unless I'm missing something here, I would therefore recommend to reject this patch, and advise you to derive a class from GzipFile that has the tell semantics you desire, for use in your application. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470 From noreply@sourceforge.net Thu Aug 9 11:32:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 03:32:48 -0700 Subject: [Patches] [ python-Patches-433537 ] better cross-compilation support Message-ID: Patches item #433537, was opened at 2001-06-15 12:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=433537&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: michael shiplett (walrusmonkey) Assigned to: Martin v. Löwis (loewis) Summary: better cross-compilation support Initial Comment: configure.in uses AC_TRY_RUN in several places without allowing for cached values to allow for cross-compilation. this patch uses the same approach as other parts of configure.in use. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-09 03:32 Message: Logged In: YES user_id=21627 Committed as configure.in 1.241, configure 1.231. The USABLE_WCHAR_T test is gone now, so that chunk doesn't apply anymore. I think a few additional AC_TRY_RUNs have been added, so we'd appreciate if you could provide further corrrections. Also, if you have a way to kill the autoconf messages AC_TRY_RUN called without default to allow cross compiling that would be much appreciated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 13:57 Message: Logged In: YES user_id=6380 I appreciate this work! Note that it currently doesn't apply cleanly. configure.in is always changing... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:45 Message: Logged In: YES user_id=21627 Looks good to me; I'll review it in detail and check it in unless I find problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-28 11:24 Message: Logged In: NO Useful patch. I used it to compile python 2.0.1 for the Agenda VR3 PDA. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=433537&group_id=5470 From noreply@sourceforge.net Thu Aug 9 11:59:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 03:59:00 -0700 Subject: [Patches] [ python-Patches-449444 ] MimeWriter: add RFC-required header Message-ID: Patches item #449444, was opened at 2001-08-09 03:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449444&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Strasser (strasser) Assigned to: Nobody/Anonymous (nobody) Summary: MimeWriter: add RFC-required header Initial Comment: RFC 1521 states that Internet messages (multi-part?) must include the header "MIME-Version: 1.0". Many mail agents ignore its absence but some do not. I have added this header to the __init__ method of MimeWriter. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449444&group_id=5470 From noreply@sourceforge.net Thu Aug 9 12:01:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 04:01:47 -0700 Subject: [Patches] [ python-Patches-449444 ] MimeWriter: add RFC-required header Message-ID: Patches item #449444, was opened at 2001-08-09 03:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449444&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Strasser (strasser) Assigned to: Nobody/Anonymous (nobody) Summary: MimeWriter: add RFC-required header Initial Comment: RFC 1521 states that Internet messages (multi-part?) must include the header "MIME-Version: 1.0". Many mail agents ignore its absence but some do not. I have added this header to the __init__ method of MimeWriter. ---------------------------------------------------------------------- >Comment By: Michael Strasser (strasser) Date: 2001-08-09 04:01 Message: Logged In: YES user_id=37262 I forgot to attach the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449444&group_id=5470 From noreply@sourceforge.net Thu Aug 9 13:25:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 05:25:00 -0700 Subject: [Patches] [ python-Patches-437683 ] Improve h2py Message-ID: Patches item #437683, was opened at 2001-07-01 01:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=437683&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Improve h2py Initial Comment: This patch changes h2py in the following ways: - use re instead of regex - if multiple header files are processed simultaneously which include each other, the corresponding modules import each other. Specifically, if h2py is invoked with sys/types.h first, later header files won't contain the complete contents of TYPES.py. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-09 05:25 Message: Logged In: YES user_id=21627 Committed as h2py 1.13. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=437683&group_id=5470 From noreply@sourceforge.net Thu Aug 9 14:25:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 06:25:59 -0700 Subject: [Patches] [ python-Patches-449367 ] HTTPS client authentication in httplib Message-ID: Patches item #449367, was opened at 2001-08-08 19:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449367&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: George Yang (gyang) >Assigned to: Greg Stein (gstein) Summary: HTTPS client authentication in httplib Initial Comment: HTTPS is different from HTTP only by: --connection_class In HTTP.__Init__: the old code use self._connection_class(host, port) It fails to pass the x509 argument to the HTTPSConnection, which makes SSL client authentication fails. So, it should be self._connection_class(host, port, **x509) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 06:25 Message: Logged In: YES user_id=6380 Greg, what he says seems to make sense, but I dun't understand the code enough -- and I thought that https:// URLs actually worked, so I'm not sure when they don't work. Can you review the patch and check it in if it's right? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449367&group_id=5470 From noreply@sourceforge.net Thu Aug 9 14:27:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 06:27:07 -0700 Subject: [Patches] [ python-Patches-449444 ] MimeWriter: add RFC-required header Message-ID: Patches item #449444, was opened at 2001-08-09 03:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449444&group_id=5470 >Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Strasser (strasser) Assigned to: Barry Warsaw (bwarsaw) Summary: MimeWriter: add RFC-required header Initial Comment: RFC 1521 states that Internet messages (multi-part?) must include the header "MIME-Version: 1.0". Many mail agents ignore its absence but some do not. I have added this header to the __init__ method of MimeWriter. ---------------------------------------------------------------------- Comment By: Michael Strasser (strasser) Date: 2001-08-09 04:01 Message: Logged In: YES user_id=37262 I forgot to attach the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449444&group_id=5470 From noreply@sourceforge.net Thu Aug 9 14:26:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 06:26:54 -0700 Subject: [Patches] [ python-Patches-449444 ] MimeWriter: add RFC-required header Message-ID: Patches item #449444, was opened at 2001-08-09 03:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449444&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Strasser (strasser) >Assigned to: Barry Warsaw (bwarsaw) Summary: MimeWriter: add RFC-required header Initial Comment: RFC 1521 states that Internet messages (multi-part?) must include the header "MIME-Version: 1.0". Many mail agents ignore its absence but some do not. I have added this header to the __init__ method of MimeWriter. ---------------------------------------------------------------------- Comment By: Michael Strasser (strasser) Date: 2001-08-09 04:01 Message: Logged In: YES user_id=37262 I forgot to attach the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449444&group_id=5470 From noreply@sourceforge.net Thu Aug 9 15:51:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 07:51:04 -0700 Subject: [Patches] [ python-Patches-401229 ] Optional memory profiler Message-ID: Patches item #401229, was opened at 2000-08-18 23:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401229&group_id=5470 Category: core (C code) Group: None Status: Open >Resolution: Out of Date >Priority: 3 Submitted By: Vladimir Marangozov (marangoz) Assigned to: Jeremy Hylton (jhylton) Summary: Optional memory profiler Initial Comment: ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-08-09 07:51 Message: Logged In: YES user_id=31392 I had the impression that the feature was useful, but haven't had any time to spend on it. I'm not sure if spending time on it before 2.2 is a good use of time or not. I'd rather keep this patch around as a reminder than close it, but I'll mark it out of date and give it a low priority. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 00:02 Message: Logged In: YES user_id=21627 The patch, in its current form, fails to apply (4 hunks fail). Also, the URL of the discussion of the patch changed to http://mail.python.org/pipermail/python-dev/2000-August/008527.html I recommend to reject this patch, since I cannot see what use the information it produces has to a Python developer. If there is a desire to have the feature in Python, I'd volunteer to provide an updated patch. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-08-19 00:18 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401229&group_id=5470 From noreply@sourceforge.net Thu Aug 9 15:52:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 07:52:11 -0700 Subject: [Patches] [ python-Patches-401335 ] Adds login to auth-type servers (smtplib.py) Message-ID: Patches item #401335, was opened at 2000-08-29 01:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401335&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Ulf Engstrøm (alexisjuh) Assigned to: Jeremy Hylton (jhylton) Summary: Adds login to auth-type servers (smtplib.py) Initial Comment: ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-08-09 07:52 Message: Logged In: YES user_id=31392 I've never looked at this patch , so I'll defer to Martin who has given it some serious attention. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 00:37 Message: Logged In: YES user_id=21627 I've transformed this into a patch into a diff-style patch. I've left out the self.authenticated attribute, since it appears never to be set, and since its purpose is unclear. Applying the patch seems harmless, since it just adds another method to the SMTP class. I still recommend rejecting it, since it has no apparent relationship to RFC 2554. In that RFC, the AUTH line of the EHLO response will contain a list of SASL authentication mechanisms, as defined in RFC 2222, and listed in http://www.iana.org/assignments/sasl-mechanisms So a valid AUTH request would be "AUTH CRAM-MD5", as the example in RFC 2554 shows. "AUTH login", as implemented in this patch, does not conform to the RFC. Therefore, I recommend to reject this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-04 07:44 Message: Jeremy, can you look at this again? ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-08-29 02:22 Message: 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". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401335&group_id=5470 From noreply@sourceforge.net Thu Aug 9 16:41:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 08:41:49 -0700 Subject: [Patches] [ python-Patches-400938 ] [Draft] libpython as shared library (.so) on Linux Message-ID: Patches item #400938, was opened at 2000-07-19 13:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=400938&group_id=5470 Category: None Group: None >Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Gregor Hoffleit (flight) Assigned to: Guido van Rossum (gvanrossum) Summary: [Draft] libpython as shared library (.so) on Linux Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:41 Message: Logged In: YES user_id=6380 I'm moving this to PEP-24, small feature requests. We're still waiting for someone to contribute a patch that works. I think it's best to have to request this explicitly with a configure option. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit (flight) Date: 2001-06-12 15:19 Message: Logged In: YES user_id=5293 > Now we're just waiting for someone to produce a working patch. > Or is there one already? I'm currently distributing experimental packages of Python 2.1 for Debian. The packages include a hack to build libpython2.1 as .so for Linux. The shared library patch currently is buried in a big diff file. You can get it as http://people.debian.org/~flight/python2/python2_2.1-0.diff.gz This is only a starting point for a real patch! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-12 09:54 Message: Logged In: YES user_id=6380 Reopening -- this keeps being requested. Now we're just waiting for someone to produce a working patch. Or is there one already? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-12 09:51 Message: Logged In: YES user_id=6380 Reopening -- this keeps being requested. Now we're just waiting for someone to produce a working patch. Or is there one already? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-21 15:59 Message: Logged In: YES user_id=35752 We're going to have to create a new patch to do this. This one is way too out of date. Maybe for 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-19 14:46 Message: I'm reassigning this to Neil. Neil, can you see if you can integrate this into your flat Makefile? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-17 15:09 Message: Andrew, I'm tentatively reassigning this to you, since you're taking charge of the build process at the moment (setup.py). I suspect that the patch no longer works as is -- would it make sense to mark it postponed and get the author to submit a new version before we release 2.1a1? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-01-17 14:46 Message: Getting this patch into the next version of Python would be "A Good Thing"(tm) in my opinion. We use libpython as a .so at ILM and end up having to make changes like this by hand every time we get a new version... ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-11-01 03:32 Message: I've had a look at the patch, and it seems it has two orthogonal parts. One is adding the infrastructure for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-26 14:13 Message: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-08-23 09:26 Message: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-08-16 00:40 Message: 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. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-08-15 10:52 Message: 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. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit (flight) Date: 2000-07-19 14:10 Message: 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). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=400938&group_id=5470 From noreply@sourceforge.net Thu Aug 9 16:48:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 08:48:43 -0700 Subject: [Patches] [ python-Patches-401606 ] threads and __del__ Message-ID: Patches item #401606, was opened at 2000-09-22 07:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401606&group_id=5470 Category: core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Toby Dickenson (htrd) >Assigned to: Martin v. Löwis (loewis) Summary: threads and __del__ Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:48 Message: Logged In: YES user_id=6380 Looks good to me. The patch to pystate.c doesn't apply cleanly, but it appears to be a benign conflict. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 00:47 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-09-22 08:06 Message: Works fine for me. Assigned to Tim for review since he's the race condition czar. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401606&group_id=5470 From noreply@sourceforge.net Thu Aug 9 16:49:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 08:49:24 -0700 Subject: [Patches] [ python-Patches-401713 ] Free extension DLLs' handles during the Py_Finalize() Message-ID: Patches item #401713, was opened at 2000-09-29 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401713&group_id=5470 Category: Windows Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Yakov Markovitch (markovitch) Assigned to: Tim Peters (tim_one) Summary: Free extension DLLs' handles during the Py_Finalize() Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:49 Message: Logged In: YES user_id=6380 Rejected, trusting MvL's judgement. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 00:56 Message: Logged In: YES user_id=21627 I recommend to reject this patch. If such a feature is implemented, it should be implemented uniformly across platforms - i.e. on Unix, appropriate dlclose calls should be issued. Furthermore, I don't see the problem with the DLLs being loaded. AFAIK, each DLL will be loaded only once, so even if the interpreter is stopped and started again, you get only one copy of the DLLs state per process, right? So what is the problem? Finally, it seems reasonable that people embedding the interpreter might need to customize its code. It is possible that the finalization procedure of user A won't work for user B, e.g. because they require state to survive different activations and deactivations. ---------------------------------------------------------------------- Comment By: Yakov Markovitch (markovitch) Date: 2000-10-06 02:54 Message: Yes, I agree with Mark, but there is the other side of the problem. Let's suppose that we have an application that uses the interpreter through dynamic loading (I mean through the LoadLibrary). It isn't likely to be directly, but the application can load/unload some other DLL which, in turn, uses an embedded interpreter. Now after freeing this DLL the application has ALL extensions which was used by this DLL loaded! (Though it hasn't the interpreter embedded at all!) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2000-10-05 18:19 Message: I agree we should close handles that we can't use as extension modules. I am quite skeptical of the unloading of modules, tho. Python simply doesn't provide enough cleanup semantics to guarantee we are finished with the module at Py_Finalize() time. Indeed, extension modules are one main reason why Python often can not handle multiple Py_Initialize()/Py_Finalize() calls in the same process. I think that Python needs to grow module termination semantics. Something like, at Py_Finalize time: Try and find function "term_{module}" If function exists: call function free handle else: pass Thus - only modules that have gone to the trouble of providing a finalize function can be trusted to be unloaded. On one hand, the addition of the map means we _are_ in a better position for better finalization semantics on Windows. On the larger hand, module finalization semantics must be cross-platform anyway. So - while I acknowledge the problem, I don't believe this alone is a reasonable solution. Marking as postponed, and assigning back to Tim, so he can rule on the next step.... This came up a number of years ago, and Guido agreed "better" semantics were needed. Sounds like PEP material. I guess I _do_ care enough about this issue to own a PEP on it, as long as no-one needs the PEP finalized this year ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-10-05 18:02 Message: Mark, you got anything to say about this? Can't say I've ever noticed a problem here. Note that "the patch" is actually a .zip archive, and it takes a little effort to sort out what's what. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-30 17:01 Message: Assigned to one of our Windows guys for review. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-30 17:01 Message: Assigned to one of our Windows guys for review. ---------------------------------------------------------------------- Comment By: Yakov Markovitch (markovitch) Date: 2000-09-29 12:09 Message: This patch is intended to fix the following problem: Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically initialized/finalized from one process many times during single run. Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension; "import foo" ends up with error, but foo.dll will be anging in process' address space!) This patch 1) frees a DLL handle in case of it has no proper initialization funcion 2) registers in an internal array all handles of successfully loaded dynamic extensions 2) frees all registered handles during Py_Finalize() Yakov Markovitch, markovitch@iso.ru ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401713&group_id=5470 From noreply@sourceforge.net Thu Aug 9 16:52:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 08:52:32 -0700 Subject: [Patches] [ python-Patches-402780 ] SET_LINENO for augassign Message-ID: Patches item #402780, was opened at 2000-12-11 08:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402780&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Jeremy Hylton (jhylton) Summary: SET_LINENO for augassign Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:52 Message: Logged In: YES user_id=6380 Jeremy, there's no reason not to apply this, is there? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 00:59 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2000-12-11 08:05 Message: Line numbers are currently not set for augmented assignment statements for code compiled by Tools/compiler. Here is a one line fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402780&group_id=5470 From noreply@sourceforge.net Thu Aug 9 16:51:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 08:51:46 -0700 Subject: [Patches] [ python-Patches-401904 ] Better SWIG with C++ support Message-ID: Patches item #401904, was opened at 2000-10-13 23:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401904&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jörg Baumann (jgbauman) >Assigned to: Greg Ward (gward) Summary: Better SWIG with C++ support Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:51 Message: Logged In: YES user_id=6380 Reassigning this to Greg Ward -- maybe he can decide to accept or reject this patch. ---------------------------------------------------------------------- Comment By: Jörg Baumann (jgbauman) Date: 2000-10-13 23:07 Message: I had troubles with distutils 1.0 and the way I use SWIG. I couldn't find any support for the -shadow option and no way to pass an extra include dir to swig (like it´s possible for the c compiler) Therefore I wrote a patch. It adds an extra_swig_args (list of string) option to Extension. All the strings are passed to swig without modification, but if extra_swig_args contains "-c++" or "-shadow" there is some special action: "-c++": behaves like build_ext --swig-cpp "-shadow": Normally swig generates a file: foo.c -> foo.so In this case SWIG generates two files: foo.py (python shadow classes, imports fooc) fooc.c -> fooc.so With this patch build_ext can handle this und generates for foo.i (foo.py, fooc.c) compiles them and installs them. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401904&group_id=5470 From noreply@sourceforge.net Thu Aug 9 16:58:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 08:58:30 -0700 Subject: [Patches] [ python-Patches-402891 ] Alternative readline module Message-ID: Patches item #402891, was opened at 2000-12-17 14:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402891&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Out of Date >Priority: 3 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Alternative readline module Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:58 Message: Logged In: YES user_id=6380 I have several problems with the patch at http://arctrix.com/nas/python/edline.diff: - Is it still needed now that we've solved the GPL compatibility problems of the Python license? - It's out of date (patches Setup.dist instead of setup.py) - It generates compilation errors and warnings: ../Modules/edline.c:74: warning: function declaration isn't a prototype ../Modules/edline.c:418: warning: function declaration isn't a prototype ../Modules/edline.c:467: parse error before `__extension__' ../Modules/edline.c:467: `__len' undeclared here (not in a function) ../Modules/edline.c:467: initializer element is not constant ../Modules/edline.c:467: parse error before `if' ../Modules/edline.c:467: warning: type defaults to `int' in declaration of `__retval' ../Modules/edline.c:467: conflicting types for `__retval' ../Modules/edline.c:467: previous declaration of `__retval' ../Modules/edline.c:467: warning: data definition has no type or storage class ../Modules/edline.c:467: parse error before `}' ../Modules/edline.c:477: warning: function declaration isn't a prototype ../Modules/edline.c: In function `search_hist': ../Modules/edline.c:482: warning: function declaration isn't a prototype ../Modules/edline.c: At top level: ../Modules/edline.c:844: warning: function declaration isn't a prototype make: *** [Modules/edline.o] Error 1 Marked Out of date and lowered priority. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 01:00 Message: Logged In: YES user_id=21627 I see this patch is still not committed. Any reason why not? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-18 16:04 Message: Neil, I'm assigning this back to you and reopening it (from Accepted). It seems patches with status Accepted frequently get lost -- probably because "My Patches" doesn't show them. In any case, I think you should just check this in ASAP and close the patch! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-16 06:59 Message: Ah, of course. I saw that, even played with it a bit. Looks cool, but I don't know about using it to replace readline. But you might want to change the name given that pyrl is already taken. ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-01-16 06:34 Message: pyrl is my line reader written in Python that I've been intermittently blathering about on python-dev: http://www-jcsu.jesus.cam.ac.uk/~mwh21/hacks/pyrl-0.2.0.tar.gz it's still very experimental, though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-16 05:41 Message: What's pyrl in this context? A Google search turns up a bunch of references to a Perl preprocessor that takes Pythonic syntax and translates it into Perl. :-) [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, though."] ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-01-16 02:23 Message: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-01-15 21:30 Message: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-03 06:10 Message: Neil, this has now status Accepted. Go ahead and check it in! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-18 14:17 Message: Neil, I propose that you check this in. The edline.c file would need a little work to compile without warnings, and you should add #HAVE_STRDUP to edline.h (Python makes sure strdup() is always present). The comment for Setup.dist "Neil Schemenauer's edline library" sounds a little strange given that most of the code is by others. Maybe "Neil Schemenauer's edline wrapper module"? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2000-12-17 14:28 Message: I like Michael Hudson's idea of writing a readline replacement in Python using modules like _curses and termios better but I had this patch 90% complete before I recieved his email. I stripped the editline library down and updated it for modern Unix systems. I have no idea if it compiles on anything other than Linux however. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402891&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:00:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:00:37 -0700 Subject: [Patches] [ python-Patches-402925 ] Add new function gc.getreferents Message-ID: Patches item #402925, was opened at 2000-12-19 07:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402925&group_id=5470 Category: core (C code) Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Neil Schemenauer (nascheme) Summary: Add new function gc.getreferents Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:00 Message: Logged In: YES user_id=6380 Looks like Neil checked something like this in today. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2000-12-19 14:52 Message: Even though the function does not find all references to an object, it does find all objects that have references to some object - at least if all container types participate in garbage collection (I expect that most extension types will know about GC sooner or later). In particular, it finds containers that can't be found from pure Python, eg. containers that are stored only in a global variable of some C module. Even not being able to explain all references to some object gives a useful clue. I agree that exposing traversal to Python is a useful feature, but that is completely different from that function - you'd also need to expose the generations lists (which this patch does access, but pure Python can't). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2000-12-19 11:25 Message: I'm -0 on this patch. The function is not as useful as it seems. The garbage collector does not and most likely never will be able to track down all references to an object (eg. an extension types could have a reference to it). If it could, we would be using a different collection scheme like mark and sweep. For debugging reference cycles like the RExec problem a pure Python tool (similar to Cyclops) would work. The tool just has to know how to chase references in different kinds of objects. Perhaps exposing the GC's knowledge of this would be more useful and general. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2000-12-19 07:13 Message: This patch adds a new function gc.getreferents which traverses all collectable objects and returns a list of objects that refer to any of the parameters of gc.getreferents. This will only find references visible to the gc; references in local variables of functions that are currently on the stack won't be found. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402925&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:03:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:03:47 -0700 Subject: [Patches] [ python-Patches-401606 ] threads and __del__ Message-ID: Patches item #401606, was opened at 2000-09-22 07:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401606&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Martin v. Löwis (loewis) Summary: threads and __del__ Initial Comment: ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-09 09:03 Message: Logged In: YES user_id=31435 See bug 215076 for discussion. It's unclear what this believes it's solving, so also unclear that it actually solves it. It does complicate *our* code, and the patch adds no comments explaining why this convolution is necessary (so if this does solve something, it's likely to break again anyway, as nobody reading the code will understand why it's so complicated). The relationship between threads and __del__ should either be left alone, or defined carefully (like in a PEP). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:48 Message: Logged In: YES user_id=6380 Looks good to me. The patch to pystate.c doesn't apply cleanly, but it appears to be a benign conflict. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 00:47 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-09-22 08:06 Message: Works fine for me. Assigned to Tim for review since he's the race condition czar. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401606&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:04:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:04:17 -0700 Subject: [Patches] [ python-Patches-403514 ] small speedup in Tkinter.Misc._bind Message-ID: Patches item #403514, was opened at 2001-01-30 12:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403514&group_id=5470 Category: Tkinter Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) >Assigned to: Martin v. Löwis (loewis) Summary: small speedup in Tkinter.Misc._bind Initial Comment: This patch precomputes _subst_format_str to avoid a call to _string.join() on each invocation of _bind. It gives a small but noticable speed improvement when creating a lot of bindings, such as in the upcoming PySol Mahjongg games. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:04 Message: Logged In: YES user_id=6380 Approved. Please don't assign Tkinter patches to effbot! MvL, can you check it in? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 13:04 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403514&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:05:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:05:26 -0700 Subject: [Patches] [ python-Patches-414492 ] adds a gc.get_generation function Message-ID: Patches item #414492, was opened at 2001-04-07 00:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414492&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Neil Schemenauer (nascheme) Summary: adds a gc.get_generation function Initial Comment: gc.get_generation(num) added by this patch allows you to get a list of all objects in a given garbage collector generation. I wrote this while trying to debug a memory leak so that I could peek at what types of objects were remaining allocated but never freed. Looking through the patches I see another similarish patch that allow for searching the collection lists for references to a particular thing or set of things. interesting. Is it useful? Yes and no. I still haven't found the memory leak. But I know what objects are consuming it so I can narrow my search through to code to find how they are remaining referenced. as a side note, there's not much point in the generation number parameter to this method, 2 is the only generation really worth examining. This or something like it would be nice to see in a future python gc module as a debugging aid. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-08-09 09:05 Message: Logged In: YES user_id=35752 Accepted in modified form as gc.get_objects. Thanks Greg. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-05 23:45 Message: Logged In: YES user_id=21627 I still would like to see my gc.getreferents patch applied, which offers a similar debugging aid. However, since this offers a somewhat orthogonal functionality, and is a quite short patch, I recommend to approve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414492&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:06:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:06:20 -0700 Subject: [Patches] [ python-Patches-403640 ] incomplete proxy handling in URLLIB Message-ID: Patches item #403640, was opened at 2001-02-06 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403640&group_id=5470 Category: library Group: None Status: Open >Resolution: Accepted >Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: incomplete proxy handling in URLLIB Initial Comment: under WinNT, the proxy code takes the proxy values from the registry, but does *not* check for the proxy override settings. The supplied patch does take care of it and works for me. Not very sophisticated, but operational. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:06 Message: Logged In: YES user_id=6380 I'm accepting this. The original submitter didn't care to clean it up, so I'm lowering the priority. Tim, just check it in -- if it's broken we'll hear about it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:08 Message: Logged In: YES user_id=6380 Back to you, Tim. I'm also an @home user so I can't test this either. I agree with the style comments. Also, it translates a pattern to regular expression; an easier way to do this is to use fnmatch (which also takes care of the case insensitive match when it's on Windows). Would the original submitter care to clean up the code according to the (Tim's & my) comments? Otherwise I think this is sufficiently low priority that I'm not going to move heaven & earth to get it into 2.1b2 (this Friday), and after that I'm not going to allow *anything* new in the code base for 2.1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 21:23 Message: Logged In: YES user_id=31435 Back to you! I've spent enough time on it, but I don't know this code, and it turns out I never get into it anyway. @Home uses the AutoConfigURL registry gimmick rather than ProxyEnable (which is 0 on my box) and ProxyOverride (which doesn't exist on my box). Even if they did exist, the new proxy_bypass() routine isn't called if the url passed to open_http() is a string, and it always is a string for me. Trying to trace *that* back, this is apparently because the NT getproxies() function returns {}, and again because @Home isn't enabling ProxyEnable. So best I can say is that this code doesn't hurt me. Note that there are jarring style differences with surrounding code, primarily use of Capitalized words for local vrbl names. Also lines and comments spilling past column 80. The list() call in list(proxyOverrd.split(';')) doesn't appear to make sense (.split() returns a list!). For that matter proxyOverrd is an ugly abbreviation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 23:07 Message: Logged In: YES user_id=6380 Tim, you seem to be using a proxy, so maybe you can give this a try? Also, it has Win specific code (_winreg usage). If you can't or don't want to, please give it back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403640&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:10:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:10:04 -0700 Subject: [Patches] [ python-Patches-401606 ] threads and __del__ Message-ID: Patches item #401606, was opened at 2000-09-22 07:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401606&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Martin v. Löwis (loewis) Summary: threads and __del__ Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:10 Message: Logged In: YES user_id=6380 In that case I'll reject and close it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 09:03 Message: Logged In: YES user_id=31435 See bug 215076 for discussion. It's unclear what this believes it's solving, so also unclear that it actually solves it. It does complicate *our* code, and the patch adds no comments explaining why this convolution is necessary (so if this does solve something, it's likely to break again anyway, as nobody reading the code will understand why it's so complicated). The relationship between threads and __del__ should either be left alone, or defined carefully (like in a PEP). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:48 Message: Logged In: YES user_id=6380 Looks good to me. The patch to pystate.c doesn't apply cleanly, but it appears to be a benign conflict. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 00:47 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-09-22 08:06 Message: Works fine for me. Assigned to Tim for review since he's the race condition czar. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401606&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:12:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:12:58 -0700 Subject: [Patches] [ python-Patches-402891 ] Alternative readline module Message-ID: Patches item #402891, was opened at 2000-12-17 14:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402891&group_id=5470 Category: Modules Group: None >Status: Deleted Resolution: Out of Date Priority: 3 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Alternative readline module Initial Comment: ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-08-09 09:12 Message: Logged In: YES user_id=35752 I don't think we need this any more so I'm deleting it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:58 Message: Logged In: YES user_id=6380 I have several problems with the patch at http://arctrix.com/nas/python/edline.diff: - Is it still needed now that we've solved the GPL compatibility problems of the Python license? - It's out of date (patches Setup.dist instead of setup.py) - It generates compilation errors and warnings: ../Modules/edline.c:74: warning: function declaration isn't a prototype ../Modules/edline.c:418: warning: function declaration isn't a prototype ../Modules/edline.c:467: parse error before `__extension__' ../Modules/edline.c:467: `__len' undeclared here (not in a function) ../Modules/edline.c:467: initializer element is not constant ../Modules/edline.c:467: parse error before `if' ../Modules/edline.c:467: warning: type defaults to `int' in declaration of `__retval' ../Modules/edline.c:467: conflicting types for `__retval' ../Modules/edline.c:467: previous declaration of `__retval' ../Modules/edline.c:467: warning: data definition has no type or storage class ../Modules/edline.c:467: parse error before `}' ../Modules/edline.c:477: warning: function declaration isn't a prototype ../Modules/edline.c: In function `search_hist': ../Modules/edline.c:482: warning: function declaration isn't a prototype ../Modules/edline.c: At top level: ../Modules/edline.c:844: warning: function declaration isn't a prototype make: *** [Modules/edline.o] Error 1 Marked Out of date and lowered priority. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 01:00 Message: Logged In: YES user_id=21627 I see this patch is still not committed. Any reason why not? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-18 16:04 Message: Neil, I'm assigning this back to you and reopening it (from Accepted). It seems patches with status Accepted frequently get lost -- probably because "My Patches" doesn't show them. In any case, I think you should just check this in ASAP and close the patch! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-16 06:59 Message: Ah, of course. I saw that, even played with it a bit. Looks cool, but I don't know about using it to replace readline. But you might want to change the name given that pyrl is already taken. ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-01-16 06:34 Message: pyrl is my line reader written in Python that I've been intermittently blathering about on python-dev: http://www-jcsu.jesus.cam.ac.uk/~mwh21/hacks/pyrl-0.2.0.tar.gz it's still very experimental, though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-16 05:41 Message: What's pyrl in this context? A Google search turns up a bunch of references to a Perl preprocessor that takes Pythonic syntax and translates it into Perl. :-) [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, though."] ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-01-16 02:23 Message: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-01-15 21:30 Message: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-03 06:10 Message: Neil, this has now status Accepted. Go ahead and check it in! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-18 14:17 Message: Neil, I propose that you check this in. The edline.c file would need a little work to compile without warnings, and you should add #HAVE_STRDUP to edline.h (Python makes sure strdup() is always present). The comment for Setup.dist "Neil Schemenauer's edline library" sounds a little strange given that most of the code is by others. Maybe "Neil Schemenauer's edline wrapper module"? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2000-12-17 14:28 Message: I like Michael Hudson's idea of writing a readline replacement in Python using modules like _curses and termios better but I had this patch 90% complete before I recieved his email. I stripped the editline library down and updated it for modern Unix systems. I have no idea if it compiles on anything other than Linux however. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402891&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:23:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:23:41 -0700 Subject: [Patches] [ python-Patches-403671 ] Allow jython to complete the test_class test Message-ID: Patches item #403671, was opened at 2001-02-07 13:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403671&group_id=5470 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to complete the test_class test Initial Comment: A breakdown of the changes: - the __del__ method must be present at class definition time for jython to use it. - slices pass into __xxxitem__ works, but the default values are not "0, maxint, None" but "None, None, 1". At this time this is a known difference. - in jython the __int__, __long__ etc methods must return a correctly typed value. The test that just return None is skipped. - An explicit call to GC is required to force a call to __del__. The two changes that just adds a print "the expected result" is really ugly, but it is necessary for jython to generate the same output as python. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:23 Message: Logged In: YES user_id=6380 Accepted. I'll leave it to Barry to check this in. (Finn, do you still need this? I assume so!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403671&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:25:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:25:10 -0700 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was opened at 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:25 Message: Logged In: YES user_id=6380 I'm rejecting this now. I have yet to find a purpose for it, and I'm quite happy with __future__. My preference for encoding directives are still to use a magical comment, but that's a separate PEP anyway. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 13:08 Message: Logged In: YES user_id=6380 I'm postponing this now. I like the idea of directives, but I don't think we should disrupt the 2.1 release for this. So let's look at this again after 2.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 04:15 Message: Logged In: YES user_id=21627 Revised patch to match the draft PEP (244?): nested scopes are enabled by "directive transitional nested_scopes", and a warning is produced if "directive" is used as a name. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:22 Message: Logged In: YES user_id=31435 SourceForge is driving me nuts today. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:21 Message: Logged In: YES user_id=31435 Assigned to Guido: since the patch would replace the current future_statement implementation, doing anything with it before Friday would require BDFL decree. I personally like that future_statements don't look like general directives: directive integer_division directive left_hand_side_swap Over time, the set of names grows, and it won't be clear which directives are dead-serious business (like an incompatible language change) and which minor tweaking of pragmatics. An extension was briefly discussed on c.l.py, along the lines of adding another word, e.g. directive future integer_division directive pragma left_hand_side_swap Whatever, AFAIK that didn't get implemented, and there's no PEP for it (or this) in any case (BTW, while I would like to see a PEP for a general directive facility, I'm not going to write one). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:58 Message: Logged In: YES user_id=31435 @Home is major-league hosed; switching to another ISP to delete 3 of the 4(!) patch copies I managed to attach to this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:11 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:10 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:08 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:26:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:26:17 -0700 Subject: [Patches] [ python-Patches-405101 ] Add Random Seeding to OpenSSL Message-ID: Patches item #405101, was opened at 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Moshe Zadka (moshez) Assigned to: Guido van Rossum (gvanrossum) Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:26 Message: Logged In: YES user_id=6380 This patch was accepted, and then withdrawn because it caused too many problems on some platforms. So I'm now officially rejecting and closing it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-15 05:36 Message: Logged In: YES user_id=6380 Reopened and grabbed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-15 05:36 Message: Logged In: YES user_id=6380 But Modules/Setup is no longer used to build the socket module! It's now built by setup.py, which ignores Modules/Setup AFAICT. I'm very tempted to undo this patch, as it has too many problems (see the python-dev discussion: it needs work for pre-0.9.5 versions of openssl, and on some systems it always issues a warning whenever you import the socket module. That's bad, since few of those imports are intended to use the ssl support. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-15 04:37 Message: Logged In: YES user_id=11645 Whoever builds, in Modules/Setup After many discussions, I have not found any way to autodetect a running EGD so setup.py can enable it. I should probably have documented it somewhere....sorry. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-14 21:29 Message: Logged In: YES user_id=6380 Who defines USE_EGD??? ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-18 00:45 Message: Logged In: YES user_id=11645 Checked in ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 08:38 Message: Logged In: YES user_id=11375 Looks OK. Go ahead and check it in. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-01 03:40 Message: Logged In: YES user_id=11645 New version of the patch: now warning when using the insecure srand/rand (version at http://www.lerner.co.il/~moshez/ssl_seed also updated) Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 11:37:12 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2505 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + PyErr_Warn(PyExc_RuntimeWarning, + "using insecure method to generate random numbers"); + srand(time(NULL)); + for(i=0; i Patches item #410471, was opened at 2001-03-21 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410471&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Out of Date >Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: linuxaudiodev lacks Py_BEGIN/END_THREAD Initial Comment: The system calls in the linuxaudiodev module need to be wrapped with: Py_BEGIN_ALLOW_THREADS Py_END_ALLOW_THREADS so that audio I/O can occur async/multithreaded. I'm including a patch to fix this, for Python 2.0. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:29 Message: Logged In: YES user_id=6380 I tried applying this patch but it got several failed hunks -- no surprise since it was for Python 2.0. I'll leave it open for another month (until 9 Sept 2001) and if someone hasn't provided a patch that works with current CVS by then, I'll close it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:23 Message: Logged In: YES user_id=6380 Good catch. I hesitate to fix this so close to the 2.1 release. I've also recategorized it as a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410471&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:30:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:30:18 -0700 Subject: [Patches] [ python-Patches-413087 ] support for Borland C++ compiler Message-ID: Patches item #413087, was opened at 2001-04-02 03:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413087&group_id=5470 Category: Build Group: None Status: Open >Resolution: Out of Date >Priority: 3 Submitted By: janez jere (janezj) Assigned to: Guido van Rossum (gvanrossum) Summary: support for Borland C++ compiler Initial Comment: Some minor changes are required to compile source with BCB 5. If patch will be accepted I will submit ky script, (written in a popular scripting language) which produces makefiles. Patch is not so elegant as it should be, because config.h is not used as it should be, just see the mess in posixmodule.c. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:30 Message: Logged In: YES user_id=6380 I'm still waiting for a patch in context diff format. The submitter has until Sept. 9, 2001 to provide a new patch. If I see no action then, I'll close and reject it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:34 Message: Logged In: YES user_id=6380 I'm sorry, we don't accept plain diffs any more, certainly not for this much code. Can you please submit a context diff? I've a feeling that this might be applied for Python 2.1 if it doesn't break any code -- the changes seem simple enough. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413087&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:31:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:31:14 -0700 Subject: [Patches] [ python-Patches-418390 ] static member functions Message-ID: Patches item #418390, was opened at 2001-04-23 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418390&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: static member functions Initial Comment: This allows for class methods to be called statically without the need for workaround abuse as described in the python FAQ (or any other method involving grabbing the "im_func" member from an unbound method object). This patch changes the "call_method" function in ceval.c. It removes the improper 'class type enforcement' on unbound method objects and just passes the arguments as is. This allows for natural and clean static methods inside classes. The only thing potentially broken with this patch is a looser guarantee that the "self" value for a method would be some inherited type instance. This is far less 'dangerous for abuse' than other python class designs (no private members, etc). With this the static method example in the FAQ is much more cleanly realized. notice, no "self" member for static methods... class C: count = 0 def __init__(self): C.count += 1 def getcount(): return C.count def sum(x, y): return x + y C(); C() c = C() print C.getcount() # prints 3 print c.getcount() # prints 3 print C.sum(27, 15) # prints 42 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:31 Message: Logged In: YES user_id=6380 Rejected. In Python 2.2, you can do this using the new "staticmethod" built-in. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-04-23 16:00 Message: Logged In: NO btw, i did submit with my email address, but sourceforge has relabeled me as anonymous. please respond to "pete at shinners dot org" should that be required. doh, i see sourceforge didn't respect my example formatting either. ---------------------------------------------------------------------- Comment By: Mark Kimsal (hardcoreholly) Date: 2001-04-23 15:47 Message: Logged In: YES user_id=89302 an application programmer could still secure the type of the arguments if s/he felt it was necessary by raising the unbound method exception if the first arg was not the expected type. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418390&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:32:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:32:02 -0700 Subject: [Patches] [ python-Patches-421893 ] Cleanup GC API Message-ID: Patches item #421893, was opened at 2001-05-06 14:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 Category: core (C code) Group: None Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Cleanup GC API Initial Comment: This patch adds three new APIs: PyObject_GC_New PyObject_GC_NewVar PyObject_GC_Resize PyObject_GC_Del and renames PyObject_GC_Init and PyObject_GC_Fini to: PyObject_GC_Track PyObject_GC_Ignore respectively. Objects that wish to be tracked by the collector must use these new APIs. Many more details about the GC implementation are hidden inside gcmodule.c. There seems to be no change in performance. Note that PyObject_GC_{New,NewVar} automatically adds the object to the GC lists. There is no need to call PyObject_GC_Track. PyObject_GC_Del automatically removes the object from the GC list but usually you want to call PyObject_GC_Ignore yourself (DECREFs can end up running arbitrary code). It should be more difficult to corrupt the GC linked lists now. Also, you can now call PyObject_GC_Ignore on objects that you know will not create RCs. The _weakref module does this. Previously, every object that had the GC type flag set and could be found by using tp_traverse had to be in a GC linked list. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:32 Message: Logged In: YES user_id=6380 Neil, do we still need this? I've marked it out-of-date because I'm sure that it won't apply cleanly any more. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-16 09:25 Message: Logged In: YES user_id=6380 I think I know a way to fix the incompatibility, by switching to a different flag bit. I'll try to work this into the descr-branch code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 10:13 Message: Logged In: YES user_id=21627 I have two problems with this patch: 1. It comes with no documentation. 2. It breaks existing third-party modules which use the GC API as defined in Python 2. Consequently, I recommend rejection of the patch in its current form. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:37:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:37:17 -0700 Subject: [Patches] [ python-Patches-424554 ] pythonrun.c: bag the _Py_AskYesNo call Message-ID: Patches item #424554, was opened at 2001-05-16 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424554&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Guido van Rossum (gvanrossum) Summary: pythonrun.c: bag the _Py_AskYesNo call Initial Comment: Currently, on Unix-like systems if Py_TRACE_REFS is defined, the Python interpreter asks at the end of the run if remaining references should be dumped. If you are trying to debug Python or its interaction with other packages that use it this can cause problems. Case in point, the configure script for the PyGtk2 package runs the python interpreter to check that its version number is >= 2.0. If you need Py_DEBUG enabled to build a version of PyGtk2 with that stuff turned on, you need it to not ask about printing references. I think the better solution is just to have the reference dumping dependent on the presence of the PYTHONDUMPREFS environment variable, which is currently only used under Windows. A patch to fix this problem is attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:37 Message: Logged In: YES user_id=6380 Good idea. Acceppted and applied as pythonrun.c:2.142. (I've replaced the getenv() call with a Py_GETENV() call. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-04 03:01 Message: Logged In: YES user_id=44345 In the example I noted (a configure script running python) it would be difficult to get at the command line without messing around with the configure script or the autoconf macros. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:33 Message: Logged In: YES user_id=3066 Another approach would be to use command line parameters. I'm not sure that either approach is necessarily better than the other. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424554&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:42:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:42:21 -0700 Subject: [Patches] [ python-Patches-438424 ] Fix for missing turtle fuctionality Message-ID: Patches item #438424, was opened at 2001-07-03 20:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438424&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Josh Cogliati (jjc) Assigned to: Guido van Rossum (gvanrossum) Summary: Fix for missing turtle fuctionality Initial Comment: Python's logolike module turtle.py did not display the turtle except when actually drawing lines. This patch changes the turtle.py module so that it displays the turtle at all times when tracing is on. This is similar to the the way that logo works. When tracing is off the turtle will not be displayed. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:42 Message: Logged In: YES user_id=6380 Thanks! Applied as tutrle.py:1.5. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:46 Message: Logged In: YES user_id=3066 Assigned to Guido, since he likely knows more about Logo than I do (I don't!), and this is his module to begin with. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438424&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:51:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:51:33 -0700 Subject: [Patches] [ python-Patches-400938 ] [Draft] libpython as shared library (.so) on Linux Message-ID: Patches item #400938, was opened at 2000-07-19 13:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=400938&group_id=5470 Category: None Group: None Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Gregor Hoffleit (flight) Assigned to: Guido van Rossum (gvanrossum) Summary: [Draft] libpython as shared library (.so) on Linux Initial Comment: ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 09:51 Message: Logged In: YES user_id=93657 If that helps, here is how I rebuild python and its library as shared entities, after the standard static build. This works fine on Linux. The next problem on linux is that all native extensions also have to be explicitely relinked with the Python shared library. A few months ago, I search the 12,000 python lines for the distutil for the line to modify to have this done properly, but I failed to find it... Since then, I've started sketching a Python implementation of a Make-like tool (rule-based), so as not to use the distutils that are beyond my grasp; but it's a low priority task :(( It's only one line to modify in the distutil, and you'll get the dynamic version entirely build on Linux and likes, using what's below... Regards, Frederic Giacometti ---------------------------------- WHICH=which PYTHONEXE=$(shell $(WHICH) python) PYTHON_BUILDDIR=$(HOME)/local/src/Python-2.1 PYTHON_O=$(PYTHON_BUILDDIR)/Modules/python.o PYTHONSTATICLIB=$(PYTHON_BUILDDIR)/lib$(PYTHONLIBNAME).a SOBUILDDIR=$(JPEDIR)/pysolib $(PYTHONSOLIB): $(PYTHONSTATICLIB) $(PYTHON_O) $(RM) -rf $(SOBUILDDIR) mkdir $(SOBUILDDIR) cd $(SOBUILDDIR) && ar x $< cd $(SOBUILDDIR) && ld -shared -export-dynamic -o $@ *.o\ -lpthread -ldl -lutil -lm -lc mv $(PYTHONEXE) $(PYTHONEXE)~ ld -export-dynamic -o $(PYTHONEXE) $(PYTHON_O)\ -L$(PYTHONSOLIBDIR) -l$(PYTHONLIBNAME)\ || (echo "failed to build $(PYTHONEXE)" && mv $(PYTHONEXE)~ $(PYTHONEXE)\ && exit 23) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:41 Message: Logged In: YES user_id=6380 I'm moving this to PEP-24, small feature requests. We're still waiting for someone to contribute a patch that works. I think it's best to have to request this explicitly with a configure option. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit (flight) Date: 2001-06-12 15:19 Message: Logged In: YES user_id=5293 > Now we're just waiting for someone to produce a working patch. > Or is there one already? I'm currently distributing experimental packages of Python 2.1 for Debian. The packages include a hack to build libpython2.1 as .so for Linux. The shared library patch currently is buried in a big diff file. You can get it as http://people.debian.org/~flight/python2/python2_2.1-0.diff.gz This is only a starting point for a real patch! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-12 09:54 Message: Logged In: YES user_id=6380 Reopening -- this keeps being requested. Now we're just waiting for someone to produce a working patch. Or is there one already? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-12 09:51 Message: Logged In: YES user_id=6380 Reopening -- this keeps being requested. Now we're just waiting for someone to produce a working patch. Or is there one already? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-21 15:59 Message: Logged In: YES user_id=35752 We're going to have to create a new patch to do this. This one is way too out of date. Maybe for 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-19 14:46 Message: I'm reassigning this to Neil. Neil, can you see if you can integrate this into your flat Makefile? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-17 15:09 Message: Andrew, I'm tentatively reassigning this to you, since you're taking charge of the build process at the moment (setup.py). I suspect that the patch no longer works as is -- would it make sense to mark it postponed and get the author to submit a new version before we release 2.1a1? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-01-17 14:46 Message: Getting this patch into the next version of Python would be "A Good Thing"(tm) in my opinion. We use libpython as a .so at ILM and end up having to make changes like this by hand every time we get a new version... ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-11-01 03:32 Message: I've had a look at the patch, and it seems it has two orthogonal parts. One is adding the infrastructure for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-26 14:13 Message: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-08-23 09:26 Message: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-08-16 00:40 Message: 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. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-08-15 10:52 Message: 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. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit (flight) Date: 2000-07-19 14:10 Message: 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). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=400938&group_id=5470 From noreply@sourceforge.net Thu Aug 9 17:58:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:58:08 -0700 Subject: [Patches] [ python-Patches-403514 ] small speedup in Tkinter.Misc._bind Message-ID: Patches item #403514, was opened at 2001-01-30 12:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403514&group_id=5470 Category: Tkinter Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: Martin v. Löwis (loewis) Summary: small speedup in Tkinter.Misc._bind Initial Comment: This patch precomputes _subst_format_str to avoid a call to _string.join() on each invocation of _bind. It gives a small but noticable speed improvement when creating a lot of bindings, such as in the upcoming PySol Mahjongg games. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-09 09:58 Message: Logged In: YES user_id=21627 Committed (in slightly modified form) as Tkinter.py 1.153 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:04 Message: Logged In: YES user_id=6380 Approved. Please don't assign Tkinter patches to effbot! MvL, can you check it in? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 13:04 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403514&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:34:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:34:09 -0700 Subject: [Patches] [ python-Patches-414948 ] Check dynload_next.c (see description) Message-ID: Patches item #414948, was opened at 2001-04-09 09:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Wight (schwa) >Assigned to: Jack Jansen (jackjansen) Summary: Check dynload_next.c (see description) Initial Comment: Fixes dynload_next.c to check to see library isn't already loaded. Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); So in effect Python isn't being returned into a 'good' state. NOTE: This is a follow-up to Patch #413005. In that Patch my browser failed to upload & attach the patch file. Apologies. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:34 Message: Logged In: YES user_id=6380 Jack, can you look at this? You have MacOS X, right? It looks OK to me but I don't know MacOS X... ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-07-23 06:52 Message: Logged In: YES user_id=11645 OK, someone else will need to check this....I have no idea and no time to check it. ---------------------------------------------------------------------- Comment By: Jonathan Wight (schwa) Date: 2001-04-11 10:40 Message: Logged In: YES user_id=29309 > This is irrelevant for 2.1 -- it is a Py2.0.1 bugfix I countered this bug in version 2.1b2a -- I then did a cvs checkout to get the latest version of the (buggy) code. Unless I'm missing something a fix isn't in 2.1 > (the author neglected to set the group up There wasn't an option for 2.1b2a in the group popup. Just "2.0.1" and "None" ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-11 00:26 Message: Logged In: YES user_id=11645 This is irrelevant for 2.1 -- it is a Py2.0.1 bugfix (the author neglected to set the group up, sadly, and I didn't have SF time before today to set this up). I'll check in some more patches to 201 this weekend, I think. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:25 Message: Logged In: YES user_id=6380 Assigned to Moshe since he assigned the other (failed) submission to himself also (Moshe, do you have the resources to test this before 2.1 goes out? If not, please unassign!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:10:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:10:42 -0700 Subject: [Patches] [ python-Patches-400938 ] [Draft] libpython as shared library (.so) on Linux Message-ID: Patches item #400938, was opened at 2000-07-19 13:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=400938&group_id=5470 Category: None Group: None Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Gregor Hoffleit (flight) Assigned to: Guido van Rossum (gvanrossum) Summary: [Draft] libpython as shared library (.so) on Linux Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:10 Message: Logged In: YES user_id=6380 Sorry Frederic, that doesn't help at all: I'm not searching for anecdotal evidence that it can be done (I have plenty), I am asking for a patch that provides this functionality on (at least some) platforms where it can be done, without breaking the build process elsewhere. Changes to the build process are hard because it's hard to verify that your change doesn't break on somebody else's machine. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 09:51 Message: Logged In: YES user_id=93657 If that helps, here is how I rebuild python and its library as shared entities, after the standard static build. This works fine on Linux. The next problem on linux is that all native extensions also have to be explicitely relinked with the Python shared library. A few months ago, I search the 12,000 python lines for the distutil for the line to modify to have this done properly, but I failed to find it... Since then, I've started sketching a Python implementation of a Make-like tool (rule-based), so as not to use the distutils that are beyond my grasp; but it's a low priority task :(( It's only one line to modify in the distutil, and you'll get the dynamic version entirely build on Linux and likes, using what's below... Regards, Frederic Giacometti ---------------------------------- WHICH=which PYTHONEXE=$(shell $(WHICH) python) PYTHON_BUILDDIR=$(HOME)/local/src/Python-2.1 PYTHON_O=$(PYTHON_BUILDDIR)/Modules/python.o PYTHONSTATICLIB=$(PYTHON_BUILDDIR)/lib$(PYTHONLIBNAME).a SOBUILDDIR=$(JPEDIR)/pysolib $(PYTHONSOLIB): $(PYTHONSTATICLIB) $(PYTHON_O) $(RM) -rf $(SOBUILDDIR) mkdir $(SOBUILDDIR) cd $(SOBUILDDIR) && ar x $< cd $(SOBUILDDIR) && ld -shared -export-dynamic -o $@ *.o\ -lpthread -ldl -lutil -lm -lc mv $(PYTHONEXE) $(PYTHONEXE)~ ld -export-dynamic -o $(PYTHONEXE) $(PYTHON_O)\ -L$(PYTHONSOLIBDIR) -l$(PYTHONLIBNAME)\ || (echo "failed to build $(PYTHONEXE)" && mv $(PYTHONEXE)~ $(PYTHONEXE)\ && exit 23) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:41 Message: Logged In: YES user_id=6380 I'm moving this to PEP-24, small feature requests. We're still waiting for someone to contribute a patch that works. I think it's best to have to request this explicitly with a configure option. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit (flight) Date: 2001-06-12 15:19 Message: Logged In: YES user_id=5293 > Now we're just waiting for someone to produce a working patch. > Or is there one already? I'm currently distributing experimental packages of Python 2.1 for Debian. The packages include a hack to build libpython2.1 as .so for Linux. The shared library patch currently is buried in a big diff file. You can get it as http://people.debian.org/~flight/python2/python2_2.1-0.diff.gz This is only a starting point for a real patch! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-12 09:54 Message: Logged In: YES user_id=6380 Reopening -- this keeps being requested. Now we're just waiting for someone to produce a working patch. Or is there one already? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-12 09:51 Message: Logged In: YES user_id=6380 Reopening -- this keeps being requested. Now we're just waiting for someone to produce a working patch. Or is there one already? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-21 15:59 Message: Logged In: YES user_id=35752 We're going to have to create a new patch to do this. This one is way too out of date. Maybe for 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-19 14:46 Message: I'm reassigning this to Neil. Neil, can you see if you can integrate this into your flat Makefile? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-17 15:09 Message: Andrew, I'm tentatively reassigning this to you, since you're taking charge of the build process at the moment (setup.py). I suspect that the patch no longer works as is -- would it make sense to mark it postponed and get the author to submit a new version before we release 2.1a1? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-01-17 14:46 Message: Getting this patch into the next version of Python would be "A Good Thing"(tm) in my opinion. We use libpython as a .so at ILM and end up having to make changes like this by hand every time we get a new version... ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-11-01 03:32 Message: I've had a look at the patch, and it seems it has two orthogonal parts. One is adding the infrastructure for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-26 14:13 Message: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-08-23 09:26 Message: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-08-16 00:40 Message: 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. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-08-15 10:52 Message: 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. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit (flight) Date: 2000-07-19 14:10 Message: 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). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=400938&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:37:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:37:10 -0700 Subject: [Patches] [ python-Patches-419145 ] SocketServer test (UDP/TCP Thread/Fork) Message-ID: Patches item #419145, was opened at 2001-04-26 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419145&group_id=5470 Category: None Group: None Status: Open >Resolution: Out of Date >Priority: 3 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer test (UDP/TCP Thread/Fork) Initial Comment: this is a _completely_ inappropriate location to put in a patch: stupid-netscape word-wraps it. well, too bad :) --- src/Python-2.1/Lib/SocketServer.py Wed Apr 11 05:02:05 2001 +++ SocketServer2.py Thu Apr 26 16:23:32 2001 @@ -110,15 +110,22 @@ BaseServer: - split generic "request" functionality out into BaseServer class. - Copyright (C) 2000 Luke Kenneth Casson Leighton example: read entries from a SQL database (requires overriding get_request() to return a table entry from the database). entry is processed by a RequestHandlerClass. +Test Method: +simple echo server, ForkingTCPServer and ThreadingTCPServer. +send data on port 10000, it will be received back, verbatim. +run test with --client to create 20 such test connections, +which will send 20 tests each and expect them to be received. + +TODO: write a UDPServer test, too. + """ -# Author of the BaseServer patch: Luke Kenneth Casson Leighton +# Author of the BaseServer and test() patch: Luke Kenneth Casson Leighton __version__ = "0.3" @@ -555,3 +562,171 @@ def finish(self): self.socket.sendto(self.wfile.getvalue(), self.client_address) + + +class EchoHandler: + """ an example handler that reads data from a socket + and sends it back. + """ + + def handle(self): + """ simple read line, write it. + we don't even do a select on the socket, just read + it. + """ + eof = None + data = None + + print 'received connection request' + data = self.rfile.readline() + print 'received data:', repr(data) + self.wfile.write(data) + self.wfile.flush() + +class EchoUDPHandler(EchoHandler,DatagramRequestHandler): pass +class EchoTCPHandler(EchoHandler,StreamRequestHandler): pass + + +class TestConnection: + """ simple test connector, has send and recv methods. + code is ripped / stripped from HTTPConnection :) + """ + + def __init__(self, host, port=None, socket_type=socket.SOCK_STREAM): + self.sock = None + self.host = host + self.port = port + self.socket_type = socket_type + + def connect(self): + """Connect to the host and port specified in __init__.""" + self.sock = socket.socket(socket.AF_INET, self.socket_type) + self.sock.connect((self.host, self.port)) + + # hmm, don't know enough about UDP / python to know if + # this works as expected! + self.fp = self.sock.makefile('wrb', 0) + + def close(self): + """Close the connection to the server.""" + if self.sock: + self.sock.close() # close it manually... there may be other refs + self.sock = None + + def send(self, str): + """Send `str' to the server.""" + if self.sock is None: + self.connect() + + try: + self.fp.write(str) + except socket.error, v: + if v[0] == 32: # Broken pipe + self.close() + raise + + def read(self, len=0): + """read from socket + """ + return self.fp.read(len) + + +def test(): + """ test method for SocketServer.py + """ + + def test_client_fn(server_addr='127.0.0.1', server_port=10000, + sock_type=socket.SOCK_STREAM): + + clients = [] + for n in range(20): + clients.append(TestConnection(server_addr, server_port, sock_type)) + + for i in range(len(clients)): + c = clients[i] + c.send("echo test %d\n" % i) + + for i in range(len(clients)): + c = clients[i] + expected_data = "echo test %d\n" % i + data = c.read(len(expected_data)) + if data != expected_data: + print "client %d failed test" + + + def test_server_fn(ServerClass, server_addr, HandlerClass): + + srv = ServerClass(('', 10000), HandlerClass) + srv.max_children = 50 + srv.serve_forever() + + def usage(): + print "usage: --client, -c a test client" + print " --thread-server, -t to run a threading server" + print " --fork-server, -f to run a forking server" + print " --udp, to run a UDP server" + print " --tcp to run a TCP server" + sys.exit(0) + + from getopt import getopt + + if len(sys.argv) == 1: + usage() + + opts, args = getopt(sys.argv[1:], 'hftc', + ['help', 'fork-server', 'thread-server', + 'udp', 'tcp', + 'client']) + + threading = None + forking = None + tcp = None + udp = None + testclass = None + testhandlerclass = None + sock_type = None + testclient = None + + for (opt, value) in opts: + + if opt == '--help' or opt == '-h': + usage() + + if opt == '--tcp': + tcp = 1 + sock_type = socket.SOCK_STREAM + + if opt == '--udp': + udp = 1 + sock_type = socket.SOCK_DGRAM + + if opt == '--fork-server' or opt == '-f': + forking = 1 + + if opt == '--thread-server' or opt == '-t': + threading = 1 + + if opt == '--client' or opt == '-c': + testclient = 1 + + if tcp and forking: + testclass = ForkingTCPServer + testhandlerclass = EchoTCPHandler + if tcp and threading: + testclass = ThreadingTCPServer + testhandlerclass = EchoTCPHandler + if udp and forking: + testclass = ForkingUDPServer + testhandlerclass = EchoUDPHandler + if udp and threading: + testclass = ThreadingUDPServer + testhandlerclass = EchoUDPHandler + + if testclass: + test_server_fn(testclass, 10000, testhandlerclass) + + if testclient: + test_client_fn('127.0.0.1', 10000, sock_type) + +if __name__ == '__main__': + test() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:37 Message: Logged In: YES user_id=6380 Marked out of date and reduced priority until someone (Luke? Martin?) submits this as an update for test_socketmodule.py as in CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-28 14:38 Message: Logged In: YES user_id=6380 Thanks, Martin. I don't like having this much test code in the module, and the important part of the test is done by test_socketmodule.py, but I think there's one aspect that this test code does better: it starts 20 test clients in parallel. Maybe that idea could be merged into test_socketmodule.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-28 10:45 Message: Logged In: YES user_id=21627 I've attached the patch as a proper diff file. Is it still needed even though we have test_socketserver.py? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419145&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:45:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:45:14 -0700 Subject: [Patches] [ python-Patches-420753 ] Patch for bug #420725 urllib MIME header Message-ID: Patches item #420753, was opened at 2001-05-02 09:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420753&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for bug #420725 urllib MIME header Initial Comment: Fixes the bug #420725. One open issue is what to do when the script doesn't have permission to call os.stat on the file. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:45 Message: Logged In: YES user_id=6380 Closed, applied. (There's no need to open a separate patch to fix a reported bug -- please just attach the fix to the bug report.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420753&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:50:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:50:32 -0700 Subject: [Patches] [ python-Patches-424606 ] (string|unicode).(|r|l)strip Message-ID: Patches item #424606, was opened at 2001-05-16 11:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424606&group_id=5470 >Category: library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: (string|unicode).(|r|l)strip Initial Comment: This patch adds an optional parameter to the six methods (string|unicode).(|r|l)strip: This parameter, when given (and not None) specifies which string should be stripped (this works analogous to (string|unicode).split where the separator can be specified). Example " spam \r\n\r\n".rstrip("\r\n") => " spam " When the parameter is not specified or None, the behaviour is the old one: Strip any whitespace character. The functionality is exposed on the C level as two functions: PyString_Strip(PyOb *self, PyOb *strip, int left, int right) PyUnicode_Strip(PyOb *self, PyOb *strip, int left, int right) ("spam".strip(u"m") yields u"spa", which is the analogous behaviour of string.split: "spam eggs".split (u" ") yields [u"spam", u"eggs"]) string.py and UserString.py are updated accordingly. A patch to the documentation and additional test cases in Lib/test/test_string.py and Lib/test/test_unicode.py are included. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:50 Message: Logged In: YES user_id=6380 I don't think this would be used enough to warrant the added complexity. Closing as Rejected. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-05-16 11:23 Message: Logged In: YES user_id=89016 Uups, the first patch had the function declarations in the wrong files. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424606&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:53:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:53:58 -0700 Subject: [Patches] [ python-Patches-434008 ] sharedinstall must use $prefix Message-ID: Patches item #434008, was opened at 2001-06-17 15:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=434008&group_id=5470 Category: Build Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Gregor Hoffleit (flight) Assigned to: Nobody/Anonymous (nobody) Summary: sharedinstall must use $prefix Initial Comment: In the sharedinstall target of the Makefile, we have to provide setup.py with the $prefix variable. Currently, the $prefix is ignored in this call of setup.py, in this leads to strange results: When called with "make install prefix=/tmp/python/debian/tmp" (which is used in packaging Python, and works completely fine otherwise), we get this (running this is non-root user): copying build/lib.linux-i686-2.1/linuxaudiodev.so->/data/src/debian/python2-2.1/debian/tmp/usr/lib/python2.1/lib-dynload running install_scripts copying build/scripts/pydoc -> /usr/bin error: /usr/bin/pydoc: Read-only file system make[1]: *** [sharedinstall] Error 1 make[1]: Leaving directory `/data/src/debian/python2-2.1' make: *** [install-stamp] Error 2 The same kind of problem occurs with all other things that are installed by the call of the setup.py script. The attached patch cures this problem by providing the $prefix to the setup.py script. I think this is the correct way to fix it. Gregor ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:53 Message: Logged In: YES user_id=6380 Hm, the comment one line above says "This goes into $(exec_prefix)". Shouldn't setup.py be given the exec-prefix variable then? Is this still an issue if the correct -prefix option is given to the configure script? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=434008&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:54:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:54:59 -0700 Subject: [Patches] [ python-Patches-438790 ] additional mappings for mimetypes.py Message-ID: Patches item #438790, was opened at 2001-07-05 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 Category: library Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: additional mappings for mimetypes.py Initial Comment: added some additional mapping for mimetypes.py. Andreas ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:54 Message: Logged In: YES user_id=6380 Still waiting for feedback... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:42 Message: Logged In: YES user_id=21627 I believe some of these types are not "official", in the sense that they are supported by an RFC; types that are not defined in an RFC MUST use the x- prefix. E.g. in what RFC is "text/xsl" or "text/xul" defined? IOW, only types listed in http://www.isi.edu/in-notes/iana/assignments/media-types/ should be supported without x-prefix. Could you please review the entire list of known types with this respect, and update the patch accordingly? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:56:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:56:12 -0700 Subject: [Patches] [ python-Patches-439848 ] Generic AIX C++ Module Support Message-ID: Patches item #439848, was opened at 2001-07-09 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439848&group_id=5470 Category: Build Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Generic AIX C++ Module Support Initial Comment: The current support for C++ modules on AIX is out of date and incompatible with more recent compiler versions. Depending on which compiler is being used, the "load.h" include could be in any of at least three places, which may or may not be in the include path. Since only a single prototype is required, it is identical in all versions, and isn't likely to change, the simplest way to deal with the issue is to simply include the one prototype in the configuration and the dynload module. Also, the symbol is always going to live in /usr/lib/libC.a, so a simple -lC is sufficient to pull it in. I've tested it with C Set++ 3.1.4 on AIX 4.2.1 and VACPP 5.0 on AIX 4.3.3 (the two extremes, more or less) and it works fine. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:56 Message: Logged In: YES user_id=6380 This is waiting for some other AIX expert to review it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-09 14:21 Message: Logged In: NO It seems the patch didn't attach. It is pretty straightforward, though, so I'll paste it here: Index: dist/src/configure.in =================================================================== RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.223 diff -c -r1.223 configure.in *** dist/src/configure.in 2001/06/27 20:22:04 1.223 --- dist/src/configure.in 2001/07/09 20:58:17 *************** *** 874,884 **** # checks for system dependent C++ extensions support case "$ac_sys_system" in AIX*) AC_MSG_CHECKING(for genuine AIX C++ extensions support) ! AC_TRY_LINK([#include "/usr/lpp/xlC/include/load.h"], [loadAndInit("", 0, "")], [AC_DEFINE(AIX_GENUINE_CPLUSPLUS) AC_MSG_RESULT(yes)], ! [AC_MSG_RESULT(no)]);; *) ;; esac --- 874,887 ---- # checks for system dependent C++ extensions support case "$ac_sys_system" in AIX*) AC_MSG_CHECKING(for genuine AIX C++ extensions support) ! LIBS_SAVE=$LIBS ! LIBS="$LIBS -lC" ! AC_TRY_LINK([int (*loadAndInit(char *name, int flags, char *path))();], [loadAndInit("", 0, "")], [AC_DEFINE(AIX_GENUINE_CPLUSPLUS) AC_MSG_RESULT(yes)], ! [LIBS=$LIBS_SAVE ! AC_MSG_RESULT(no)]);; *) ;; esac Index: dist/src/Python/dynload_aix.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/dynload_aix.c,v retrieving revision 2.10 diff -c -r2.10 dynload_aix.c *** dist/src/Python/dynload_aix.c 2000/09/04 00:54:56 2.10 --- dist/src/Python/dynload_aix.c 2001/07/09 20:58:17 *************** *** 12,18 **** #ifdef AIX_GENUINE_CPLUSPLUS ! #include "/usr/lpp/xlC/include/load.h" #define aix_load loadAndInit #else #define aix_load load --- 12,18 ---- #ifdef AIX_GENUINE_CPLUSPLUS ! int (*loadAndInit(char *name, int flags, char *path))(); #define aix_load loadAndInit #else #define aix_load load ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-09 14:18 Message: Logged In: NO One more thing. This supports xlC-compiled modules; g++ modules are another issue entirely. We have something that works for both xlC and g++ based on the AIX loader from Apache, but g++ requires its own set of fixes for things to work properly, so the xlC-only fix seems more practical until the AIX g++ problems are ironed out. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439848&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:57:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:57:24 -0700 Subject: [Patches] [ python-Patches-441091 ] Allow jython to complete test_zlib test Message-ID: Patches item #441091, was opened at 2001-07-13 09:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441091&group_id=5470 >Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: A.M. Kuchling (akuchling) Summary: Allow jython to complete test_zlib test Initial Comment: The more advanced flush options are not availabe in java. With the patch, test_zlib will only use the advanced flush options if they are defined in the zlib module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:57 Message: Logged In: YES user_id=6380 Andrew, can you review this? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441091&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:58:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:58:49 -0700 Subject: [Patches] [ python-Patches-448038 ] a move function for shutil.py Message-ID: Patches item #448038, was opened at 2001-08-04 17:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448038&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 3 Submitted By: William McVey (wamcvey) Assigned to: Nobody/Anonymous (nobody) Summary: a move function for shutil.py Initial Comment: Although shutil.py has some nice copy functions but no real equivalent of mv(1). This is a very simple implimentation (as in not a whole lot of stuff has been implimented) but it's functional. Simply calls rename, and if that fails tries to copy and unlink. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:41 Message: Logged In: YES user_id=6380 This is OK, but only perpetuates the problem with this module -- it doesn't have a decent error handling strategy (prints to stdout!?!?!?!). If someone wants to put some more effort in this, I would recommend at least adding an option to copytree() to control error handling. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448038&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:58:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:58:05 -0700 Subject: [Patches] [ python-Patches-443626 ] TreeWidget cancellation problem Message-ID: Patches item #443626, was opened at 2001-07-22 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443626&group_id=5470 Category: IDLE Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: TreeWidget cancellation problem Initial Comment: TreeWidget was supposed to cancel editing when the user presses an Escape key. An entry was accepted anyways. Offending funcion : TreeWidget.TreeNode.edit_cancel Here is the origial: def edit_cancel(self, event=None): self.drawtext() self.canvas.focus_set() Here is the fix: def edit_cancel(self, event=None): try: self.entry.destroy() del self.entry except AttributeError: return self.drawtext() self.canvas.focus_set() The bug arose mainly because the edit_cancel did not destroy the Tkinter.Entry widget as part of the cancellation process. This obviously fixes that... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443626&group_id=5470 From noreply@sourceforge.net Thu Aug 9 18:58:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:58:18 -0700 Subject: [Patches] [ python-Patches-443626 ] TreeWidget cancellation problem Message-ID: Patches item #443626, was opened at 2001-07-22 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443626&group_id=5470 Category: IDLE >Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: TreeWidget cancellation problem Initial Comment: TreeWidget was supposed to cancel editing when the user presses an Escape key. An entry was accepted anyways. Offending funcion : TreeWidget.TreeNode.edit_cancel Here is the origial: def edit_cancel(self, event=None): self.drawtext() self.canvas.focus_set() Here is the fix: def edit_cancel(self, event=None): try: self.entry.destroy() del self.entry except AttributeError: return self.drawtext() self.canvas.focus_set() The bug arose mainly because the edit_cancel did not destroy the Tkinter.Entry widget as part of the cancellation process. This obviously fixes that... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443626&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:06:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:06:03 -0700 Subject: [Patches] [ python-Patches-403640 ] incomplete proxy handling in URLLIB Message-ID: Patches item #403640, was opened at 2001-02-06 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403640&group_id=5470 Category: library Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: incomplete proxy handling in URLLIB Initial Comment: under WinNT, the proxy code takes the proxy values from the registry, but does *not* check for the proxy override settings. The supplied patch does take care of it and works for me. Not very sophisticated, but operational. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-09 11:06 Message: Logged In: YES user_id=31435 Cleaned up the most egregious style clashes, and checked in: Lib/urllib.py, new revision: 1.129 Don't know whether it works. Didn't bother with fnmatch (simply because I'm not going to make substantive changes to code I don't understand and can't test). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:06 Message: Logged In: YES user_id=6380 I'm accepting this. The original submitter didn't care to clean it up, so I'm lowering the priority. Tim, just check it in -- if it's broken we'll hear about it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:08 Message: Logged In: YES user_id=6380 Back to you, Tim. I'm also an @home user so I can't test this either. I agree with the style comments. Also, it translates a pattern to regular expression; an easier way to do this is to use fnmatch (which also takes care of the case insensitive match when it's on Windows). Would the original submitter care to clean up the code according to the (Tim's & my) comments? Otherwise I think this is sufficiently low priority that I'm not going to move heaven & earth to get it into 2.1b2 (this Friday), and after that I'm not going to allow *anything* new in the code base for 2.1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 21:23 Message: Logged In: YES user_id=31435 Back to you! I've spent enough time on it, but I don't know this code, and it turns out I never get into it anyway. @Home uses the AutoConfigURL registry gimmick rather than ProxyEnable (which is 0 on my box) and ProxyOverride (which doesn't exist on my box). Even if they did exist, the new proxy_bypass() routine isn't called if the url passed to open_http() is a string, and it always is a string for me. Trying to trace *that* back, this is apparently because the NT getproxies() function returns {}, and again because @Home isn't enabling ProxyEnable. So best I can say is that this code doesn't hurt me. Note that there are jarring style differences with surrounding code, primarily use of Capitalized words for local vrbl names. Also lines and comments spilling past column 80. The list() call in list(proxyOverrd.split(';')) doesn't appear to make sense (.split() returns a list!). For that matter proxyOverrd is an ugly abbreviation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 23:07 Message: Logged In: YES user_id=6380 Tim, you seem to be using a proxy, so maybe you can give this a try? Also, it has Win specific code (_winreg usage). If you can't or don't want to, please give it back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403640&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:06:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:06:58 -0700 Subject: [Patches] [ python-Patches-440407 ] Remote execution patch for IDLE Message-ID: Patches item #440407, was opened at 2001-07-11 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440407&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Guido van Rossum (gvanrossum) Summary: Remote execution patch for IDLE Initial Comment: This is the code I have for the remote execution patch. (Remote execution must be enabled with an explicit command line argument -r.) Caveats: - undocumented - slow - security issue: the subprocess should not be the server but the client, to prevent a hacker from gaining access This should apply cleanly against IDLE as currently checked into the Python CVS tree. I don't want to check this in yet because of the security issue, and I don't have time to work on it. I hope the idlefork project will pick this up though and address the issues above. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 06:38 Message: Logged In: YES user_id=6380 Uploading the patch again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440407&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:13:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:13:27 -0700 Subject: [Patches] [ python-Patches-429024 ] Deal with some unary ops at compile time Message-ID: Patches item #429024, was opened at 2001-05-31 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429024&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Tim Peters (tim_one) Summary: Deal with some unary ops at compile time Initial Comment: This patch makes unary + and - operations with numeric literals compile to a constant reference instead of a constant reference and UNARY_POSITIVE or UNARY_NEGATIVE opcode. This could be extended to support UNARY_INVERT as well, but that would be a little more complicated. Folding unary + only affects one case in the regression test, but folding the - affects 817 places (on a Linux system with pretty much everything enabled). I don't know that this makes much difference at runtime, but certainly reduces the number of opcodes evaluated. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-09 11:13 Message: Logged In: YES user_id=31435 Back to Jeremy. Fred's patch is fine by me, but I'd like to see a comment before the 20 lines of mallocs and frees and strcpys explaining what the *intent* of all that stuff is (it's a lot of code to stick "-" at the front of a string ). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-06-03 21:24 Message: Logged In: YES user_id=3066 Re-assigned to Tim since Jeremy's on a new assignment. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429024&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:13:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:13:50 -0700 Subject: [Patches] [ python-Patches-429024 ] Deal with some unary ops at compile time Message-ID: Patches item #429024, was opened at 2001-05-31 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429024&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Jeremy Hylton (jhylton) Summary: Deal with some unary ops at compile time Initial Comment: This patch makes unary + and - operations with numeric literals compile to a constant reference instead of a constant reference and UNARY_POSITIVE or UNARY_NEGATIVE opcode. This could be extended to support UNARY_INVERT as well, but that would be a little more complicated. Folding unary + only affects one case in the regression test, but folding the - affects 817 places (on a Linux system with pretty much everything enabled). I don't know that this makes much difference at runtime, but certainly reduces the number of opcodes evaluated. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 11:13 Message: Logged In: YES user_id=31435 Back to Jeremy. Fred's patch is fine by me, but I'd like to see a comment before the 20 lines of mallocs and frees and strcpys explaining what the *intent* of all that stuff is (it's a lot of code to stick "-" at the front of a string ). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-06-03 21:24 Message: Logged In: YES user_id=3066 Re-assigned to Tim since Jeremy's on a new assignment. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429024&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:14:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:14:00 -0700 Subject: [Patches] [ python-Patches-438790 ] additional mappings for mimetypes.py Message-ID: Patches item #438790, was opened at 2001-07-05 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: additional mappings for mimetypes.py Initial Comment: added some additional mapping for mimetypes.py. Andreas ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2001-08-09 11:14 Message: Logged In: YES user_id=11084 The x-* mimetypes are common used although they might not be officially assigned. I would not remove these from the list. This patch also relates to bug #439710 for better support of user-defined mime-types. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:54 Message: Logged In: YES user_id=6380 Still waiting for feedback... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:42 Message: Logged In: YES user_id=21627 I believe some of these types are not "official", in the sense that they are supported by an RFC; types that are not defined in an RFC MUST use the x- prefix. E.g. in what RFC is "text/xsl" or "text/xul" defined? IOW, only types listed in http://www.isi.edu/in-notes/iana/assignments/media-types/ should be supported without x-prefix. Could you please review the entire list of known types with this respect, and update the patch accordingly? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:15:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:15:42 -0700 Subject: [Patches] [ python-Patches-441229 ] f.readline() checks for errors Message-ID: Patches item #441229, was opened at 2001-07-13 17:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441229&group_id=5470 >Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: f.readline() checks for errors Initial Comment: Previously, f.read() and f.readlines() checked for errors on their file object and possibly raised an IOError, but f.readline() didn't. This patch makes f.readline() behave like the others. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 11:15 Message: Logged In: YES user_id=6380 Applied as fileobject.c:2.117. I added a clearerr() call to match the other situations. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441229&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:18:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:18:33 -0700 Subject: [Patches] [ python-Patches-442867 ] Tests cases for mhlib.py Message-ID: Patches item #442867, was opened at 2001-07-19 12:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442867&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) >Assigned to: Guido van Rossum (gvanrossum) Summary: Tests cases for mhlib.py Initial Comment: Another installment. The mhlib module previously had no unit tests. The attatched file contains a relatively complete set of tests for mhlib.py ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 11:18 Message: Logged In: YES user_id=6380 Thanks -- checked in now! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442867&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:19:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:19:18 -0700 Subject: [Patches] [ python-Patches-438331 ] make ndiff.py into a library module Message-ID: Patches item #438331, was opened at 2001-07-03 12:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 Category: demos and tools Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Tim Peters (tim_one) Summary: make ndiff.py into a library module Initial Comment: Here's a patch to make ndiff.py's functionality generally available to Python programs. It should move from Tools/scripts/ to Lib/. ndiff.py's functionality is very useful for making comparisons human-readable. I wanted to use it from my Python code (unittest's of generated XML), but unfortunately ndiff.py wasn't written that way. So I refactored out the lists-of-strings comparison code from fcompare() into lcompare(), and parameterized the formerly hard-coded IS_*_JUNK filters. I'd like to see it further converted to return a diff string, rather than only spew to stdout. It's easy enough to capture stdout, but klugey. I will do the mods if they have a good-to-certain chance of making it in. (Please let me know.) Also, give me the word and I will whip up some TeX docs if Tim doesn't have the time. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-09 11:19 Message: Logged In: YES user_id=31435 I *believe* this patch is "obsoleted" by David's two later patches, so am closing this as Duplicate (we don't really have a good way to say Withdrawn or Superceded). ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-27 21:36 Message: Logged In: YES user_id=7733 Submitted new patches for difflib & ndiff (http:// sourceforge.net/tracker/?func=detail&aid=445412& group_id=5470&atid=305470), and docs (http:// sourceforge.net/tracker/?func=detail&aid=445413& group_id=5470&atid=305470). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 20:51 Message: Logged In: YES user_id=31435 David, Guido has given his blessing to this. Refactoring released functionality is too minor to require a PEP, so long as ndiff "still works" in the end -- all that changes is (I hope) that difflib grews a new capability. Just don't forget the docstrings . ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-04 20:49 Message: Logged In: YES user_id=7733 Tim: Your doctest example is spot-on. That's exactly what I'm using ndiff for, within unit tests. I will work on a clean class to add to difflib.py, implementing the ndiff functionality. PEP required? (No, I'm not going for a record.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-04 19:27 Message: Logged In: YES user_id=31435 Fred, I think I understand what David's after. ndiff has a great deal of logic for comparing "files" as sequences of lines which are in turn sequences of characters, on top of what difflib.py provides (in fact, only the easiest part was factored out). Whether that should go into the std library is a legit question, though. I'll ask Guido about it; if he's at all inclined to say "yes", I bet it would only be because he trusts me to maintain it for the rest of my life <0.7 wink>. I've wanted this at times too; e.g., doctest would love to do a clearer job of showing "expected" vs "but got" outcomes than just listing both in full without any correlation. David, if you want to do this you should supply a proper "file-like object" comparison class instead. You appear to be aiming more at minimal changes here than at clean library design. I'd rather see a clean new class added to difflib.py, the use of which could reduce ndiff.py to a one-pager (or so). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:26 Message: Logged In: YES user_id=3066 Is this still relevant in light of ndiff being factored into the ndiff.py script and the difflib library module? difflib is already documented. Assigning to Tim since this is his baby. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:22:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:22:47 -0700 Subject: [Patches] [ python-Patches-444750 ] os.statvfs support for BSD Message-ID: Patches item #444750, was opened at 2001-07-26 04:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444750&group_id=5470 Category: library Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: os.statvfs support for BSD Initial Comment: BSD systems have the statfs(2) call; we use that one to fake statvfs(). See the code for more comments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-28 02:10 Message: Logged In: YES user_id=21627 I think fstatfs cannot be used to emulate statvfs, since it expects a file descriptor, not a path. It would be very confusing if the function is there on some system but does not expect a path. In general, I feel that this emulation is not appropriate. posix exposes system calls as-is, so it should add statfs and fstatfs calls, instead of trying to emulate statvfs. It might then be useful to put a function into os to portably access pieces of information, e.g. free disk space. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 04:26 Message: Logged In: NO Oops, in case there are questions left, here's my email address: tg@FreeBSD.org. tg ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444750&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:22:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:22:26 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: M.-A. Lemburg (lemburg) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-09 11:22 Message: Logged In: YES user_id=31435 Marc-Andre, if there's some specific line or section of code here you're worried about, please try to explain the hangup in detail. The code looks "almost obviously correct" to me, and I assume it did to /F too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-08 09:25 Message: Logged In: YES user_id=31435 The switch to unsigned char is coupled with code to read and write one byte at a time; it should work fine on any box where an unsigned char is 8 bits (incl. Palm Pilots and Crays); and on any box where it's larger than 8 bits (I don't of any such box) provided input routines arrange to store only 8 bits per native machine byte. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 01:58 Message: Logged In: YES user_id=38388 It seems that you have replaced Py_UCS2 with "unsigned char" in the latest patch. This won't work for obvious reasons (maybe on Crays, don't know ;-). Shouldn't this have been "unsigned int" ?! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-03 16:56 Message: Logged In: YES user_id=31435 New patch attached, and back to MAL. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 22:59 Message: Logged In: YES user_id=31435 Marked Out of Date as per MAL's remark, and assigned back to me. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:39 Message: Logged In: YES user_id=38388 Tim, please resubmit the patch -- it no longer applies to the current CVS tree. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Thu Aug 9 19:40:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:40:05 -0700 Subject: [Patches] [ python-Patches-403671 ] Allow jython to complete the test_class test Message-ID: Patches item #403671, was opened at 2001-02-07 13:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403671&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to complete the test_class test Initial Comment: A breakdown of the changes: - the __del__ method must be present at class definition time for jython to use it. - slices pass into __xxxitem__ works, but the default values are not "0, maxint, None" but "None, None, 1". At this time this is a known difference. - in jython the __int__, __long__ etc methods must return a correctly typed value. The test that just return None is skipped. - An explicit call to GC is required to force a call to __del__. The two changes that just adds a print "the expected result" is really ugly, but it is necessary for jython to generate the same output as python. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-08-09 11:40 Message: Logged In: YES user_id=4201 Yes, combatibility have not improved in any of these areas. Jython still needs helps like this patch to pass the test. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:23 Message: Logged In: YES user_id=6380 Accepted. I'll leave it to Barry to check this in. (Finn, do you still need this? I assume so!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403671&group_id=5470 From noreply@sourceforge.net Thu Aug 9 20:26:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 12:26:04 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: M.-A. Lemburg (lemburg) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-09 12:26 Message: Logged In: YES user_id=38388 Sorry, it turned out that I was looking a the wrong part of the patch... what worried me was these compares, but they are part of the original, not your patched version: ! if (*q == 0xFEFF) { ! q++; bo = -1; ! } else if (*q == 0xFFFE) { ! q++; bo = 1; } Given my mistake, I'd say, the patch looks OK :-) Just two nits: 1. #defining macros inside functions isn't portable AFAIK. Better put the STORECHAR before the function and then #undef it just behind it. 2. The hiliho thingie is likely going to slow down the codec; we'll leave that for the next generation, if you don't mind ;-) Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 11:22 Message: Logged In: YES user_id=31435 Marc-Andre, if there's some specific line or section of code here you're worried about, please try to explain the hangup in detail. The code looks "almost obviously correct" to me, and I assume it did to /F too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-08 09:25 Message: Logged In: YES user_id=31435 The switch to unsigned char is coupled with code to read and write one byte at a time; it should work fine on any box where an unsigned char is 8 bits (incl. Palm Pilots and Crays); and on any box where it's larger than 8 bits (I don't of any such box) provided input routines arrange to store only 8 bits per native machine byte. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 01:58 Message: Logged In: YES user_id=38388 It seems that you have replaced Py_UCS2 with "unsigned char" in the latest patch. This won't work for obvious reasons (maybe on Crays, don't know ;-). Shouldn't this have been "unsigned int" ?! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-03 16:56 Message: Logged In: YES user_id=31435 New patch attached, and back to MAL. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 22:59 Message: Logged In: YES user_id=31435 Marked Out of Date as per MAL's remark, and assigned back to me. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:39 Message: Logged In: YES user_id=38388 Tim, please resubmit the patch -- it no longer applies to the current CVS tree. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Thu Aug 9 20:34:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 12:34:39 -0700 Subject: [Patches] [ python-Patches-449367 ] HTTPS client authentication in httplib Message-ID: Patches item #449367, was opened at 2001-08-08 19:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449367&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: George Yang (gyang) Assigned to: Greg Stein (gstein) Summary: HTTPS client authentication in httplib Initial Comment: HTTPS is different from HTTP only by: --connection_class In HTTP.__Init__: the old code use self._connection_class(host, port) It fails to pass the x509 argument to the HTTPSConnection, which makes SSL client authentication fails. So, it should be self._connection_class(host, port, **x509) ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-09 12:34 Message: Logged In: YES user_id=6501 Seems reasonable at first glance. I'll handle this next week with the other HTTP/proxy/DAV work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 06:25 Message: Logged In: YES user_id=6380 Greg, what he says seems to make sense, but I dun't understand the code enough -- and I thought that https:// URLs actually worked, so I'm not sure when they don't work. Can you review the patch and check it in if it's right? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449367&group_id=5470 From noreply@sourceforge.net Thu Aug 9 20:46:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 12:46:50 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-09 12:46 Message: Logged In: YES user_id=31435 Changed to Accepted and assigned back to me. I'll check it in later tonight. Thanks! Macros are defined and expanded in the preprocessor stage; they don't care about function boundaries, in part because the preprocessor has no idea what anything "means" (i.e., the source code is just a giant string of characters to the preprocessor). I haven't timed it, but wouldn't be surprised if it were actually faster now: it removes all need for runtime enddianess tests and branches in the inner loops. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-09 12:26 Message: Logged In: YES user_id=38388 Sorry, it turned out that I was looking a the wrong part of the patch... what worried me was these compares, but they are part of the original, not your patched version: ! if (*q == 0xFEFF) { ! q++; bo = -1; ! } else if (*q == 0xFFFE) { ! q++; bo = 1; } Given my mistake, I'd say, the patch looks OK :-) Just two nits: 1. #defining macros inside functions isn't portable AFAIK. Better put the STORECHAR before the function and then #undef it just behind it. 2. The hiliho thingie is likely going to slow down the codec; we'll leave that for the next generation, if you don't mind ;-) Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 11:22 Message: Logged In: YES user_id=31435 Marc-Andre, if there's some specific line or section of code here you're worried about, please try to explain the hangup in detail. The code looks "almost obviously correct" to me, and I assume it did to /F too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-08 09:25 Message: Logged In: YES user_id=31435 The switch to unsigned char is coupled with code to read and write one byte at a time; it should work fine on any box where an unsigned char is 8 bits (incl. Palm Pilots and Crays); and on any box where it's larger than 8 bits (I don't of any such box) provided input routines arrange to store only 8 bits per native machine byte. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 01:58 Message: Logged In: YES user_id=38388 It seems that you have replaced Py_UCS2 with "unsigned char" in the latest patch. This won't work for obvious reasons (maybe on Crays, don't know ;-). Shouldn't this have been "unsigned int" ?! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-03 16:56 Message: Logged In: YES user_id=31435 New patch attached, and back to MAL. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 22:59 Message: Logged In: YES user_id=31435 Marked Out of Date as per MAL's remark, and assigned back to me. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:39 Message: Logged In: YES user_id=38388 Tim, please resubmit the patch -- it no longer applies to the current CVS tree. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Thu Aug 9 20:51:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 12:51:48 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 12:51 Message: Logged In: YES user_id=6380 I agree with Tim: macros inside functions are perfectly portable (at least as portable as listobject.c :-). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 12:46 Message: Logged In: YES user_id=31435 Changed to Accepted and assigned back to me. I'll check it in later tonight. Thanks! Macros are defined and expanded in the preprocessor stage; they don't care about function boundaries, in part because the preprocessor has no idea what anything "means" (i.e., the source code is just a giant string of characters to the preprocessor). I haven't timed it, but wouldn't be surprised if it were actually faster now: it removes all need for runtime enddianess tests and branches in the inner loops. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-09 12:26 Message: Logged In: YES user_id=38388 Sorry, it turned out that I was looking a the wrong part of the patch... what worried me was these compares, but they are part of the original, not your patched version: ! if (*q == 0xFEFF) { ! q++; bo = -1; ! } else if (*q == 0xFFFE) { ! q++; bo = 1; } Given my mistake, I'd say, the patch looks OK :-) Just two nits: 1. #defining macros inside functions isn't portable AFAIK. Better put the STORECHAR before the function and then #undef it just behind it. 2. The hiliho thingie is likely going to slow down the codec; we'll leave that for the next generation, if you don't mind ;-) Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 11:22 Message: Logged In: YES user_id=31435 Marc-Andre, if there's some specific line or section of code here you're worried about, please try to explain the hangup in detail. The code looks "almost obviously correct" to me, and I assume it did to /F too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-08 09:25 Message: Logged In: YES user_id=31435 The switch to unsigned char is coupled with code to read and write one byte at a time; it should work fine on any box where an unsigned char is 8 bits (incl. Palm Pilots and Crays); and on any box where it's larger than 8 bits (I don't of any such box) provided input routines arrange to store only 8 bits per native machine byte. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 01:58 Message: Logged In: YES user_id=38388 It seems that you have replaced Py_UCS2 with "unsigned char" in the latest patch. This won't work for obvious reasons (maybe on Crays, don't know ;-). Shouldn't this have been "unsigned int" ?! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-03 16:56 Message: Logged In: YES user_id=31435 New patch attached, and back to MAL. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 22:59 Message: Logged In: YES user_id=31435 Marked Out of Date as per MAL's remark, and assigned back to me. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:39 Message: Logged In: YES user_id=38388 Tim, please resubmit the patch -- it no longer applies to the current CVS tree. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Thu Aug 9 22:10:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 14:10:42 -0700 Subject: [Patches] [ python-Patches-438790 ] additional mappings for mimetypes.py Message-ID: Patches item #438790, was opened at 2001-07-05 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: additional mappings for mimetypes.py Initial Comment: added some additional mapping for mimetypes.py. Andreas ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-09 14:10 Message: Logged In: YES user_id=21627 I wasn't complaining about the x- types (application/x-javascript); they are fine. I was complaining about using unregistered types without an x- prefix, specifically + '.xsl': 'text/xsl', + '.xul': 'text/xul' These are not valid MIME types, unless I'm missing something. More generally, I was requesting that the IANA registry is analysed and this patch is brought in sync with it. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-08-09 11:14 Message: Logged In: YES user_id=11084 The x-* mimetypes are common used although they might not be officially assigned. I would not remove these from the list. This patch also relates to bug #439710 for better support of user-defined mime-types. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:54 Message: Logged In: YES user_id=6380 Still waiting for feedback... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:42 Message: Logged In: YES user_id=21627 I believe some of these types are not "official", in the sense that they are supported by an RFC; types that are not defined in an RFC MUST use the x- prefix. E.g. in what RFC is "text/xsl" or "text/xul" defined? IOW, only types listed in http://www.isi.edu/in-notes/iana/assignments/media-types/ should be supported without x-prefix. Could you please review the entire list of known types with this respect, and update the patch accordingly? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 From noreply@sourceforge.net Thu Aug 9 22:23:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 14:23:50 -0700 Subject: [Patches] [ python-Patches-428326 ] Timer class for threading Message-ID: Patches item #428326, was opened at 2001-05-29 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: Timer class for threading Initial Comment: The Timer class allows you to schedule an action to happen at some time in the future, using a thread. For example: def f(): print "30 seconds have passed" t = Timer(30.0, f) t.start() # after 30 seconds f will be called try: # .... other stuff except SystemExit: t.cancel() # cancel the timer since we are shutting down It allows passing arguments and keyword arguments to the function that is called. It also allows *cancelling* the timer. That is, if the timer is still waiting, we can tell it to stop its operation. Why should this be in the standard library? 1. Timers are a standard, useful programming idiom. 2. It can be used as an example of how to: a. create subclasses of threading.Thread b. make threads that can be "stopped" If this patch is approved I will then write documentation. I'm not sure how to go about writing tests for it. ---------------------------------------------------------------------- >Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-08-09 14:23 Message: Logged In: YES user_id=32065 1) license can be python's and copyright PSF's 2) I will write docs and tests 3) not sure when, maybe this weekend One question - timers actually seem to be a task that happens repeatedly every X seconds (e.g. in wxWindows). Should I add that functionality (do a task every X seconds, N times, N is either >= 1 or infinite) or just rename the class? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 13:53 Message: Logged In: YES user_id=6380 I like it too. But I don't want itamar's license anywhere in the distribution -- too wordy. I agree that the PSF should clear up the licensing situation; we're working on that but it's slow going (nobody likes this work :-( ). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:32 Message: Logged In: YES user_id=21627 I'm in favour of approving this patch, as an extension to the threading module. Are you willing to draft a patch to the documentation (libthreading.tex) as well? Ideally, there would also be a set of regression tests in a test_threading file; it would be acceptable if this only tests your feature for the moment. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 09:40 Message: Logged In: YES user_id=32065 There was a licensing discussion on python-dev which no one bothered to CC me on :). Yes, this can be relicensed under the PSF license. I suggest someone write up some sort of guidelines for submitted patches and improvement explain the whole licensing and copyright issues. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 02:16 Message: Logged In: YES user_id=32065 OK, I'm un-withdrawing this patch. Just had to get things straight with our lawyer. The patch is released under the following license (the X11 license with 4 extra paragraphs of disclaimers :): http://www.zoteca.com/opensource/LICENSE.txt ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-29 09:45 Message: Logged In: YES user_id=32065 I'm withdrawing this patch for a short period of time for non-technical reasons, hopefully I can put it back soon. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 From noreply@sourceforge.net Thu Aug 9 22:37:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 14:37:32 -0700 Subject: [Patches] [ python-Patches-448305 ] Additions to the C API Message-ID: Patches item #448305, was opened at 2001-08-05 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: Additions to the C API Initial Comment: I'm not sure a PEP is required for this patch, but these functions are pre-requisiste for two other PEP in the pipe... I have not always had easy access to news posting, so I'll be the happier this can go through without all the PEP overhead, otherwise, I'll try to follow up the PEP. I'm submitting this as a PEP in the same time, to the Director of PEP Affairs, as indicated in the PEP meta PEP 000 (barry), with a reference to this patch (file attached). Frederic Giacometti --------------------------- PEP XXX: Additions to the C API fred@arakne.com (Frederic Giacometti) Abstract This PEP defines a couple of C functions. The first two functions are for raising exceptions with multiple arguments; the third one is for calling a method when an arg tuple is given; and the other ones programmatically define sys.path and the optimization level in embedded python context, before initialization of the global Python engine. Copyright: This document is published under the Open Publication License. Specification: PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) Raise the exception created by applying args to exctype. This is equivalent to the Python expression raise apply( exctype, args). Always set the error state and return NULL. PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) This function is similar to PyErr_RaiseArgs(), but defines the arguments using the same convention as Py_BuildValue(). Always set the error state and return NULL. PyObject* PyObject_CallMethodArgs( PyObject* o, char const* method, PyObject* args) Call the method named 'method' with arguments given by the tuple args, using for args the same convention as PyObject_CallObject(). This is the equivalent of the Python expression o.method( args). Note that special method names, such as __add__(), __getitem__(), and so on are not supported. The specific abstract-object routines for these must be used. void Py_SetPythonPath( char const* path) This function should be called before Py_Initialize() is called for the first time, if it is called at all. It defines the PYTHONPATH value to be used by the interpreter. Calling Py_SetPythonPath() will override the PYTHONPATH value from the environment. The argument should be NULL, or point to a zero-terminated character string which will not change for the duration of the program's execution. char const* Py_GetPythonPath() If Py_SetPythonPath() was never called, getenv( "PYTHONPATH") is returned, otherwise the argument of Py_SetPythonPath() is returned. The returned string points into static storage. void Py_SetOptimizeLevel( int level) This function should be called before Py_Initialize() is called for the first time. Legal optimization levels are listed below. \begin{tableii}{c|l}{character}{Character}{Meaning} \lineii{0}{No optimization (use \code{.pyc} files by default)} \lineii{1}{Same as \code{python -O}} \lineii{2}{Same as \code{python -OO}} \end{tableii} int Py_GetOptimizeLevel() Return the interpreter optimization level. Reference Implementation: See attached patch (concatenation of 2 patch files). ---------------------------------------------------------------------- >Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 14:37 Message: Logged In: YES user_id=93657 1) Patch for PyErr_Raise: I manually edited the patch file, since I had the ImportNotFound changes with it. The entire patch is in cdiff file attached to http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448488&group_id=5470 Meanwhile, I'm pasting below the missing section. 2) I'm going to make a quick search on the existing base for replacement opportunities. 3) CallMethodArgs vs. CallMethodArgs with keywords: The main reason is that the implementation relies on the exsiting PyObject_CallObject function, with does not take keyword args... However, your remark is relevant, and two other functions would be needed to complete the call interface: PyObject_CallObjectWithKW and PyObject_CallMethodArgsWithKW... I'd say that use of keyword arg from the C API is unusual; since I've never needed them, I haven't implemented them... Index: Python/errors.c =================================================================== RCS file: /cvs/python/Python/Python/errors.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 errors.c *** Python/errors.c 2001/05/27 15:36:36 1.1.1.1 --- Python/errors.c 2001/06/05 16:11:16 *************** *** 514,519 **** --- 514,571 ---- } + PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) + { + PyObject* exception; + exception = PyObject_CallObject( exctype, args); + if (! exception) return NULL; + PyErr_SetObject( exctype, exception); + return NULL; + } + + PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) + { + PyObject* args = NULL, *result = NULL; + va_list va; + + va_start( va, format); + args = format ? Py_VaBuildValue( (char*)format, va) : PyTuple_New(0); + va_end(va); + + if (! args) goto Finally; + if (! PyTuple_Check( args)) { + PyObject* newargs; + newargs = PyTuple_New( 1); + if (! newargs) goto Finally; + PyTuple_SET_ITEM( newargs, 0, args); + args = newargs; + } + + result = PyErr_RaiseArgs( exctype, args); + Finally: + Py_XDECREF(args); + return result; + } + PyObject * PyErr_NewException(char *name, PyObject *base, PyObject *dict) { ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:16 Message: Logged In: YES user_id=21627 It seems that your patch is somewhat confused: It contains fragments of the SetPythonPath code, but fails to include the implementation of PyErr_Raise[Args]. I think the patch should also identify the places in the code that could make use of the offered simplifications (and change them to the new API), to get an impression of how general this API is. I'm +1 on the _Raise functions and -0 on the CallMethodArgs (why does it not support keyword arguments?). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 From noreply@sourceforge.net Thu Aug 9 22:45:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 14:45:28 -0700 Subject: [Patches] [ python-Patches-428326 ] Timer class for threading Message-ID: Patches item #428326, was opened at 2001-05-29 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: Timer class for threading Initial Comment: The Timer class allows you to schedule an action to happen at some time in the future, using a thread. For example: def f(): print "30 seconds have passed" t = Timer(30.0, f) t.start() # after 30 seconds f will be called try: # .... other stuff except SystemExit: t.cancel() # cancel the timer since we are shutting down It allows passing arguments and keyword arguments to the function that is called. It also allows *cancelling* the timer. That is, if the timer is still waiting, we can tell it to stop its operation. Why should this be in the standard library? 1. Timers are a standard, useful programming idiom. 2. It can be used as an example of how to: a. create subclasses of threading.Thread b. make threads that can be "stopped" If this patch is approved I will then write documentation. I'm not sure how to go about writing tests for it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 14:45 Message: Logged In: YES user_id=6380 Good! I don't think there's a standard definition of timers -- I've seen both. A more general timer that can go off N times, defaulting to once, sounds like a nice API. Hm, I can actually only think of two usage scenarios: either you want it to go off once, or you want it to repeat until you cancel it. Think about it. There's also the msg from Aahz in the python-dev list where he claims he doesn't like something about this without saying what. I hope he clarifies that in this SF tracker item. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-08-09 14:23 Message: Logged In: YES user_id=32065 1) license can be python's and copyright PSF's 2) I will write docs and tests 3) not sure when, maybe this weekend One question - timers actually seem to be a task that happens repeatedly every X seconds (e.g. in wxWindows). Should I add that functionality (do a task every X seconds, N times, N is either >= 1 or infinite) or just rename the class? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 13:53 Message: Logged In: YES user_id=6380 I like it too. But I don't want itamar's license anywhere in the distribution -- too wordy. I agree that the PSF should clear up the licensing situation; we're working on that but it's slow going (nobody likes this work :-( ). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:32 Message: Logged In: YES user_id=21627 I'm in favour of approving this patch, as an extension to the threading module. Are you willing to draft a patch to the documentation (libthreading.tex) as well? Ideally, there would also be a set of regression tests in a test_threading file; it would be acceptable if this only tests your feature for the moment. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 09:40 Message: Logged In: YES user_id=32065 There was a licensing discussion on python-dev which no one bothered to CC me on :). Yes, this can be relicensed under the PSF license. I suggest someone write up some sort of guidelines for submitted patches and improvement explain the whole licensing and copyright issues. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 02:16 Message: Logged In: YES user_id=32065 OK, I'm un-withdrawing this patch. Just had to get things straight with our lawyer. The patch is released under the following license (the X11 license with 4 extra paragraphs of disclaimers :): http://www.zoteca.com/opensource/LICENSE.txt ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-29 09:45 Message: Logged In: YES user_id=32065 I'm withdrawing this patch for a short period of time for non-technical reasons, hopefully I can put it back soon. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 From noreply@sourceforge.net Thu Aug 9 23:10:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 15:10:58 -0700 Subject: [Patches] [ python-Patches-449637 ] Remove NT special case in asycnore Message-ID: Patches item #449637, was opened at 2001-08-09 15:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Tim Peters (tim_one) Summary: Remove NT special case in asycnore Initial Comment: asyncore uses socket error codes like EWOULDBLOCK and EALREADY. On Unix, it gets the values from errno. On NT, it has hard-coded constants. The constants match the values I see in errno on Win2k. Therefore, I assume that errno should be used on both platforms. I'm not sure if older versions of Windows are different in this repsect. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 From noreply@sourceforge.net Thu Aug 9 23:24:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 15:24:01 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-09 15:24 Message: Logged In: YES user_id=31435 Checked in. Note that I also removed the now-unused Py_UCS2 defn. from unicodeobject.h. If someone wants to add that back, with the portable meaning of "at *least* 2 bytes", unsigned short would be good enough. Include/unicodeobject.h; new revision: 2.30 Objects/unicodeobject.c; new revision: 2.107 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 12:51 Message: Logged In: YES user_id=6380 I agree with Tim: macros inside functions are perfectly portable (at least as portable as listobject.c :-). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 12:46 Message: Logged In: YES user_id=31435 Changed to Accepted and assigned back to me. I'll check it in later tonight. Thanks! Macros are defined and expanded in the preprocessor stage; they don't care about function boundaries, in part because the preprocessor has no idea what anything "means" (i.e., the source code is just a giant string of characters to the preprocessor). I haven't timed it, but wouldn't be surprised if it were actually faster now: it removes all need for runtime enddianess tests and branches in the inner loops. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-09 12:26 Message: Logged In: YES user_id=38388 Sorry, it turned out that I was looking a the wrong part of the patch... what worried me was these compares, but they are part of the original, not your patched version: ! if (*q == 0xFEFF) { ! q++; bo = -1; ! } else if (*q == 0xFFFE) { ! q++; bo = 1; } Given my mistake, I'd say, the patch looks OK :-) Just two nits: 1. #defining macros inside functions isn't portable AFAIK. Better put the STORECHAR before the function and then #undef it just behind it. 2. The hiliho thingie is likely going to slow down the codec; we'll leave that for the next generation, if you don't mind ;-) Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 11:22 Message: Logged In: YES user_id=31435 Marc-Andre, if there's some specific line or section of code here you're worried about, please try to explain the hangup in detail. The code looks "almost obviously correct" to me, and I assume it did to /F too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-08 09:25 Message: Logged In: YES user_id=31435 The switch to unsigned char is coupled with code to read and write one byte at a time; it should work fine on any box where an unsigned char is 8 bits (incl. Palm Pilots and Crays); and on any box where it's larger than 8 bits (I don't of any such box) provided input routines arrange to store only 8 bits per native machine byte. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-08 01:58 Message: Logged In: YES user_id=38388 It seems that you have replaced Py_UCS2 with "unsigned char" in the latest patch. This won't work for obvious reasons (maybe on Crays, don't know ;-). Shouldn't this have been "unsigned int" ?! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-03 16:56 Message: Logged In: YES user_id=31435 New patch attached, and back to MAL. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 22:59 Message: Logged In: YES user_id=31435 Marked Out of Date as per MAL's remark, and assigned back to me. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:39 Message: Logged In: YES user_id=38388 Tim, please resubmit the patch -- it no longer applies to the current CVS tree. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Thu Aug 9 23:26:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 15:26:45 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Thu Aug 9 23:36:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 15:36:51 -0700 Subject: [Patches] [ python-Patches-448305 ] Additions to the C API Message-ID: Patches item #448305, was opened at 2001-08-05 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: Additions to the C API Initial Comment: I'm not sure a PEP is required for this patch, but these functions are pre-requisiste for two other PEP in the pipe... I have not always had easy access to news posting, so I'll be the happier this can go through without all the PEP overhead, otherwise, I'll try to follow up the PEP. I'm submitting this as a PEP in the same time, to the Director of PEP Affairs, as indicated in the PEP meta PEP 000 (barry), with a reference to this patch (file attached). Frederic Giacometti --------------------------- PEP XXX: Additions to the C API fred@arakne.com (Frederic Giacometti) Abstract This PEP defines a couple of C functions. The first two functions are for raising exceptions with multiple arguments; the third one is for calling a method when an arg tuple is given; and the other ones programmatically define sys.path and the optimization level in embedded python context, before initialization of the global Python engine. Copyright: This document is published under the Open Publication License. Specification: PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) Raise the exception created by applying args to exctype. This is equivalent to the Python expression raise apply( exctype, args). Always set the error state and return NULL. PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) This function is similar to PyErr_RaiseArgs(), but defines the arguments using the same convention as Py_BuildValue(). Always set the error state and return NULL. PyObject* PyObject_CallMethodArgs( PyObject* o, char const* method, PyObject* args) Call the method named 'method' with arguments given by the tuple args, using for args the same convention as PyObject_CallObject(). This is the equivalent of the Python expression o.method( args). Note that special method names, such as __add__(), __getitem__(), and so on are not supported. The specific abstract-object routines for these must be used. void Py_SetPythonPath( char const* path) This function should be called before Py_Initialize() is called for the first time, if it is called at all. It defines the PYTHONPATH value to be used by the interpreter. Calling Py_SetPythonPath() will override the PYTHONPATH value from the environment. The argument should be NULL, or point to a zero-terminated character string which will not change for the duration of the program's execution. char const* Py_GetPythonPath() If Py_SetPythonPath() was never called, getenv( "PYTHONPATH") is returned, otherwise the argument of Py_SetPythonPath() is returned. The returned string points into static storage. void Py_SetOptimizeLevel( int level) This function should be called before Py_Initialize() is called for the first time. Legal optimization levels are listed below. \begin{tableii}{c|l}{character}{Character}{Meaning} \lineii{0}{No optimization (use \code{.pyc} files by default)} \lineii{1}{Same as \code{python -O}} \lineii{2}{Same as \code{python -OO}} \end{tableii} int Py_GetOptimizeLevel() Return the interpreter optimization level. Reference Implementation: See attached patch (concatenation of 2 patch files). ---------------------------------------------------------------------- >Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 15:36 Message: Logged In: YES user_id=93657 A) Direct code replacement. Here is a non-exhaustive list of occurences: pythonrun.c-2.1:1242 w = Py_BuildValue("(sO)", msg, v); Py_XDECREF(v); PyErr_SetObject(errtype, w); Py_XDECREF(w); --> PyErr_Raise( errtype, "sO", msg, v); Py_XDECREF( v); errors.c:towards 303 and 350: if (filename != NULL) v = Py_BuildValue("(iss)", err, s, filename); else v = Py_BuildValue("(is)", err, s); if (v != NULL) { PyErr_SetObject(PyExc_WindowsError, v); Py_DECREF(v); --> if (filename) PyErr_Raise( Pyexc_WindowsError, "iss", err, s, filename) else PyErr_Raise( ..., "is", err, s); compile.c: 421 w = Py_BuildValue("(OO)", v, t); if (w == NULL) goto exit; PyErr_SetObject(exc, w); --> PyErr_Raise( exc, "OO", v, t) Modules/socketmodules.c:361 v = Py_BuildValue("(is)", myerrorcode, outbuf); if (v != NULL) { PyErr_SetObject(PySocket_Error, v); Py_DECREF(v); } return NULL; --> return PyErr_Raise( PySocketError, "is", myerrorcode, outbuf); posixmodule.c:441 v = Py_BuildValue("(is)", code, text); if (v != NULL) { PyErr_SetObject(PyExc_OSError, v); Py_DECREF(v); } return NULL; /* Signal to Python that an Exception is Pending */ --> return PyErr_Raise( PyExc_OSError, "is", code, text); ..... B) Other use of PyErr_Raise* in the current code base: ---------------------------------------------- As of today, there are 3 functions for raising a new exception: - PyErr_SetString (1118 occurences) - PyErr_Format (158 occurences) - PyErr_SetObject (48 occurences) PyErr_Raise( exctype, "O", obj) would replace PyErr_SetObject( exctype, obj) PyErr_Raise( exctype, "s", msg) would replace PyErr_SetString( exctype, msg) PyErr_SetObject and PyErr_SetString could then both be deprecated, in cases the arg is not already an instance of the exception... Here is some explaination: Historically, Python was first working with string exceptions, only. Structured object-oriented exceptions were introduced only towards the 1.5 releases, I think (very approximately - I've only used python 1.5.1 or later...). It is not also also how the current API works with exception whose __init__ require more than two args, and process them. If you want to raise an exception with an __init__ that has to or more args, there is presently no clear way of doing it; this is where i created the PyErr_Raise* functions. There is also the case where one would define an exception which does not accept a string object as __init__ argument... PyErr_SetString would create problem there too. Furthermore, the exact semantics and workings of PyErr_Object are not clear, with regard to the type of the object passed (this is fine when the object is already an instance of the exception class, but when it is not an instance of the exception class, huum). Use of PyErr_Raise would clarify this... ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 14:37 Message: Logged In: YES user_id=93657 1) Patch for PyErr_Raise: I manually edited the patch file, since I had the ImportNotFound changes with it. The entire patch is in cdiff file attached to http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448488&group_id=5470 Meanwhile, I'm pasting below the missing section. 2) I'm going to make a quick search on the existing base for replacement opportunities. 3) CallMethodArgs vs. CallMethodArgs with keywords: The main reason is that the implementation relies on the exsiting PyObject_CallObject function, with does not take keyword args... However, your remark is relevant, and two other functions would be needed to complete the call interface: PyObject_CallObjectWithKW and PyObject_CallMethodArgsWithKW... I'd say that use of keyword arg from the C API is unusual; since I've never needed them, I haven't implemented them... Index: Python/errors.c =================================================================== RCS file: /cvs/python/Python/Python/errors.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 errors.c *** Python/errors.c 2001/05/27 15:36:36 1.1.1.1 --- Python/errors.c 2001/06/05 16:11:16 *************** *** 514,519 **** --- 514,571 ---- } + PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) + { + PyObject* exception; + exception = PyObject_CallObject( exctype, args); + if (! exception) return NULL; + PyErr_SetObject( exctype, exception); + return NULL; + } + + PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) + { + PyObject* args = NULL, *result = NULL; + va_list va; + + va_start( va, format); + args = format ? Py_VaBuildValue( (char*)format, va) : PyTuple_New(0); + va_end(va); + + if (! args) goto Finally; + if (! PyTuple_Check( args)) { + PyObject* newargs; + newargs = PyTuple_New( 1); + if (! newargs) goto Finally; + PyTuple_SET_ITEM( newargs, 0, args); + args = newargs; + } + + result = PyErr_RaiseArgs( exctype, args); + Finally: + Py_XDECREF(args); + return result; + } + PyObject * PyErr_NewException(char *name, PyObject *base, PyObject *dict) { ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:16 Message: Logged In: YES user_id=21627 It seems that your patch is somewhat confused: It contains fragments of the SetPythonPath code, but fails to include the implementation of PyErr_Raise[Args]. I think the patch should also identify the places in the code that could make use of the offered simplifications (and change them to the new API), to get an impression of how general this API is. I'm +1 on the _Raise functions and -0 on the CallMethodArgs (why does it not support keyword arguments?). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 From noreply@sourceforge.net Fri Aug 10 02:22:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 18:22:01 -0700 Subject: [Patches] [ python-Patches-438790 ] additional mappings for mimetypes.py Message-ID: Patches item #438790, was opened at 2001-07-05 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: additional mappings for mimetypes.py Initial Comment: added some additional mapping for mimetypes.py. Andreas ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2001-08-09 18:22 Message: Logged In: YES user_id=11084 the mimetypes for .xsl and xul are also in common usage. Andreas ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-09 14:10 Message: Logged In: YES user_id=21627 I wasn't complaining about the x- types (application/x-javascript); they are fine. I was complaining about using unregistered types without an x- prefix, specifically + '.xsl': 'text/xsl', + '.xul': 'text/xul' These are not valid MIME types, unless I'm missing something. More generally, I was requesting that the IANA registry is analysed and this patch is brought in sync with it. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-08-09 11:14 Message: Logged In: YES user_id=11084 The x-* mimetypes are common used although they might not be officially assigned. I would not remove these from the list. This patch also relates to bug #439710 for better support of user-defined mime-types. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:54 Message: Logged In: YES user_id=6380 Still waiting for feedback... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:42 Message: Logged In: YES user_id=21627 I believe some of these types are not "official", in the sense that they are supported by an RFC; types that are not defined in an RFC MUST use the x- prefix. E.g. in what RFC is "text/xsl" or "text/xul" defined? IOW, only types listed in http://www.isi.edu/in-notes/iana/assignments/media-types/ should be supported without x-prefix. Could you please review the entire list of known types with this respect, and update the patch accordingly? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 From noreply@sourceforge.net Fri Aug 10 06:01:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 22:01:42 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Tim Peters (tim_one) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Fri Aug 10 06:29:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 22:29:20 -0700 Subject: [Patches] [ python-Patches-449637 ] Remove NT special case in asycnore Message-ID: Patches item #449637, was opened at 2001-08-09 15:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Jeremy Hylton (jhylton) Summary: Remove NT special case in asycnore Initial Comment: asyncore uses socket error codes like EWOULDBLOCK and EALREADY. On Unix, it gets the values from errno. On NT, it has hard-coded constants. The constants match the values I see in errno on Win2k. Therefore, I assume that errno should be used on both platforms. I'm not sure if older versions of Windows are different in this repsect. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:29 Message: Logged In: YES user_id=31435 Back to Jeremy. Winsock doesn't use errno, and these specific hard-coded values are documented by MS as the (a very few of many more possible) return codes from the Winsock-appropriate WSAGetLastError() API call. I have no idea whether errnomodule.c translates them correctly in all cases, despite that it appeared to for you on your Win2K box. Why are you mucking with this? If you really care, ask Sam Rushing why he did it this way -- I can't bless any change here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 From noreply@sourceforge.net Fri Aug 10 07:22:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 23:22:10 -0700 Subject: [Patches] [ python-Patches-438790 ] additional mappings for mimetypes.py Message-ID: Patches item #438790, was opened at 2001-07-05 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: additional mappings for mimetypes.py Initial Comment: added some additional mapping for mimetypes.py. Andreas ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-09 23:22 Message: Logged In: YES user_id=21627 Just that Microsoft uses them should not cause us to violate internet standards. RFC 2045 specifies that the syntax of a subtype is subtype := extension-token / iana-token iana-token := x-token := Since text/xsl and text/xul are not registered as specified in RFC 2048, they are not valid types. So our choice is to either follow Microsoft, or follow the Internet Standards. If the inclusion of text/xsl in the patch was intentional (rather than a mistake), I recommend to reject this patch. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-08-09 18:22 Message: Logged In: YES user_id=11084 the mimetypes for .xsl and xul are also in common usage. Andreas ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-09 14:10 Message: Logged In: YES user_id=21627 I wasn't complaining about the x- types (application/x-javascript); they are fine. I was complaining about using unregistered types without an x- prefix, specifically + '.xsl': 'text/xsl', + '.xul': 'text/xul' These are not valid MIME types, unless I'm missing something. More generally, I was requesting that the IANA registry is analysed and this patch is brought in sync with it. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-08-09 11:14 Message: Logged In: YES user_id=11084 The x-* mimetypes are common used although they might not be officially assigned. I would not remove these from the list. This patch also relates to bug #439710 for better support of user-defined mime-types. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:54 Message: Logged In: YES user_id=6380 Still waiting for feedback... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:42 Message: Logged In: YES user_id=21627 I believe some of these types are not "official", in the sense that they are supported by an RFC; types that are not defined in an RFC MUST use the x- prefix. E.g. in what RFC is "text/xsl" or "text/xul" defined? IOW, only types listed in http://www.isi.edu/in-notes/iana/assignments/media-types/ should be supported without x-prefix. Could you please review the entire list of known types with this respect, and update the patch accordingly? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 From noreply@sourceforge.net Fri Aug 10 09:21:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 01:21:43 -0700 Subject: [Patches] [ python-Patches-428326 ] Timer class for threading Message-ID: Patches item #428326, was opened at 2001-05-29 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: Timer class for threading Initial Comment: The Timer class allows you to schedule an action to happen at some time in the future, using a thread. For example: def f(): print "30 seconds have passed" t = Timer(30.0, f) t.start() # after 30 seconds f will be called try: # .... other stuff except SystemExit: t.cancel() # cancel the timer since we are shutting down It allows passing arguments and keyword arguments to the function that is called. It also allows *cancelling* the timer. That is, if the timer is still waiting, we can tell it to stop its operation. Why should this be in the standard library? 1. Timers are a standard, useful programming idiom. 2. It can be used as an example of how to: a. create subclasses of threading.Thread b. make threads that can be "stopped" If this patch is approved I will then write documentation. I'm not sure how to go about writing tests for it. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:21 Message: Logged In: YES user_id=21627 A quick poll among colleagues shows that shoot-once timers are far more common than repeated intervall timers. You also can quite easily implement the intervall timer on top of a shoot-once timer, by restarting it in the timeout handler (although care is needed if you need exact intervalls: between last scheduled time-out and the handler invocation, time may pass, so the restart may need to be smaller than the intervall). In short, I think the API as you provide it is excellent; if people find it useful and require more, they will provide patches. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 14:45 Message: Logged In: YES user_id=6380 Good! I don't think there's a standard definition of timers -- I've seen both. A more general timer that can go off N times, defaulting to once, sounds like a nice API. Hm, I can actually only think of two usage scenarios: either you want it to go off once, or you want it to repeat until you cancel it. Think about it. There's also the msg from Aahz in the python-dev list where he claims he doesn't like something about this without saying what. I hope he clarifies that in this SF tracker item. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-08-09 14:23 Message: Logged In: YES user_id=32065 1) license can be python's and copyright PSF's 2) I will write docs and tests 3) not sure when, maybe this weekend One question - timers actually seem to be a task that happens repeatedly every X seconds (e.g. in wxWindows). Should I add that functionality (do a task every X seconds, N times, N is either >= 1 or infinite) or just rename the class? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 13:53 Message: Logged In: YES user_id=6380 I like it too. But I don't want itamar's license anywhere in the distribution -- too wordy. I agree that the PSF should clear up the licensing situation; we're working on that but it's slow going (nobody likes this work :-( ). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:32 Message: Logged In: YES user_id=21627 I'm in favour of approving this patch, as an extension to the threading module. Are you willing to draft a patch to the documentation (libthreading.tex) as well? Ideally, there would also be a set of regression tests in a test_threading file; it would be acceptable if this only tests your feature for the moment. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 09:40 Message: Logged In: YES user_id=32065 There was a licensing discussion on python-dev which no one bothered to CC me on :). Yes, this can be relicensed under the PSF license. I suggest someone write up some sort of guidelines for submitted patches and improvement explain the whole licensing and copyright issues. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 02:16 Message: Logged In: YES user_id=32065 OK, I'm un-withdrawing this patch. Just had to get things straight with our lawyer. The patch is released under the following license (the X11 license with 4 extra paragraphs of disclaimers :): http://www.zoteca.com/opensource/LICENSE.txt ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-29 09:45 Message: Logged In: YES user_id=32065 I'm withdrawing this patch for a short period of time for non-technical reasons, hopefully I can put it back soon. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 From noreply@sourceforge.net Fri Aug 10 09:23:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 01:23:41 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: distutils Group: None Status: Open Resolution: None >Priority: 9 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From alice@homegiant.com.tw Fri Aug 10 09:46:51 2001 From: alice@homegiant.com.tw (Alice Lin (Home Giant)) Date: 10 Aug 2001 16:46:51 +0800 Subject: [Patches] Furniture Hardware Message-ID: Business Opportunity for Cabinet & Furniture Hardware

To: Purchasing Manager / Importing Dept. Manager

*** In case you do not have any need for Furniture Hardware, or if you are not involved in a related business and/or look for a purchasing agent; please disregard this e-mail.  

To remove your email address from our database, please click the link below:
mail to: alice@homegiant.d2g.com?subject=REMOVE 
Thank you and sorry for any inconvenience ! *** 

¡@

Hello,

We are pleased to have this opportunity to briefly introduce ourselves.

Home Giant was established in 1987, specialized in manufacturing of  Furniture Hardware. 
We produce:

   Hinges
   Pulls
   Knobs
   Metal Brackets
   Brackets
   Adorning Brass
   Casters
   Home hardware

If you do not see it listed here, or for more detailed product information, please feel free to visit our web site at http://www.homegiant.com.tw or contact us directly.   

We will be pleased to furnish any information you require.  We will work with you to meet your needs (OEM/ODM projects welcome). 

Meanwhile, if you are looking for the purchasing agent, Home Giant will be happy to serve you. To provide our customers the most competitive prices and best services are our missions.

You will be satisfied with the high quality of our products and service. Give us a chance to prove that Home Giant will be your best choice of Furniture Hardware and/or purchasing agent.

Contact Home Giant to make the highest profit and obtain the best service & support.  

Looking forward to hearing from you very soon.

Sincerely yours,

Alice Lin
Home Giant Enterprise Co., Ltd.
http://www.homegiant.com.tw   

P.S. If you are not in purchasing/importing,  please forward our email to your Purchasing Manager/Importing Dept. Manager or anyone who may be interested in our products and/or service.  Thank you very much!

From noreply@sourceforge.net Fri Aug 10 10:52:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 02:52:54 -0700 Subject: [Patches] [ python-Patches-449757 ] digestsize variable for the md5 module Message-ID: Patches item #449757, was opened at 2001-08-10 02:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449757&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Sjögren (msjogren) Assigned to: Nobody/Anonymous (nobody) Summary: digestsize variable for the md5 module Initial Comment: The sha module has a digestsize constant (which is 20) which makes it easy to know how large space to use (e.g. in a database), while the md5 module doesn't. Yes I know that it IS 16, but ideally, the two modules would have the same interface and you could do tricks like this: insize = globals()[digestname].digestsize So, I included a patch to md5module.c that adds a digestsize constant both to the md5 objects and to the module dictionary, as in the sha module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449757&group_id=5470 From noreply@sourceforge.net Fri Aug 10 14:27:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 06:27:33 -0700 Subject: [Patches] [ python-Patches-449757 ] digestsize variable for the md5 module Message-ID: Patches item #449757, was opened at 2001-08-10 02:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449757&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Martin Sjögren (msjogren) Assigned to: Nobody/Anonymous (nobody) Summary: digestsize variable for the md5 module Initial Comment: The sha module has a digestsize constant (which is 20) which makes it easy to know how large space to use (e.g. in a database), while the md5 module doesn't. Yes I know that it IS 16, but ideally, the two modules would have the same interface and you could do tricks like this: insize = globals()[digestname].digestsize So, I included a patch to md5module.c that adds a digestsize constant both to the md5 objects and to the module dictionary, as in the sha module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:27 Message: Logged In: YES user_id=6380 Sorry, I fail to understand why knowing the return size in advance is useful. Python is a dynamic language -- why would you have to allocate a fixed-size buffer? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449757&group_id=5470 From noreply@sourceforge.net Fri Aug 10 14:34:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 06:34:18 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 9 Submitted By: Paul Moore (pmoore) >Assigned to: Greg Ward (gward) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Fri Aug 10 14:51:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 06:51:09 -0700 Subject: [Patches] [ python-Patches-428326 ] Timer class for threading Message-ID: Patches item #428326, was opened at 2001-05-29 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: Timer class for threading Initial Comment: The Timer class allows you to schedule an action to happen at some time in the future, using a thread. For example: def f(): print "30 seconds have passed" t = Timer(30.0, f) t.start() # after 30 seconds f will be called try: # .... other stuff except SystemExit: t.cancel() # cancel the timer since we are shutting down It allows passing arguments and keyword arguments to the function that is called. It also allows *cancelling* the timer. That is, if the timer is still waiting, we can tell it to stop its operation. Why should this be in the standard library? 1. Timers are a standard, useful programming idiom. 2. It can be used as an example of how to: a. create subclasses of threading.Thread b. make threads that can be "stopped" If this patch is approved I will then write documentation. I'm not sure how to go about writing tests for it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:51 Message: Logged In: YES user_id=6380 OK. Let's do a one-short timer only. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:21 Message: Logged In: YES user_id=21627 A quick poll among colleagues shows that shoot-once timers are far more common than repeated intervall timers. You also can quite easily implement the intervall timer on top of a shoot-once timer, by restarting it in the timeout handler (although care is needed if you need exact intervalls: between last scheduled time-out and the handler invocation, time may pass, so the restart may need to be smaller than the intervall). In short, I think the API as you provide it is excellent; if people find it useful and require more, they will provide patches. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 14:45 Message: Logged In: YES user_id=6380 Good! I don't think there's a standard definition of timers -- I've seen both. A more general timer that can go off N times, defaulting to once, sounds like a nice API. Hm, I can actually only think of two usage scenarios: either you want it to go off once, or you want it to repeat until you cancel it. Think about it. There's also the msg from Aahz in the python-dev list where he claims he doesn't like something about this without saying what. I hope he clarifies that in this SF tracker item. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-08-09 14:23 Message: Logged In: YES user_id=32065 1) license can be python's and copyright PSF's 2) I will write docs and tests 3) not sure when, maybe this weekend One question - timers actually seem to be a task that happens repeatedly every X seconds (e.g. in wxWindows). Should I add that functionality (do a task every X seconds, N times, N is either >= 1 or infinite) or just rename the class? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 13:53 Message: Logged In: YES user_id=6380 I like it too. But I don't want itamar's license anywhere in the distribution -- too wordy. I agree that the PSF should clear up the licensing situation; we're working on that but it's slow going (nobody likes this work :-( ). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:32 Message: Logged In: YES user_id=21627 I'm in favour of approving this patch, as an extension to the threading module. Are you willing to draft a patch to the documentation (libthreading.tex) as well? Ideally, there would also be a set of regression tests in a test_threading file; it would be acceptable if this only tests your feature for the moment. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 09:40 Message: Logged In: YES user_id=32065 There was a licensing discussion on python-dev which no one bothered to CC me on :). Yes, this can be relicensed under the PSF license. I suggest someone write up some sort of guidelines for submitted patches and improvement explain the whole licensing and copyright issues. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 02:16 Message: Logged In: YES user_id=32065 OK, I'm un-withdrawing this patch. Just had to get things straight with our lawyer. The patch is released under the following license (the X11 license with 4 extra paragraphs of disclaimers :): http://www.zoteca.com/opensource/LICENSE.txt ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-29 09:45 Message: Logged In: YES user_id=32065 I'm withdrawing this patch for a short period of time for non-technical reasons, hopefully I can put it back soon. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 From noreply@sourceforge.net Fri Aug 10 15:07:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 07:07:38 -0700 Subject: [Patches] [ python-Patches-449637 ] Remove NT special case in asycnore Message-ID: Patches item #449637, was opened at 2001-08-09 15:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 Category: library Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: Remove NT special case in asycnore Initial Comment: asyncore uses socket error codes like EWOULDBLOCK and EALREADY. On Unix, it gets the values from errno. On NT, it has hard-coded constants. The constants match the values I see in errno on Win2k. Therefore, I assume that errno should be used on both platforms. I'm not sure if older versions of Windows are different in this repsect. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 07:07 Message: Logged In: YES user_id=6380 I'm with Jeremy. The errno module on Windows exports values for the names used in asyncore match the values that asyncore hardcodes. Moreover, errnomodule.c #includes , which defines the values for these errors. The exception made in asyncore looks like it predates the patch (rev 2.5 by MAL) that exported the correct Windows errno values. Jeremy, go ahead and check it in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:29 Message: Logged In: YES user_id=31435 Back to Jeremy. Winsock doesn't use errno, and these specific hard-coded values are documented by MS as the (a very few of many more possible) return codes from the Winsock-appropriate WSAGetLastError() API call. I have no idea whether errnomodule.c translates them correctly in all cases, despite that it appeared to for you on your Win2K box. Why are you mucking with this? If you really care, ask Sam Rushing why he did it this way -- I can't bless any change here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 From noreply@sourceforge.net Fri Aug 10 15:59:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 07:59:04 -0700 Subject: [Patches] [ python-Patches-449815 ] Set filesystemencoding based on CODESET Message-ID: Patches item #449815, was opened at 2001-08-10 07:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449815&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Set filesystemencoding based on CODESET Initial Comment: This patch sets the Py_FileSystemDefaultEncoding in each setlocale call if nl_langinfo(CODESET) is available and returns a well-known codec name. This is closest to the windows approach, which uses the "mbcs" encoding. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449815&group_id=5470 From noreply@sourceforge.net Fri Aug 10 16:27:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 08:27:56 -0700 Subject: [Patches] [ python-Patches-449757 ] digestsize variable for the md5 module Message-ID: Patches item #449757, was opened at 2001-08-10 02:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449757&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Martin Sjögren (msjogren) Assigned to: Nobody/Anonymous (nobody) Summary: digestsize variable for the md5 module Initial Comment: The sha module has a digestsize constant (which is 20) which makes it easy to know how large space to use (e.g. in a database), while the md5 module doesn't. Yes I know that it IS 16, but ideally, the two modules would have the same interface and you could do tricks like this: insize = globals()[digestname].digestsize So, I included a patch to md5module.c that adds a digestsize constant both to the md5 objects and to the module dictionary, as in the sha module. ---------------------------------------------------------------------- >Comment By: Martin Sjögren (msjogren) Date: 2001-08-10 08:27 Message: Logged In: YES user_id=80762 Yes, Python is a dynamic language. I think you missed my 'e.g. in a database'. In SQL you'd want create a column "digest CHAR(nn)" and it would be nice to have the flexibility of which digest algorithm to use. It is also nice to know when you send a digest over a socket. I'm not saying that this constant is vitally important to my health! I'm saying that the sha module has it, and it would be nice if the md5 module had it too! I'm quite aware that the size of the digests are well-known, but instead of having to do digestsizes = { 'md5': 16, 'sha': 20 } myself, I don't see why Python can't provide those constants. They are after all properties of the digest algorithms! Example: I get a message on a socket. All I know is that the characters up to the first '\0' is the name of the digest function used. I would like to do this: import md5, sha digests = { 'md5': md5, 'sha': sha } # using globals() is ugly digest = sock.recv(digests[mdalg].digestsize) I really don't see your problem with adding this constant. With your argument you could as well remove the constant from the sha module, but that would break backwards compatability, so why not just add this constant and they'd have more similar APIs? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:27 Message: Logged In: YES user_id=6380 Sorry, I fail to understand why knowing the return size in advance is useful. Python is a dynamic language -- why would you have to allocate a fixed-size buffer? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449757&group_id=5470 From noreply@sourceforge.net Fri Aug 10 16:41:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 08:41:11 -0700 Subject: [Patches] [ python-Patches-449757 ] digestsize variable for the md5 module Message-ID: Patches item #449757, was opened at 2001-08-10 02:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449757&group_id=5470 Category: None Group: None Status: Open >Resolution: Rejected Priority: 3 Submitted By: Martin Sjögren (msjogren) Assigned to: Nobody/Anonymous (nobody) Summary: digestsize variable for the md5 module Initial Comment: The sha module has a digestsize constant (which is 20) which makes it easy to know how large space to use (e.g. in a database), while the md5 module doesn't. Yes I know that it IS 16, but ideally, the two modules would have the same interface and you could do tricks like this: insize = globals()[digestname].digestsize So, I included a patch to md5module.c that adds a digestsize constant both to the md5 objects and to the module dictionary, as in the sha module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 08:41 Message: Logged In: YES user_id=6380 I'm for leaving well enough alone, and against code bloat. I would not have added those constants to sha, but I didn't write it. Your examples don't convince me -- they don't seem very robust coding practices anyway. Also, how often do we grow new digest algorithms? ---------------------------------------------------------------------- Comment By: Martin Sjögren (msjogren) Date: 2001-08-10 08:27 Message: Logged In: YES user_id=80762 Yes, Python is a dynamic language. I think you missed my 'e.g. in a database'. In SQL you'd want create a column "digest CHAR(nn)" and it would be nice to have the flexibility of which digest algorithm to use. It is also nice to know when you send a digest over a socket. I'm not saying that this constant is vitally important to my health! I'm saying that the sha module has it, and it would be nice if the md5 module had it too! I'm quite aware that the size of the digests are well-known, but instead of having to do digestsizes = { 'md5': 16, 'sha': 20 } myself, I don't see why Python can't provide those constants. They are after all properties of the digest algorithms! Example: I get a message on a socket. All I know is that the characters up to the first '\0' is the name of the digest function used. I would like to do this: import md5, sha digests = { 'md5': md5, 'sha': sha } # using globals() is ugly digest = sock.recv(digests[mdalg].digestsize) I really don't see your problem with adding this constant. With your argument you could as well remove the constant from the sha module, but that would break backwards compatability, so why not just add this constant and they'd have more similar APIs? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:27 Message: Logged In: YES user_id=6380 Sorry, I fail to understand why knowing the return size in advance is useful. Python is a dynamic language -- why would you have to allocate a fixed-size buffer? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449757&group_id=5470 From noreply@sourceforge.net Fri Aug 10 16:44:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 08:44:03 -0700 Subject: [Patches] [ python-Patches-441091 ] Allow jython to complete test_zlib test Message-ID: Patches item #441091, was opened at 2001-07-13 09:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441091&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: A.M. Kuchling (akuchling) Summary: Allow jython to complete test_zlib test Initial Comment: The more advanced flush options are not availabe in java. With the patch, test_zlib will only use the advanced flush options if they are defined in the zlib module. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-08-10 08:44 Message: Logged In: YES user_id=11375 The patch looks good. Finn, you don't seem to have checkin privileges to the Python source tree, so I'll check this patch in, but you should really get checkin privileges. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:57 Message: Logged In: YES user_id=6380 Andrew, can you review this? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441091&group_id=5470 From noreply@sourceforge.net Fri Aug 10 16:49:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 08:49:28 -0700 Subject: [Patches] [ python-Patches-441091 ] Allow jython to complete test_zlib test Message-ID: Patches item #441091, was opened at 2001-07-13 09:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441091&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: A.M. Kuchling (akuchling) Summary: Allow jython to complete test_zlib test Initial Comment: The more advanced flush options are not availabe in java. With the patch, test_zlib will only use the advanced flush options if they are defined in the zlib module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 08:49 Message: Logged In: YES user_id=6380 Good point, Andrew. I've added Finn to the developers. Anyone else who deserves developer privileges? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-10 08:44 Message: Logged In: YES user_id=11375 The patch looks good. Finn, you don't seem to have checkin privileges to the Python source tree, so I'll check this patch in, but you should really get checkin privileges. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:57 Message: Logged In: YES user_id=6380 Andrew, can you review this? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441091&group_id=5470 From noreply@sourceforge.net Fri Aug 10 16:50:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 08:50:42 -0700 Subject: [Patches] [ python-Patches-441091 ] Allow jython to complete test_zlib test Message-ID: Patches item #441091, was opened at 2001-07-13 09:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441091&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: A.M. Kuchling (akuchling) Summary: Allow jython to complete test_zlib test Initial Comment: The more advanced flush options are not availabe in java. With the patch, test_zlib will only use the advanced flush options if they are defined in the zlib module. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-08-10 08:50 Message: Logged In: YES user_id=11375 Applied to rev.1.14 of test_zlib.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 08:49 Message: Logged In: YES user_id=6380 Good point, Andrew. I've added Finn to the developers. Anyone else who deserves developer privileges? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-10 08:44 Message: Logged In: YES user_id=11375 The patch looks good. Finn, you don't seem to have checkin privileges to the Python source tree, so I'll check this patch in, but you should really get checkin privileges. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:57 Message: Logged In: YES user_id=6380 Andrew, can you review this? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441091&group_id=5470 From noreply@sourceforge.net Fri Aug 10 16:56:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 08:56:53 -0700 Subject: [Patches] [ python-Patches-428320 ] rich comparisons as operator.__lt__ etc. Message-ID: Patches item #428320, was opened at 2001-05-29 07:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: rich comparisons as operator.__lt__ etc. Initial Comment: Rich Comparisons (PEP 207) introduce new special names in classes (__lt__, __le__, __eq__, etc.). They should be available in the 'operator' module just like the other special names (__add__ and the like). This patch introduce 12 new names in 'operator': lt, le, eq, ne, gt, ge, __lt__, __le__, __eq__, __ne__, __gt__, __ge__. The first 6 are provided for uniformity with the rest of the module but I am not sure whether it is a good idea to clutter a namespace with names only two letters long; for example, could names like 'eq' accidentally break existing programs using from operator import * ? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 08:56 Message: Logged In: YES user_id=3066 Checked in as Modules/operator.c revision 2.18 and Doc/lib/liboperator.tex revision 1.20. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-18 14:54 Message: Logged In: YES user_id=6380 I disagree with Fred re the long names. These are too long to be typed. Now is not the time to try and argue over whether "le" etc. are good names -- the time was when the rich comparisons PEP was under discussion. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 14:44 Message: Logged In: YES user_id=3066 Have sent an email to the submitter regarding this; awaiting response. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:53 Message: Logged In: YES user_id=3066 I'd prefer to see the names that don't have underscores be lessthan, lessthanequal, equal, notequal, greaterthan, greaterthanequal. Not sure what others think. I doubt the issue is "from operator import *" -- no one should be doing that anyway. Also, the documentation fragment uses "informations" (note the 's') instead of "information". ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2001-05-29 08:01 Message: Logged In: YES user_id=4771 Sorry, I forgot to login when I posted the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470 From noreply@sourceforge.net Fri Aug 10 18:45:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 10:45:26 -0700 Subject: [Patches] [ python-Patches-449637 ] Remove NT special case in asycnore Message-ID: Patches item #449637, was opened at 2001-08-09 15:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 Category: library Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: Remove NT special case in asycnore Initial Comment: asyncore uses socket error codes like EWOULDBLOCK and EALREADY. On Unix, it gets the values from errno. On NT, it has hard-coded constants. The constants match the values I see in errno on Win2k. Therefore, I assume that errno should be used on both platforms. I'm not sure if older versions of Windows are different in this repsect. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-10 10:45 Message: Logged In: YES user_id=31435 Are we opposed to coordinating changes with Sam? We got a fresh version from him just 6 months ago, and the more we fiddle on our own the harder it will be to do that the next time. This code may not have been maximally elegant, but it's essentially a foreign library (unless we've decided to fork our own), and it simply wasn't broken. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 07:07 Message: Logged In: YES user_id=6380 I'm with Jeremy. The errno module on Windows exports values for the names used in asyncore match the values that asyncore hardcodes. Moreover, errnomodule.c #includes , which defines the values for these errors. The exception made in asyncore looks like it predates the patch (rev 2.5 by MAL) that exported the correct Windows errno values. Jeremy, go ahead and check it in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:29 Message: Logged In: YES user_id=31435 Back to Jeremy. Winsock doesn't use errno, and these specific hard-coded values are documented by MS as the (a very few of many more possible) return codes from the Winsock-appropriate WSAGetLastError() API call. I have no idea whether errnomodule.c translates them correctly in all cases, despite that it appeared to for you on your Win2K box. Why are you mucking with this? If you really care, ask Sam Rushing why he did it this way -- I can't bless any change here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 From noreply@sourceforge.net Fri Aug 10 18:50:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 10:50:16 -0700 Subject: [Patches] [ python-Patches-449637 ] Remove NT special case in asycnore Message-ID: Patches item #449637, was opened at 2001-08-09 15:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 Category: library Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: Remove NT special case in asycnore Initial Comment: asyncore uses socket error codes like EWOULDBLOCK and EALREADY. On Unix, it gets the values from errno. On NT, it has hard-coded constants. The constants match the values I see in errno on Win2k. Therefore, I assume that errno should be used on both platforms. I'm not sure if older versions of Windows are different in this repsect. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 10:50 Message: Logged In: YES user_id=6380 I'm not opposed to coordinating with Sam -- but I thought that he had lost interest? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-10 10:45 Message: Logged In: YES user_id=31435 Are we opposed to coordinating changes with Sam? We got a fresh version from him just 6 months ago, and the more we fiddle on our own the harder it will be to do that the next time. This code may not have been maximally elegant, but it's essentially a foreign library (unless we've decided to fork our own), and it simply wasn't broken. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 07:07 Message: Logged In: YES user_id=6380 I'm with Jeremy. The errno module on Windows exports values for the names used in asyncore match the values that asyncore hardcodes. Moreover, errnomodule.c #includes , which defines the values for these errors. The exception made in asyncore looks like it predates the patch (rev 2.5 by MAL) that exported the correct Windows errno values. Jeremy, go ahead and check it in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:29 Message: Logged In: YES user_id=31435 Back to Jeremy. Winsock doesn't use errno, and these specific hard-coded values are documented by MS as the (a very few of many more possible) return codes from the Winsock-appropriate WSAGetLastError() API call. I have no idea whether errnomodule.c translates them correctly in all cases, despite that it appeared to for you on your Win2K box. Why are you mucking with this? If you really care, ask Sam Rushing why he did it this way -- I can't bless any change here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 From noreply@sourceforge.net Fri Aug 10 18:57:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 10:57:28 -0700 Subject: [Patches] [ python-Patches-449637 ] Remove NT special case in asycnore Message-ID: Patches item #449637, was opened at 2001-08-09 15:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 Category: library Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: Remove NT special case in asycnore Initial Comment: asyncore uses socket error codes like EWOULDBLOCK and EALREADY. On Unix, it gets the values from errno. On NT, it has hard-coded constants. The constants match the values I see in errno on Win2k. Therefore, I assume that errno should be used on both platforms. I'm not sure if older versions of Windows are different in this repsect. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-08-10 10:57 Message: Logged In: YES user_id=31392 I made the changes and sent a note to medusa@yahoogroups.com. We'll see if there is any interest on that list. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 10:50 Message: Logged In: YES user_id=6380 I'm not opposed to coordinating with Sam -- but I thought that he had lost interest? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-10 10:45 Message: Logged In: YES user_id=31435 Are we opposed to coordinating changes with Sam? We got a fresh version from him just 6 months ago, and the more we fiddle on our own the harder it will be to do that the next time. This code may not have been maximally elegant, but it's essentially a foreign library (unless we've decided to fork our own), and it simply wasn't broken. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 07:07 Message: Logged In: YES user_id=6380 I'm with Jeremy. The errno module on Windows exports values for the names used in asyncore match the values that asyncore hardcodes. Moreover, errnomodule.c #includes , which defines the values for these errors. The exception made in asyncore looks like it predates the patch (rev 2.5 by MAL) that exported the correct Windows errno values. Jeremy, go ahead and check it in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:29 Message: Logged In: YES user_id=31435 Back to Jeremy. Winsock doesn't use errno, and these specific hard-coded values are documented by MS as the (a very few of many more possible) return codes from the Winsock-appropriate WSAGetLastError() API call. I have no idea whether errnomodule.c translates them correctly in all cases, despite that it appeared to for you on your Win2K box. Why are you mucking with this? If you really care, ask Sam Rushing why he did it this way -- I can't bless any change here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449637&group_id=5470 From noreply@sourceforge.net Fri Aug 10 20:25:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 12:25:03 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 9 Submitted By: Paul Moore (pmoore) >Assigned to: Thomas Heller (theller) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Fri Aug 10 21:22:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 13:22:09 -0700 Subject: [Patches] [ python-Patches-429611 ] doc build on win32 with MiKTeX et al. Message-ID: Patches item #429611, was opened at 2001-06-02 08:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429611&group_id=5470 Category: documentation Group: None >Status: Pending >Resolution: Accepted Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: doc build on win32 with MiKTeX et al. Initial Comment: With this patch, everything build fine on win32 but for the following problems: - html/api/labels.pl not generated -> html/api/*.html uncorrect - lib/modindex.html not generated -> html/modindex.html uncorrect Problems worked out: - fancyhdr.sty is not in the Miktex distribution ... - Makefile content made compatible with the Windows command line (now runs fine with VC++'s nmake, or cygnus's make --win32) - misc. problems regarding the path formats - miktex 2.0's pdflatex would block on a mismatching macro level in python.sty -> fixed Hints on installing latex2html: - I had to work out some fixes in the config.pl script (2,000 lines of perl...) - make sure the paths to the ghostscript and miktex installations have no spaces!!!!!! latex2html will silently screw up its configuration process - looking at perl scripts gave me a serious trauma ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 13:22 Message: Logged In: YES user_id=3066 Added fancyhdr.sty in Doc/texinputs/. Doc/perl/l2hinit.perl no longer needs "cat" (revision 1.55), so the adjustment to support CygWin cat is no longer needed in mkhowto. Doc/tools/mkhowto revision 1.29 contains changes to be portable to Windows/CygWin, based on the attached patch. Still not closed ;-( -- I need to try to actually understand what's going on with \pdfendlink, and the README probably needs a little work. Frederic, have I missed anything else? (Sorry to take so long getting this in!) Marked "Pending" waiting for feedback. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 10:25 Message: Logged In: YES user_id=3066 I've checked in some of the required changes, but others still need to be considered. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:30 Message: Logged In: YES user_id=3066 Assigned to the doc-tsar for review. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429611&group_id=5470 From noreply@sourceforge.net Fri Aug 10 22:55:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 14:55:04 -0700 Subject: [Patches] [ python-Patches-429024 ] Deal with some unary ops at compile time Message-ID: Patches item #429024, was opened at 2001-05-31 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429024&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) Summary: Deal with some unary ops at compile time Initial Comment: This patch makes unary + and - operations with numeric literals compile to a constant reference instead of a constant reference and UNARY_POSITIVE or UNARY_NEGATIVE opcode. This could be extended to support UNARY_INVERT as well, but that would be a little more complicated. Folding unary + only affects one case in the regression test, but folding the - affects 817 places (on a Linux system with pretty much everything enabled). I don't know that this makes much difference at runtime, but certainly reduces the number of opcodes evaluated. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 14:55 Message: Logged In: YES user_id=3066 Updated the patch to include an explanatory comment. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 11:13 Message: Logged In: YES user_id=31435 Back to Jeremy. Fred's patch is fine by me, but I'd like to see a comment before the 20 lines of mallocs and frees and strcpys explaining what the *intent* of all that stuff is (it's a lot of code to stick "-" at the front of a string ). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-06-03 21:24 Message: Logged In: YES user_id=3066 Re-assigned to Tim since Jeremy's on a new assignment. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429024&group_id=5470 From noreply@sourceforge.net Fri Aug 10 23:41:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 15:41:32 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Tim Peters (tim_one) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-08-10 15:41 Message: Logged In: YES user_id=6656 Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly). No rest for the wicked: more docs and some tests still needed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Tue Aug 14 20:13:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 12:13:31 -0700 Subject: [Patches] [ python-Patches-450702 ] zlibmodule ALLOW_THREADS update Message-ID: Patches item #450702, was opened at 2001-08-13 22:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: zlibmodule ALLOW_THREADS update Initial Comment: When using e.g. the gzip module in a threaded Python embedding (PyWX, pywx.idyll.org) all other Python threads halt, because no thread interleaving is done by the time-intensive commands in zlib.so. This leads to serious lags when compressing 5 MB files... I have wrapped all of the inflate and deflate commands in Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, which fixes this problem. Note that this fix is backwards compatible to 2.1, at least, as zlibmodule.c has not changed since then. As requested, a _context_ diff from the head of the current CVS tree is attached ;). ---------------------------------------------------------------------- >Comment By: Titus Brown (titus) Date: 2001-08-14 12:13 Message: Logged In: YES user_id=23486 N.B. I've found that zlib _is_ threadsafe. I still need to determine if the way in which objects are passed around in the zlibmodule.c can potentially cause problems; it seems like it can. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 09:06 Message: Logged In: YES user_id=23486 I think there may be a 2nd problem: I have to look into some of the Python calls used to transfer data around, but it may be possible for threads with access to the compression objects to retrieve data in an indeterminate state, i.e. mid-compression. Luckily a module-wide lock should take care of both this problem AND resolve threadsafety issues with zlib! I'll look into this & fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:21 Message: Logged In: YES user_id=21627 The patch looks good, however there is a major problem with the approach taken: zlib itself might not be threadsafe. Please try to find out whether zlib indeed is thread-safe; if it isn't, I think you need to add another lock to prevent multiple Python threads from accessing zlib simultaneously. You may want to take a look at _tkinter, which has similar code to prevent multiple Python threads from accessing Tk simultaneously. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 From noreply@sourceforge.net Tue Aug 14 20:14:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 12:14:17 -0700 Subject: [Patches] [ python-Patches-443899 ] Minor fix to gzip.py module. Message-ID: Patches item #443899, was opened at 2001-07-23 12:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) >Assigned to: A.M. Kuchling (akuchling) Summary: Minor fix to gzip.py module. Initial Comment: --- from cStringIO import StringIO from gzip import GzipFile stringFile = StringIO() gzFile = GzipFile("test1", 'wb', 9, stringFile) gzFile.write('howdy there!') r = gzFile.read() --- the above code fragment gave a nonintuitive error response (attribute missing). Now, an exception is raised stating that the file is not opened for reading or writing. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 From noreply@sourceforge.net Tue Aug 14 20:15:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 12:15:19 -0700 Subject: [Patches] [ python-Patches-443899 ] Minor fix to gzip.py module. Message-ID: Patches item #443899, was opened at 2001-07-23 12:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) >Assigned to: Jeremy Hylton (jhylton) Summary: Minor fix to gzip.py module. Initial Comment: --- from cStringIO import StringIO from gzip import GzipFile stringFile = StringIO() gzFile = GzipFile("test1", 'wb', 9, stringFile) gzFile.write('howdy there!') r = gzFile.read() --- the above code fragment gave a nonintuitive error response (attribute missing). Now, an exception is raised stating that the file is not opened for reading or writing. ---------------------------------------------------------------------- >Comment By: Titus Brown (titus) Date: 2001-08-14 12:15 Message: Logged In: YES user_id=23486 (sorry -- misunderstanding of how the changelog view works) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 From noreply@sourceforge.net Tue Aug 14 22:27:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 14:27:51 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Tim Peters (tim_one) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-08-14 14:27 Message: Logged In: YES user_id=6656 I think this latest version actually compiles (ahem). As far as I'm concerned, the coding is now done. Also attach a first cut at some doc updates. Fred will definitely need to fiddle these to get them to compile (there's no latex here on the starship). I should probably do some test cases.. later. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-10 15:41 Message: Logged In: YES user_id=6656 Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly). No rest for the wicked: more docs and some tests still needed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Tue Aug 14 23:05:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 15:05:50 -0700 Subject: [Patches] [ python-Patches-450979 ] Add module docstring - imputil Message-ID: Patches item #450979, was opened at 2001-08-14 15:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450979&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Add module docstring - imputil Initial Comment: Add module docstring - imputil ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450979&group_id=5470 From noreply@sourceforge.net Tue Aug 14 23:06:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 15:06:42 -0700 Subject: [Patches] [ python-Patches-450980 ] Add module docstring - sre*, re Message-ID: Patches item #450980, was opened at 2001-08-14 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450980&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Add module docstring - sre*, re Initial Comment: Add module docstring - sre*, re ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450980&group_id=5470 From noreply@sourceforge.net Tue Aug 14 23:07:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 15:07:30 -0700 Subject: [Patches] [ python-Patches-450981 ] Add module docstring - xmlrpc Message-ID: Patches item #450981, was opened at 2001-08-14 15:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Add module docstring - xmlrpc Initial Comment: Add module docstring - xmlrpc ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450981&group_id=5470 From noreply@sourceforge.net Tue Aug 14 23:26:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 15:26:38 -0700 Subject: [Patches] [ python-Patches-448305 ] Additions to the C API Message-ID: Patches item #448305, was opened at 2001-08-05 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) >Assigned to: Barry Warsaw (bwarsaw) Summary: Additions to the C API Initial Comment: I'm not sure a PEP is required for this patch, but these functions are pre-requisiste for two other PEP in the pipe... I have not always had easy access to news posting, so I'll be the happier this can go through without all the PEP overhead, otherwise, I'll try to follow up the PEP. I'm submitting this as a PEP in the same time, to the Director of PEP Affairs, as indicated in the PEP meta PEP 000 (barry), with a reference to this patch (file attached). Frederic Giacometti --------------------------- PEP XXX: Additions to the C API fred@arakne.com (Frederic Giacometti) Abstract This PEP defines a couple of C functions. The first two functions are for raising exceptions with multiple arguments; the third one is for calling a method when an arg tuple is given; and the other ones programmatically define sys.path and the optimization level in embedded python context, before initialization of the global Python engine. Copyright: This document is published under the Open Publication License. Specification: PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) Raise the exception created by applying args to exctype. This is equivalent to the Python expression raise apply( exctype, args). Always set the error state and return NULL. PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) This function is similar to PyErr_RaiseArgs(), but defines the arguments using the same convention as Py_BuildValue(). Always set the error state and return NULL. PyObject* PyObject_CallMethodArgs( PyObject* o, char const* method, PyObject* args) Call the method named 'method' with arguments given by the tuple args, using for args the same convention as PyObject_CallObject(). This is the equivalent of the Python expression o.method( args). Note that special method names, such as __add__(), __getitem__(), and so on are not supported. The specific abstract-object routines for these must be used. void Py_SetPythonPath( char const* path) This function should be called before Py_Initialize() is called for the first time, if it is called at all. It defines the PYTHONPATH value to be used by the interpreter. Calling Py_SetPythonPath() will override the PYTHONPATH value from the environment. The argument should be NULL, or point to a zero-terminated character string which will not change for the duration of the program's execution. char const* Py_GetPythonPath() If Py_SetPythonPath() was never called, getenv( "PYTHONPATH") is returned, otherwise the argument of Py_SetPythonPath() is returned. The returned string points into static storage. void Py_SetOptimizeLevel( int level) This function should be called before Py_Initialize() is called for the first time. Legal optimization levels are listed below. \begin{tableii}{c|l}{character}{Character}{Meaning} \lineii{0}{No optimization (use \code{.pyc} files by default)} \lineii{1}{Same as \code{python -O}} \lineii{2}{Same as \code{python -OO}} \end{tableii} int Py_GetOptimizeLevel() Return the interpreter optimization level. Reference Implementation: See attached patch (concatenation of 2 patch files). ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 15:36 Message: Logged In: YES user_id=93657 A) Direct code replacement. Here is a non-exhaustive list of occurences: pythonrun.c-2.1:1242 w = Py_BuildValue("(sO)", msg, v); Py_XDECREF(v); PyErr_SetObject(errtype, w); Py_XDECREF(w); --> PyErr_Raise( errtype, "sO", msg, v); Py_XDECREF( v); errors.c:towards 303 and 350: if (filename != NULL) v = Py_BuildValue("(iss)", err, s, filename); else v = Py_BuildValue("(is)", err, s); if (v != NULL) { PyErr_SetObject(PyExc_WindowsError, v); Py_DECREF(v); --> if (filename) PyErr_Raise( Pyexc_WindowsError, "iss", err, s, filename) else PyErr_Raise( ..., "is", err, s); compile.c: 421 w = Py_BuildValue("(OO)", v, t); if (w == NULL) goto exit; PyErr_SetObject(exc, w); --> PyErr_Raise( exc, "OO", v, t) Modules/socketmodules.c:361 v = Py_BuildValue("(is)", myerrorcode, outbuf); if (v != NULL) { PyErr_SetObject(PySocket_Error, v); Py_DECREF(v); } return NULL; --> return PyErr_Raise( PySocketError, "is", myerrorcode, outbuf); posixmodule.c:441 v = Py_BuildValue("(is)", code, text); if (v != NULL) { PyErr_SetObject(PyExc_OSError, v); Py_DECREF(v); } return NULL; /* Signal to Python that an Exception is Pending */ --> return PyErr_Raise( PyExc_OSError, "is", code, text); ..... B) Other use of PyErr_Raise* in the current code base: ---------------------------------------------- As of today, there are 3 functions for raising a new exception: - PyErr_SetString (1118 occurences) - PyErr_Format (158 occurences) - PyErr_SetObject (48 occurences) PyErr_Raise( exctype, "O", obj) would replace PyErr_SetObject( exctype, obj) PyErr_Raise( exctype, "s", msg) would replace PyErr_SetString( exctype, msg) PyErr_SetObject and PyErr_SetString could then both be deprecated, in cases the arg is not already an instance of the exception... Here is some explaination: Historically, Python was first working with string exceptions, only. Structured object-oriented exceptions were introduced only towards the 1.5 releases, I think (very approximately - I've only used python 1.5.1 or later...). It is not also also how the current API works with exception whose __init__ require more than two args, and process them. If you want to raise an exception with an __init__ that has to or more args, there is presently no clear way of doing it; this is where i created the PyErr_Raise* functions. There is also the case where one would define an exception which does not accept a string object as __init__ argument... PyErr_SetString would create problem there too. Furthermore, the exact semantics and workings of PyErr_Object are not clear, with regard to the type of the object passed (this is fine when the object is already an instance of the exception class, but when it is not an instance of the exception class, huum). Use of PyErr_Raise would clarify this... ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 14:37 Message: Logged In: YES user_id=93657 1) Patch for PyErr_Raise: I manually edited the patch file, since I had the ImportNotFound changes with it. The entire patch is in cdiff file attached to http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448488&group_id=5470 Meanwhile, I'm pasting below the missing section. 2) I'm going to make a quick search on the existing base for replacement opportunities. 3) CallMethodArgs vs. CallMethodArgs with keywords: The main reason is that the implementation relies on the exsiting PyObject_CallObject function, with does not take keyword args... However, your remark is relevant, and two other functions would be needed to complete the call interface: PyObject_CallObjectWithKW and PyObject_CallMethodArgsWithKW... I'd say that use of keyword arg from the C API is unusual; since I've never needed them, I haven't implemented them... Index: Python/errors.c =================================================================== RCS file: /cvs/python/Python/Python/errors.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 errors.c *** Python/errors.c 2001/05/27 15:36:36 1.1.1.1 --- Python/errors.c 2001/06/05 16:11:16 *************** *** 514,519 **** --- 514,571 ---- } + PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) + { + PyObject* exception; + exception = PyObject_CallObject( exctype, args); + if (! exception) return NULL; + PyErr_SetObject( exctype, exception); + return NULL; + } + + PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) + { + PyObject* args = NULL, *result = NULL; + va_list va; + + va_start( va, format); + args = format ? Py_VaBuildValue( (char*)format, va) : PyTuple_New(0); + va_end(va); + + if (! args) goto Finally; + if (! PyTuple_Check( args)) { + PyObject* newargs; + newargs = PyTuple_New( 1); + if (! newargs) goto Finally; + PyTuple_SET_ITEM( newargs, 0, args); + args = newargs; + } + + result = PyErr_RaiseArgs( exctype, args); + Finally: + Py_XDECREF(args); + return result; + } + PyObject * PyErr_NewException(char *name, PyObject *base, PyObject *dict) { ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:16 Message: Logged In: YES user_id=21627 It seems that your patch is somewhat confused: It contains fragments of the SetPythonPath code, but fails to include the implementation of PyErr_Raise[Args]. I think the patch should also identify the places in the code that could make use of the offered simplifications (and change them to the new API), to get an impression of how general this API is. I'm +1 on the _Raise functions and -0 on the CallMethodArgs (why does it not support keyword arguments?). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 From noreply@sourceforge.net Tue Aug 14 23:32:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 15:32:29 -0700 Subject: [Patches] [ python-Patches-448305 ] Additions to the C API Message-ID: Patches item #448305, was opened at 2001-08-05 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) >Assigned to: Guido van Rossum (gvanrossum) Summary: Additions to the C API Initial Comment: I'm not sure a PEP is required for this patch, but these functions are pre-requisiste for two other PEP in the pipe... I have not always had easy access to news posting, so I'll be the happier this can go through without all the PEP overhead, otherwise, I'll try to follow up the PEP. I'm submitting this as a PEP in the same time, to the Director of PEP Affairs, as indicated in the PEP meta PEP 000 (barry), with a reference to this patch (file attached). Frederic Giacometti --------------------------- PEP XXX: Additions to the C API fred@arakne.com (Frederic Giacometti) Abstract This PEP defines a couple of C functions. The first two functions are for raising exceptions with multiple arguments; the third one is for calling a method when an arg tuple is given; and the other ones programmatically define sys.path and the optimization level in embedded python context, before initialization of the global Python engine. Copyright: This document is published under the Open Publication License. Specification: PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) Raise the exception created by applying args to exctype. This is equivalent to the Python expression raise apply( exctype, args). Always set the error state and return NULL. PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) This function is similar to PyErr_RaiseArgs(), but defines the arguments using the same convention as Py_BuildValue(). Always set the error state and return NULL. PyObject* PyObject_CallMethodArgs( PyObject* o, char const* method, PyObject* args) Call the method named 'method' with arguments given by the tuple args, using for args the same convention as PyObject_CallObject(). This is the equivalent of the Python expression o.method( args). Note that special method names, such as __add__(), __getitem__(), and so on are not supported. The specific abstract-object routines for these must be used. void Py_SetPythonPath( char const* path) This function should be called before Py_Initialize() is called for the first time, if it is called at all. It defines the PYTHONPATH value to be used by the interpreter. Calling Py_SetPythonPath() will override the PYTHONPATH value from the environment. The argument should be NULL, or point to a zero-terminated character string which will not change for the duration of the program's execution. char const* Py_GetPythonPath() If Py_SetPythonPath() was never called, getenv( "PYTHONPATH") is returned, otherwise the argument of Py_SetPythonPath() is returned. The returned string points into static storage. void Py_SetOptimizeLevel( int level) This function should be called before Py_Initialize() is called for the first time. Legal optimization levels are listed below. \begin{tableii}{c|l}{character}{Character}{Meaning} \lineii{0}{No optimization (use \code{.pyc} files by default)} \lineii{1}{Same as \code{python -O}} \lineii{2}{Same as \code{python -OO}} \end{tableii} int Py_GetOptimizeLevel() Return the interpreter optimization level. Reference Implementation: See attached patch (concatenation of 2 patch files). ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-14 15:32 Message: Logged In: YES user_id=12800 It's not clear to me that adding a couple of C API functions requires a PEP. I'm assigning to Guido for BDFL pronouncement. Guido should probably also decide on the patches themselves. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 15:36 Message: Logged In: YES user_id=93657 A) Direct code replacement. Here is a non-exhaustive list of occurences: pythonrun.c-2.1:1242 w = Py_BuildValue("(sO)", msg, v); Py_XDECREF(v); PyErr_SetObject(errtype, w); Py_XDECREF(w); --> PyErr_Raise( errtype, "sO", msg, v); Py_XDECREF( v); errors.c:towards 303 and 350: if (filename != NULL) v = Py_BuildValue("(iss)", err, s, filename); else v = Py_BuildValue("(is)", err, s); if (v != NULL) { PyErr_SetObject(PyExc_WindowsError, v); Py_DECREF(v); --> if (filename) PyErr_Raise( Pyexc_WindowsError, "iss", err, s, filename) else PyErr_Raise( ..., "is", err, s); compile.c: 421 w = Py_BuildValue("(OO)", v, t); if (w == NULL) goto exit; PyErr_SetObject(exc, w); --> PyErr_Raise( exc, "OO", v, t) Modules/socketmodules.c:361 v = Py_BuildValue("(is)", myerrorcode, outbuf); if (v != NULL) { PyErr_SetObject(PySocket_Error, v); Py_DECREF(v); } return NULL; --> return PyErr_Raise( PySocketError, "is", myerrorcode, outbuf); posixmodule.c:441 v = Py_BuildValue("(is)", code, text); if (v != NULL) { PyErr_SetObject(PyExc_OSError, v); Py_DECREF(v); } return NULL; /* Signal to Python that an Exception is Pending */ --> return PyErr_Raise( PyExc_OSError, "is", code, text); ..... B) Other use of PyErr_Raise* in the current code base: ---------------------------------------------- As of today, there are 3 functions for raising a new exception: - PyErr_SetString (1118 occurences) - PyErr_Format (158 occurences) - PyErr_SetObject (48 occurences) PyErr_Raise( exctype, "O", obj) would replace PyErr_SetObject( exctype, obj) PyErr_Raise( exctype, "s", msg) would replace PyErr_SetString( exctype, msg) PyErr_SetObject and PyErr_SetString could then both be deprecated, in cases the arg is not already an instance of the exception... Here is some explaination: Historically, Python was first working with string exceptions, only. Structured object-oriented exceptions were introduced only towards the 1.5 releases, I think (very approximately - I've only used python 1.5.1 or later...). It is not also also how the current API works with exception whose __init__ require more than two args, and process them. If you want to raise an exception with an __init__ that has to or more args, there is presently no clear way of doing it; this is where i created the PyErr_Raise* functions. There is also the case where one would define an exception which does not accept a string object as __init__ argument... PyErr_SetString would create problem there too. Furthermore, the exact semantics and workings of PyErr_Object are not clear, with regard to the type of the object passed (this is fine when the object is already an instance of the exception class, but when it is not an instance of the exception class, huum). Use of PyErr_Raise would clarify this... ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 14:37 Message: Logged In: YES user_id=93657 1) Patch for PyErr_Raise: I manually edited the patch file, since I had the ImportNotFound changes with it. The entire patch is in cdiff file attached to http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448488&group_id=5470 Meanwhile, I'm pasting below the missing section. 2) I'm going to make a quick search on the existing base for replacement opportunities. 3) CallMethodArgs vs. CallMethodArgs with keywords: The main reason is that the implementation relies on the exsiting PyObject_CallObject function, with does not take keyword args... However, your remark is relevant, and two other functions would be needed to complete the call interface: PyObject_CallObjectWithKW and PyObject_CallMethodArgsWithKW... I'd say that use of keyword arg from the C API is unusual; since I've never needed them, I haven't implemented them... Index: Python/errors.c =================================================================== RCS file: /cvs/python/Python/Python/errors.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 errors.c *** Python/errors.c 2001/05/27 15:36:36 1.1.1.1 --- Python/errors.c 2001/06/05 16:11:16 *************** *** 514,519 **** --- 514,571 ---- } + PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) + { + PyObject* exception; + exception = PyObject_CallObject( exctype, args); + if (! exception) return NULL; + PyErr_SetObject( exctype, exception); + return NULL; + } + + PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) + { + PyObject* args = NULL, *result = NULL; + va_list va; + + va_start( va, format); + args = format ? Py_VaBuildValue( (char*)format, va) : PyTuple_New(0); + va_end(va); + + if (! args) goto Finally; + if (! PyTuple_Check( args)) { + PyObject* newargs; + newargs = PyTuple_New( 1); + if (! newargs) goto Finally; + PyTuple_SET_ITEM( newargs, 0, args); + args = newargs; + } + + result = PyErr_RaiseArgs( exctype, args); + Finally: + Py_XDECREF(args); + return result; + } + PyObject * PyErr_NewException(char *name, PyObject *base, PyObject *dict) { ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-07 22:16 Message: Logged In: YES user_id=21627 It seems that your patch is somewhat confused: It contains fragments of the SetPythonPath code, but fails to include the implementation of PyErr_Raise[Args]. I think the patch should also identify the places in the code that could make use of the offered simplifications (and change them to the new API), to get an impression of how general this API is. I'm +1 on the _Raise functions and -0 on the CallMethodArgs (why does it not support keyword arguments?). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 From noreply@sourceforge.net Wed Aug 15 01:39:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 17:39:51 -0700 Subject: [Patches] [ python-Patches-429611 ] doc build on win32 with MiKTeX et al. Message-ID: Patches item #429611, was opened at 2001-06-02 08:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429611&group_id=5470 Category: documentation Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: doc build on win32 with MiKTeX et al. Initial Comment: With this patch, everything build fine on win32 but for the following problems: - html/api/labels.pl not generated -> html/api/*.html uncorrect - lib/modindex.html not generated -> html/modindex.html uncorrect Problems worked out: - fancyhdr.sty is not in the Miktex distribution ... - Makefile content made compatible with the Windows command line (now runs fine with VC++'s nmake, or cygnus's make --win32) - misc. problems regarding the path formats - miktex 2.0's pdflatex would block on a mismatching macro level in python.sty -> fixed Hints on installing latex2html: - I had to work out some fixes in the config.pl script (2,000 lines of perl...) - make sure the paths to the ghostscript and miktex installations have no spaces!!!!!! latex2html will silently screw up its configuration process - looking at perl scripts gave me a serious trauma ---------------------------------------------------------------------- >Comment By: Frederic Giacometti (giacometti) Date: 2001-08-14 17:39 Message: Logged In: YES user_id=93657 When you say 'windows/cygwin', I don't know if you mean 'cygwin on windows', or 'cygwin' and 'windows'... So, here are some precisions: The changes in the doc makefile are first meant to make it compatible with the Win2K command line shell, and using VC++'s nmake. As a rule, I try not to mix up Win32 and Cygwin environments together (the bundling of python and some Tetex/Latex in the standard cygwin distribution does not help at all). Since MikTek is easy to install and works fine (in contrast to cygwin's tetex), I build the doc in a 'win32' environment; and to put most chances on my side: - I don't use cygwin bash for the builds - if cygwin make is used, I run it as 'make --win32'. In what I have installed to compile the docs, cygwin is only required for building some 3rd party graphic library required for installing properly latex2html (I could not work it around). Frederic Giacometti ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 13:22 Message: Logged In: YES user_id=3066 Added fancyhdr.sty in Doc/texinputs/. Doc/perl/l2hinit.perl no longer needs "cat" (revision 1.55), so the adjustment to support CygWin cat is no longer needed in mkhowto. Doc/tools/mkhowto revision 1.29 contains changes to be portable to Windows/CygWin, based on the attached patch. Still not closed ;-( -- I need to try to actually understand what's going on with \pdfendlink, and the README probably needs a little work. Frederic, have I missed anything else? (Sorry to take so long getting this in!) Marked "Pending" waiting for feedback. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 10:25 Message: Logged In: YES user_id=3066 I've checked in some of the required changes, but others still need to be considered. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:30 Message: Logged In: YES user_id=3066 Assigned to the doc-tsar for review. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429611&group_id=5470 From noreply@sourceforge.net Wed Aug 15 02:35:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 18:35:33 -0700 Subject: [Patches] [ python-Patches-450350 ] Get --with-next-framework to work again (on OSX at least) Message-ID: Patches item #450350, was opened at 2001-08-12 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450350&group_id=5470 Category: Build Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Get --with-next-framework to work again (on OSX at least) Initial Comment: These patches to Makefile.pre.in, configure.in and Modules/getpath.c make --with-next-framework work again, for build as well as install. At least 50% of the credits go to Tony Lownds (as they say: the bits that show a strike of genius are his, the stupidities are mine:-) --with-next-framework now has an optional argument saying where to install the framework (default /Library/Frameworks). Using --with-next-framework will also automatically set $prefix correctly. Makefile.pre.in will create a temporary skeleton framework in the build directory against which python.exe is linked and which is used when python is run from the build directory (for building the extensions, for instance). "make frameworkinstall" will install the complete framework (including Lib/python2.2 and all that jazz) in the final location. getpath.c now expects a "normal" python installation even in a framework, and it has also acquired (framework only) a bit of magic to detect that it is running with the skeleton framework from the build directory. The main reason for posting the patch here is that there's quite a bit of changes, and I can never be sure that it doesn't break things on other platforms. Assigned to Martin because he's one of the config purists and has provided valuable feedback before. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-08-14 18:35 Message: Logged In: YES user_id=45365 Checked in the changes, with most of Martin's suggestions incorporated (including "rip out next support", not including "why are you doing this in the first place":-). These versions of Makefile.pre.in and configure.in should definitely be tested for ill effects on other unix platforms. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-13 14:20 Message: Logged In: YES user_id=21627 Please see http://mail.python.org/pipermail/python-dev/2001-August/016990.html for further comments. If you are uncertain whether it works on any NeXT flavour, I recommend you remove the claim that it does. As for Darwin proper, doesn't your pulling in of the "Mac toolbox glue" pretty much destroy any hope that the framework code work on Darwin alone? The code itself works fine on Linux, no worries here. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-08-13 10:46 Message: Logged In: YES user_id=45365 As to the utility of frameworks: did you see my pythondev-post? Not convinced??!? As to OpenStep, Rhapsody and naked Darwin: I have absolutely no way of checking that. If someone responds to my "anyone using NeXTStep" question I'll ask them to try it. But, all that aside: did you check that these mods don't break builds on your system? That was my main reason for posting it here: from inspection it shouldn't break anything but I haven't tested it... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-13 09:14 Message: Logged In: YES user_id=21627 The patch looks technically fine now, also I still cannot see the utility of building libpython as a framework (and you add some quite code just for that feature). Also, you might recheck the likelyhood that --enable-framework really works on OpenStep and Rhapsody still. Likewise, would it work on a naked Darwin system (IOW, does Darwin proper include the Foundation, Carbon, and System frameworks)? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-08-13 07:51 Message: Logged In: YES user_id=45365 Ok, attached is a new patch which should address the issues you've raised: - --enable-framework in stead of --with-next-framework - comments updated Also a few minor things were changed to make building the plat-darwin1 directory work, and getting better linker errors when building extensions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-12 22:56 Message: Logged In: YES user_id=21627 Please see http://mail.python.org/pipermail/python-dev/2001-August/016944.html for my primary concerns about this change in configuration procedures. As for the specific patch: - There is a comment "NeXT framework builds require that the 'ar' library", however the next fragment does not mention either are nor libtool. The comment, at a minimum, should explain what BLDLIBRARY is. - What is the rationale for the various -u options? I find it extremely strange that you need such options. What happens if you leave them out? Where does the specific selection of -u option come from? Is that a hack around a problem that is not fully understood, or is it a procedure endorsed and documented by Apple? This is mysterious enough to require an elaborate comment on what exactly these symbols are, and why it is necessary to make them undefined. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450350&group_id=5470 From noreply@sourceforge.net Wed Aug 15 06:05:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 Aug 2001 22:05:35 -0700 Subject: [Patches] [ python-Patches-450862 ] distutils patch to find MacOSX dylibs Message-ID: Patches item #450862, was opened at 2001-08-14 09:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450862&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: distutils patch to find MacOSX dylibs Initial Comment: Distutils doesn't look for MacOSX's dylib archive files. This makes the default build of 2.1.1 and 2.2 (cvs) fail to make the zlib module. This patch adds dylib to the library file list. --Bill Noon ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 22:05 Message: Logged In: YES user_id=21627 Where is the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450862&group_id=5470 From urmost@europe.com Wed Aug 15 14:40:20 2001 From: urmost@europe.com (=?windows-1251?Q?=DE=F0=E8=E4=E8=F7=E5=F1=EA=E8=E9_=F6=E5=ED=F2=F0_=CC=CE=D1=D2?=) Date: Wed, 15 Aug 2001 17:40:20 +0400 Subject: [Patches] =?windows-1251?Q?=CD=C0=CB=CE=C3=CE=C2=C0=DF_=CF=CE=CB=C8=D6=C8=DF_=CD=C5_=C4=D0=C5=CC=CB=C5=D2_!!!?= Message-ID: <786520018315134020254@mail.ru> ------=_NextPart_84815C5ABAF209EF376268C8 Content-type: text/plain; charset="windows-1251" ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset="windows-1251"
Óâàæàåìûå ãîñïîäà!

Âû ðàáîòàåòå ñî ñâîèì ïðåäïðèÿòèåì áîëåå 2õ ëåò?
Ó âàñ åñòü çàäîëæåííîñòü ïåðåä áþäæåòîì?
Òàêèì îáðàçîì ïîâûøàåòñÿ âåðîÿòíîñòü ïðîâåðêè Âàøåãî ïðåäïðèÿòèÿ íàëîãîâîé èíñïåêöèåé, à âîçìîæíî íàëîãîâîé ïîëèöèåé. Òðåáóåòñÿ îáÿçàòåëüíîå ïðîâåäåíèå äîðîãîñòîÿùåé àóäèòîðñêîé ïðîâåðêè.

ÂÛÕÎÄ ÅÑÒÜ!!!

Þðèäè÷åñêàÿ ôèðìà «ÌÎÑÒ» ñâèäåòåëüñòâóåò Âàì ñâîå ïî÷òåíèå
è èìååò ÷åñòü ïðåäëîæèòü Âàì óñëóãè ïî
ëèêâèäàöèè ïðåäïðèÿòèé.
Ó Âàñ åñòü âîçìîæíîñòü âûáðàòü íàèáîëåå ïðèåìëåìûé âàðèàíò.

1.Ëèêâèäàöèÿ ñìåíîé ó÷ðåäèòåëåé è ðóêîâîäñòâà. Ìû ïðîèçâîäèì íàçíà÷åíèå íîâîãî äèðåêòîðà, ñìåíó ó÷ðåäèòåëåé è ïåðåðåãèñòðàöèþ èçìåíåíèé â ðåãèñòðàöèîííîé ïàëàòå, à òàêæå óâåäîìëåíèå îá ýòîì ÈÌÍÑ è ôîíäîâ. Íàø äèðåêòîð ËÈ×ÍÎ â âàøåì ïðèñóòñòâèè ãîòîâ ïðèíÿòü âñå äîêóìåíòû Âàøåãî ïðåäïðèÿòèÿ ïî àêòó ïðèåìà-ïåðåäà÷è.
Ïðîáëåìû ñ çàäîëæåííîñòüþ ïåðåä áþäæåòîì ìîãóò âàñ íå âîëíîâàòü.
Åñëè íå ñäàâàëèñü áàëàíñû, òî ìû ñäåëàåì è ñäàäèì èõ â ÈÌÍÑ ñàìè.
Ñòîèìîñòü óñëóãè - 400 äîë.
Ñðîê èñïîëíåíèÿ - 1,5-2 ìåñ.

2.Ëèêâèäàöèÿ ñëèÿíèåì. Ëèêâèäàöèÿ îñóùåñòâëÿåòñÿ ñëèÿíèåì Âàøåé ôèðìû ñ ïðåäïðèÿòèåì, çàðåãèñòðèðîâàííûì â ã. Òâåðü, ïðè ýòîì ïðàâà è îáÿçàííîñòè Âàøåé ôèðìû ïåðåõîäÿò ê âíîâü îáðàçîâàííîìó þðèäè÷åñêîìó ëèöó.
Ñòîèìîñòü óñëóãè - 550 äîë.
Ñðîê èñïîëíåíèÿ - 5-7 ìåñ.

3.Îôèöèàëüíàÿ ëèêâèäàöèÿ. Ëèêâèäàöèÿ þðèäè÷åñêîãî ëèöà âëå÷åò åãî ïðåêðàùåíèå áåç ïåðåõîäà ïðàâ è îáÿçàííîñòåé â ïîðÿäêå ïðàâîïðååìñòâà ê äðóãèì ëèöàì. Ýòîò âèä ëèêâèäàöèè ïðåäïðèÿòèÿ ñîïðÿæåí ñî ñäà÷åé ëèêâèäàöèîííîãî áàëàíñà è, êàê ïðàâèëî, ñ ïðîâåðêîé íàëîãîâîé èíñïåêöèè.
Ñòîèìîñòü óñëóãè - 1200 äîë
Ñðîê èñïîëíåíèÿ ðàáîòû - 5-7 ìåñ.

ÅÑËÈ ÂÛ ÏÐÎÈÇÂÎÄÈÒÅ ÒÎÂÀÐÛ È ÓÑËÓÃÈ, ÒÎ ÌÛ ÌÎÆÅÌ
ÐÀÑÑÌÎÒÐÅÒÜ ÂÀÐÈÀÍÒ ÎÏËÀÒÛ ÍÀØÈÕ ÓÑËÓÃ
ÏÐÎÈÇÂÎÄÈÌÛÌÈ ÂÀÌÈ ÒÎÂÀÐÀÌÈ ÈËÈ ÓÑËÓÃÀÌÈ.

Þðèäè÷åñêàÿ ôèðìà "ÌÎÑÒ"
Óë. Êóçíåöêèé Ìîñò, ä. 19, ñòð.1
Òåë./ôàêñ (095) 105-75-85 (ìíîãîêàíàëüíûé), 928-22-25
928-45-88, 928-12-45, 921-56-17
E-mail: urmost@europe.com
www.likvid.ru

ÌÛ ÂÑÅ ÑÄÅËÀÅÌ ÇÀ ÂÀÑ!

P.S. Åñëè Âû íå õîòèòå â äàëüíåéøåì ïîëó÷àòü íàøó èíôîðìàöèþ,
òî ìîæåòå èñêëþ÷èòü ñâîé àäðåñ patches@python.org èç ñïèñêà ðàññûëêè.
Äëÿ ýòîãî íàæìèòå íà ññûëêó:
http://www.likvid.ru/unsub4/index.php?email=patches@python. org&SUBMIT=UnSubscribe ------=_NextPart_84815C5ABAF209EF376268C8-- From MusicMaster" This newsletter is provided to you FREE! To unsubscribe, reply to this email with REMOVE in the Subject. August, 15, 2001 Today's Topics: (Full Stories, See Below) -MADONNA Cancels NJ Concert -Blues Traveler: New Album, New Tour -U2 Plans more US Tour Dates -311 To Headline Following Warped Tour -CONCERT TICKETS Anyone? MADONNA CANCELS NJ CONCERT: Madonna's Friday night (8/3) concert at the Continental Airlines Arena in East Rutherford, N.J., has been canceled, promoter Clear Channel Entertainment announced. According to the artist's management, she is suffering from laryngitis. The canceled show--which will not be rescheduled--was to have been Madonna's seventh sold-out performance in the New York area. The decision not to reschedule immediately drew an angry response from fans posting on her official website . "I think it's absolutely ridiculous that she didn't re-schedule the concert," one fan wrote. "I think it's safe to say that she alienated a lot of her fans for not being willing to move the show to a later date." All Ticketmaster phone and Internet orders will be automatically refunded and credited to the card holder within two weeks, according to a press release. Tickets purchased at Ticketmaster outlets and at the Continental Airlines Arena box office will be refunded at the point of purchase. (Ticketmaster is LiveDaily's parent company.) Madonna's tour is expected to resume in Boston on Aug. 7 and 8. BLUES TRAVELER: NEW ALBUM, NEW TOUR Blues Traveler returns to the tour circuit to promote its new album, "Bridge." The tour is set to begin August 18th. Blues Traveler has revealed the next batch of dates for its summer tour, which kicks off on Aug. 18 in Oneida, Wis. The band will perform in mostly secondary markets including Sedona, Ariz., Buffalo, N.Y., and Portsmouth, Va. The Pontiac, Mich., show on Aug. 31 is part of the free Labor Day festival Arts, Beats and Eats. On Aug. 25, Blues Traveler will perform on "Weekend Today" on NBC. More October tour dates will be announced soon, according to the band's spokesperson. The second leg of Blues Traveler's summer jaunt coincides with the release of "Back in the Day," the second single from its fifth studio album, "Bridge" (A&M Records/Interscope). GO Here For More Info: http://www.livedaily.citysearch.com/news/printable.html?id=3478 U2 Plans More US Tour Dates: U2, which wraps up a tour of Europe later this month, plans to return to North America later this year to play 25 additional concert dates, the Times of London reported this week. Though there have been persistent rumors that more North American dates will be added, no dates have been confirmed by the band or by concert organizers. The Times of London reported that U2's Elevation tour has grossed $142 million from worldwide ticket sales, and the that the new dates are expected to gross an additional $33 million. According to Pollstar, U2's March-June run through North America grossed $69 million. If estimates prove accurate--and if U2 does add the additional dates--U2's Elevation Tour could rank as the third-highest grossing North American tour of all time, behind 1994 outings by the Rolling Stones ($121 million) and Pink Floyd ($103.5 million), according to Pollstar. 311 To Headline Following Warped Tour As its stint on the Warped Tour winds down, 311 has revealed the dates for a late summer headlining tour. Warped ends on Sunday (8/12) in Pontiac, Mich., after which 311 heads to Europe for a handful of shows. The band returns to the United States in late August and begins its stateside tour on Sept. 8 in San Diego. The last date, according to its official website , is a Halloween show in Los Angeles. The group will then spend the early part of November in Japan. All of the dates are in support of 311's latest record, "From Chaos," 311's first for Volcano/Zomba. CONCERT TICKETS Anyone? We found a great place to get your next pair of tickets to your favorite event! We have dealt with them many times and they have really prooved a great source for tickets to concerts, sports, theater; All Nationwide. Check them out at www.tixx4u.com That's about it for now, see ya next time! From noreply@sourceforge.net Wed Aug 15 21:19:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 Aug 2001 13:19:50 -0700 Subject: [Patches] [ python-Patches-451305 ] Indeterminate progress bars Message-ID: Patches item #451305, was opened at 2001-08-15 13:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451305&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: Indeterminate progress bars Initial Comment: Support for indeterminate progress bars has been added to EasyDialogs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451305&group_id=5470 From noreply@sourceforge.net Wed Aug 15 21:51:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 Aug 2001 13:51:31 -0700 Subject: [Patches] [ python-Patches-424475 ] Speed-up tp_compare usage Message-ID: Patches item #424475, was opened at 2001-05-16 01:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 Category: core (C code) Group: None >Status: Open Resolution: Accepted >Priority: 7 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Speed-up tp_compare usage Initial Comment: This patch tries to optimize PyObject_RichCompare for the common case of objects with equal types which support tp_compare. It gives a speed-up of roughly 7% for comparing strings in a loop. The patch also gives type objects a tp_compare function, so that they can make use of the improvement. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-15 13:51 Message: Logged In: YES user_id=6380 I have to reopen this, because I've encountered a bug (I think). Take a trivial class: class C: pass and compare two instances of it: cmp(C(), C()) In Python 2.1.1 and before, this returned the same as cmp(id(C()), id(C())) but currently it always returns the value 2! This 2 is supposed to be an internal value that should never be returned. I am not 100% sure that it is this patch that's at fault, but I selectively rolled the object.c part of this patch back, and then it started doing the right thing again. I'm going to check in a test that verifies the correct behavior. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-09 00:40 Message: Logged In: YES user_id=21627 Committed as object.c 2.132, typeobject.c 2.17, UserList.py 1.17. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:19 Message: Logged In: YES user_id=31435 Accepted and assigned back to Martin. This is too valuable to quibble over. Note that when calling a tp_compare slot, this kind of thing: . c = (*f)(v, w); . if (PyErr_Occurred()) is better spelled: . c = (*f)(v, w); . if (c < 0 && Py_Err_Occurred()) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-05-21 09:57 Message: Logged In: YES user_id=21627 The revised patch prefers tp_compare over tp_richcompare in do_cmp if both are available. It also restores UserList.__cmp__ from deprecation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 From noreply@sourceforge.net Thu Aug 16 08:43:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 00:43:51 -0700 Subject: [Patches] [ python-Patches-424475 ] Speed-up tp_compare usage Message-ID: Patches item #424475, was opened at 2001-05-16 01:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted Priority: 7 Submitted By: Martin v. Löwis (loewis) >Assigned to: Guido van Rossum (gvanrossum) Summary: Speed-up tp_compare usage Initial Comment: This patch tries to optimize PyObject_RichCompare for the common case of objects with equal types which support tp_compare. It gives a speed-up of roughly 7% for comparing strings in a loop. The patch also gives type objects a tp_compare function, so that they can make use of the improvement. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 00:43 Message: Logged In: YES user_id=21627 It appears that do_cmp does not take into account the special calling semantics of tp_compare for instances. The attached cmp.diff fixes this case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-15 13:51 Message: Logged In: YES user_id=6380 I have to reopen this, because I've encountered a bug (I think). Take a trivial class: class C: pass and compare two instances of it: cmp(C(), C()) In Python 2.1.1 and before, this returned the same as cmp(id(C()), id(C())) but currently it always returns the value 2! This 2 is supposed to be an internal value that should never be returned. I am not 100% sure that it is this patch that's at fault, but I selectively rolled the object.c part of this patch back, and then it started doing the right thing again. I'm going to check in a test that verifies the correct behavior. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-09 00:40 Message: Logged In: YES user_id=21627 Committed as object.c 2.132, typeobject.c 2.17, UserList.py 1.17. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:19 Message: Logged In: YES user_id=31435 Accepted and assigned back to Martin. This is too valuable to quibble over. Note that when calling a tp_compare slot, this kind of thing: . c = (*f)(v, w); . if (PyErr_Occurred()) is better spelled: . c = (*f)(v, w); . if (c < 0 && Py_Err_Occurred()) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-05-21 09:57 Message: Logged In: YES user_id=21627 The revised patch prefers tp_compare over tp_richcompare in do_cmp if both are available. It also restores UserList.__cmp__ from deprecation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 From noreply@sourceforge.net Thu Aug 16 09:05:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 01:05:58 -0700 Subject: [Patches] [ python-Patches-424475 ] Speed-up tp_compare usage Message-ID: Patches item #424475, was opened at 2001-05-16 01:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted >Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: Speed-up tp_compare usage Initial Comment: This patch tries to optimize PyObject_RichCompare for the common case of objects with equal types which support tp_compare. It gives a speed-up of roughly 7% for comparing strings in a loop. The patch also gives type objects a tp_compare function, so that they can make use of the improvement. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-16 01:05 Message: Logged In: YES user_id=6380 Thanks for the quick fix. I'll check it in, because I want to commit some other changes to the same file. I still feel uneasy about the PyInstance_Check(). Shouldn't all types be allowed to return 2 from their tp_compare slot? (In general, the type/class unification makes me feel uneasy with *any* PyInstance_Check() special cases.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 00:43 Message: Logged In: YES user_id=21627 It appears that do_cmp does not take into account the special calling semantics of tp_compare for instances. The attached cmp.diff fixes this case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-15 13:51 Message: Logged In: YES user_id=6380 I have to reopen this, because I've encountered a bug (I think). Take a trivial class: class C: pass and compare two instances of it: cmp(C(), C()) In Python 2.1.1 and before, this returned the same as cmp(id(C()), id(C())) but currently it always returns the value 2! This 2 is supposed to be an internal value that should never be returned. I am not 100% sure that it is this patch that's at fault, but I selectively rolled the object.c part of this patch back, and then it started doing the right thing again. I'm going to check in a test that verifies the correct behavior. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-09 00:40 Message: Logged In: YES user_id=21627 Committed as object.c 2.132, typeobject.c 2.17, UserList.py 1.17. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:19 Message: Logged In: YES user_id=31435 Accepted and assigned back to Martin. This is too valuable to quibble over. Note that when calling a tp_compare slot, this kind of thing: . c = (*f)(v, w); . if (PyErr_Occurred()) is better spelled: . c = (*f)(v, w); . if (c < 0 && Py_Err_Occurred()) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-05-21 09:57 Message: Logged In: YES user_id=21627 The revised patch prefers tp_compare over tp_richcompare in do_cmp if both are available. It also restores UserList.__cmp__ from deprecation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 From noreply@sourceforge.net Thu Aug 16 10:58:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 02:58:45 -0700 Subject: [Patches] [ python-Patches-424475 ] Speed-up tp_compare usage Message-ID: Patches item #424475, was opened at 2001-05-16 01:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Speed-up tp_compare usage Initial Comment: This patch tries to optimize PyObject_RichCompare for the common case of objects with equal types which support tp_compare. It gives a speed-up of roughly 7% for comparing strings in a loop. The patch also gives type objects a tp_compare function, so that they can make use of the improvement. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 02:58 Message: Logged In: YES user_id=21627 The instance-tp-compare-is-special assumption was introduced with rich comparisons. Currently, it is nowhere specified that tp_compare *must* return -1/0/1, so for other types, 2 may well mean "one is larger than the other". In fact, in Py 2.1, string_compare would return Py_CHARMASK(*a->ob_sval) - Py_CHARMASK(*b->ob_sval) if the first two letters of the string were different. It is probably ok to tighten this up, but in a phased manner: First (in 2.2), document that the return type really is {-1,0,1}; then (in 2.3) extend the documentation to cover +2 as well, and perhaps even -2 (exception). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-16 01:05 Message: Logged In: YES user_id=6380 Thanks for the quick fix. I'll check it in, because I want to commit some other changes to the same file. I still feel uneasy about the PyInstance_Check(). Shouldn't all types be allowed to return 2 from their tp_compare slot? (In general, the type/class unification makes me feel uneasy with *any* PyInstance_Check() special cases.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 00:43 Message: Logged In: YES user_id=21627 It appears that do_cmp does not take into account the special calling semantics of tp_compare for instances. The attached cmp.diff fixes this case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-15 13:51 Message: Logged In: YES user_id=6380 I have to reopen this, because I've encountered a bug (I think). Take a trivial class: class C: pass and compare two instances of it: cmp(C(), C()) In Python 2.1.1 and before, this returned the same as cmp(id(C()), id(C())) but currently it always returns the value 2! This 2 is supposed to be an internal value that should never be returned. I am not 100% sure that it is this patch that's at fault, but I selectively rolled the object.c part of this patch back, and then it started doing the right thing again. I'm going to check in a test that verifies the correct behavior. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-09 00:40 Message: Logged In: YES user_id=21627 Committed as object.c 2.132, typeobject.c 2.17, UserList.py 1.17. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:19 Message: Logged In: YES user_id=31435 Accepted and assigned back to Martin. This is too valuable to quibble over. Note that when calling a tp_compare slot, this kind of thing: . c = (*f)(v, w); . if (PyErr_Occurred()) is better spelled: . c = (*f)(v, w); . if (c < 0 && Py_Err_Occurred()) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-05-21 09:57 Message: Logged In: YES user_id=21627 The revised patch prefers tp_compare over tp_richcompare in do_cmp if both are available. It also restores UserList.__cmp__ from deprecation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 From noreply@sourceforge.net Thu Aug 16 11:07:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 03:07:33 -0700 Subject: [Patches] [ python-Patches-423140 ] adds encode- and decodestring to quopri Message-ID: Patches item #423140, was opened at 2001-05-10 12:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423140&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aluo Nowu (etoffi) Assigned to: Barry Warsaw (bwarsaw) Summary: adds encode- and decodestring to quopri Initial Comment: i added this to match base64.py ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 03:07 Message: Logged In: YES user_id=21627 I recommend to approve this patch. It might be worthwhile to use cStringIO if available. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:23 Message: Logged In: YES user_id=3066 Assigned to Barry since the new APIs in base64 are his invention. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423140&group_id=5470 From noreply@sourceforge.net Thu Aug 16 11:14:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 03:14:11 -0700 Subject: [Patches] [ python-Patches-422329 ] Python 2.1 site.py patch Message-ID: Patches item #422329, was opened at 2001-05-08 08:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422329&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Gleen Aduana (gleen) Assigned to: Mark Hammond (mhammond) Summary: Python 2.1 site.py patch Initial Comment: site-package support in Python 2.1 does not work in Windows because site.py fails to add the site-package directory in sys.path ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 03:14 Message: Logged In: YES user_id=21627 This patch seems to be outdated, site-packages is already added to sys.path on all systems. If you think something still needs to be done, please submit a new patch. Make sure you use a context (-c) or unified (-u) diff then. ---------------------------------------------------------------------- Comment By: Gleen Aduana (gleen) Date: 2001-05-09 23:30 Message: Logged In: YES user_id=214628 It seems that PEP 250 (for release 2.2) addresses the same issue but was too late to have been included in release 2.1-final. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-05-09 12:32 Message: Logged In: YES user_id=31435 Mark, has site-packages ever worked on Windows? Not that I can recall. Do you want it to (the patch appears to want it to work the way it works on Macintosh (classic) boxes)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422329&group_id=5470 From noreply@sourceforge.net Thu Aug 16 11:15:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 03:15:23 -0700 Subject: [Patches] [ python-Patches-416704 ] More robust freeze Message-ID: Patches item #416704, was opened at 2001-04-17 07:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Toby Dickenson (htrd) >Assigned to: Nobody/Anonymous (nobody) Summary: More robust freeze Initial Comment: This patch addresses three issues, all relating to robustness of frozen programs. Specifically, this patch allows explicit and complete control over which modules may be loaded from source on the filesystem of the host system where the frozen program is run, and which may not. Without this patch it is impossible to create a non- trivial frozen program which will *never* load a module from source on the filesystem. 1. A patch to correct bug #404545 (frozen package import uses wrong files). Under this change, submodules of a frozen package must themselves be frozen modules. Previously, the import machinery may also try to import submodules from curiously named files (packagename.modulename.py) from directories in sys.path 2. A patch to add an extra command line option -E to freeze.py, which forces freeze to terminate with an error message if there are modules that it can not locate. If this switch is not specified then the default behaviour is unchanged: modules which can not be found by freeze will not be included in the frozen program, and the import machinery will try to load them from source on sys.path when the frozen program is run. In practice we have found that a missing module is probably an error (and it is a fairly frequent error too!). The -E switch can be used to detect this error; any missing modules will cause freeze.py to fail. In the rare case of a frozen module importing a non- frozen one (ie one which should be loaded from source when the program is run), the non-frozen module must be excluded from the freeze using the -x option. 3. A patch to add an extra command line option -X to freeze.py, which indicates that a specified module is excluded from the freeze, and also that the frozen program should not try to load the module from sys.path when it is imported. Importing the specified module will always trigger an ImportError. This is useful if a module used by a frozen program can optionally use a submodule... try: import optional_submodule except ImportError: pass It may be preferable for the frozen program's behaviour to not depend on whether optional_submodule happens to be installed on the host system, and that the 'import optional_submodule' should always fail with an ImportError. This can be achieved using the '- X optional_submodule' command line switch to freeze.py This is implemented by including the excluded module in the frozen imports table (_PyImport_FrozenModules), with the code pointer set to NULL. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-07 15:26 Message: Logged In: YES user_id=21627 Why is this assigned to Mark? I cannot see anything windows-specific in it. Mark, if you are not interested in reviewing this patch, I recommend to unassign this from yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 From noreply@sourceforge.net Thu Aug 16 11:53:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 03:53:56 -0700 Subject: [Patches] [ python-Patches-432401 ] unicode encoding error callbacks Message-ID: Patches item #432401, was opened at 2001-06-12 06:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode encoding error callbacks Initial Comment: This patch adds unicode error handling callbacks to the encode functionality. With this patch it's possible to not only pass 'strict', 'ignore' or 'replace' as the errors argument to encode, but also a callable function, that will be called with the encoding name, the original unicode object and the position of the unencodable character. The callback must return a replacement unicode object that will be encoded instead of the original character. For example replacing unencodable characters with XML character references can be done in the following way. u"aäoöuüß".encode( "ascii", lambda enc, uni, pos: u"&#x%x;" % ord(uni[pos]) ) ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-16 03:53 Message: Logged In: YES user_id=38388 I think we ought to summarize these changes in a PEP to get some more feedback and testing from others as well. I'll look into this after I'm back from vacation on the 10.09. Given the release schedule I am not sure whether this feature will make it into 2.2. The size of the patch is huge and probably needs a lot of testing first. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-26 20:55 Message: Logged In: YES user_id=89016 Changing the decoding API is done now. There are new functions codec.register_unicodedecodeerrorhandler and codec.lookup_unicodedecodeerrorhandler. Only the standard handlers for 'strict', 'ignore' and 'replace' are preregistered. There may be many reasons for decoding errors in the byte string, so I added an additional argument to the decoding API: reason, which gives the reason for the failure, e.g.: >>> "\U1111111".decode("unicode_escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 8: truncated \UXXXXXXXX escape >>> "\U11111111".decode("unicode_escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 9: illegal Unicode character For symmetry I added this to the encoding API too: >>> u"\xff".encode("ascii") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'ascii' can't decode byte 0xff in position 0: ordinal not in range(128) The parameters passed to the callbacks now are: encoding, unicode, position, reason, state. The encoding and decoding API for strings has been adapted too, so now the new API should be usable everywhere: >>> unicode("a\xffb\xffc", "ascii", ... lambda enc, uni, pos, rea, sta: (u"", pos+1)) u'abc' >>> "a\xffb\xffc".decode("ascii", ... lambda enc, uni, pos, rea, sta: (u"", pos+1)) u'abc' I had a problem with the decoding API: all the functions in _codecsmodule.c used the t# format specifier. I changed that to O! with &PyString_Type, because otherwise we would have the problem that the decoding API would must pass buffer object around instead of strings, and the callback would have to call str() on the buffer anyway to access a specific character, so this wouldn't be any faster than calling str() on the buffer before decoding. It seems that buffers aren't used anyway. I changed all the old function to call the new ones so bugfixes don't have to be done in two places. There are two exceptions: I didn't change PyString_AsEncodedString and PyString_AsDecodedString because they are documented as deprecated anyway (although they are called in a few spots) This means that I duplicated part of their functionality in PyString_AsEncodedObjectEx and PyString_AsDecodedObjectEx. There are still a few spots that call the old API: E.g. PyString_Format still calls PyUnicode_Decode (but with strict decoding) because it passes the rest of the format string to PyUnicode_Format when it encounters a Unicode object. Should we switch to the new API everywhere even if strict encoding/decoding is used? The size of this patch begins to scare me. I guess we need an extensive test script for all the new features and documentation. I hope you have time to do that, as I'll be busy with other projects in the next weeks. (BTW, I have't touched PyUnicode_TranslateCharmap yet.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-23 10:03 Message: Logged In: YES user_id=89016 New version of the patch with the error handling callback registry. > > OK, done, now there's a > > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > > codecs.escapereplace_unicodeencode_errors > > that uses \u (or \U if x>0xffff (with a wide build > > of Python)). > > Great! Now PyCodec_EscapeReplaceUnicodeEncodeErrors uses \x in addition to \u and \U where appropriate. > > [...] > > But for special one-shot error handlers, it might still be > > useful to pass the error handler directly, so maybe we > > should leave error as PyObject *, but implement the > > registry anyway? > > Good idea ! > > One minor nit: codecs.registerError() should be named > codecs.register_errorhandler() to be more inline with > the Python coding style guide. OK, but these function are specific to unicode encoding, so now the functions are called: codecs.register_unicodeencodeerrorhandler codecs.lookup_unicodeencodeerrorhandler Now all callbacks (including the new ones: "xmlcharrefreplace" and "escapereplace") are registered in the codecs.c/_PyCodecRegistry_Init so using them is really simple: u"gürk".encode("ascii", "xmlcharrefreplace") ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-13 04:26 Message: Logged In: YES user_id=38388 > > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > > with \uxxxx replacement callback. > > > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > > I'd rather leave the special encoder in place, > > > > since it is being used a lot in Python and > > > > probably some applications too. > > > > > > It would be a slowdown. But callbacks open many > > > possiblities. > > > > True, but in this case I believe that we should stick with > > the native implementation for "unicode-escape". Having > > a standard callback error handler which does the \uXXXX > > replacement would be nice to have though, since this would > > also be usable with lots of other codecs (e.g. all the > > code page ones). > > OK, done, now there's a > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > codecs.escapereplace_unicodeencode_errors > that uses \u (or \U if x>0xffff (with a wide build > of Python)). Great ! > > [...] > > > Should the old TranslateCharmap map to the new > > > TranslateCharmapEx and inherit the > > > "multicharacter replacement" feature, > > > or should I leave it as it is? > > > > If possible, please also add the multichar replacement > > to the old API. I think it is very useful and since the > > old APIs work on raw buffers it would be a benefit to have > > the functionality in the old implementation too. > > OK! I will try to find the time to implement that in the > next days. Good. > > [Decoding error callbacks] > > > > About the return value: > > > > I'd suggest to always use the same tuple interface, e.g. > > > > callback(encoding, input_data, input_position, > state) -> > > (output_to_be_appended, new_input_position) > > > > (I think it's better to use absolute values for the > > position rather than offsets.) > > > > Perhaps the encoding callbacks should use the same > > interface... what do you think ? > > This would make the callback feature hypergeneric and a > little slower, because tuples have to be created, but it > (almost) unifies the encoding and decoding API. ("almost" > because, for the encoder output_to_be_appended will be > reencoded, for the decoder it will simply be appended.), > so I'm for it. That's the point. Note that I don't think the tuple creation will hurt much (see the make_tuple() API in codecs.c) since small tuples are cached by Python internally. > I implemented this and changed the encoders to only > lookup the error handler on the first error. The UCS1 > encoder now no longer uses the two-item stack strategy. > (This strategy only makes sense for those encoder where > the encoding itself is much more complicated than the > looping/callback etc.) So now memory overflow tests are > only done, when an unencodable error occurs, so now the > UCS1 encoder should be as fast as it was without > error callbacks. > > Do we want to enforce new_input_position>input_position, > or should jumping back be allowed? No; moving backwards should be allowed (this may be useful in order to resynchronize with the input data). > Here's is the current todo list: > 1. implement a new TranslateCharmap and fix the old. > 2. New encoding API for string objects too. > 3. Decoding > 4. Documentation > 5. Test cases > > I'm thinking about a different strategy for implementing > callbacks > (see http://mail.python.org/pipermail/i18n-sig/2001- > July/001262.html) > > We coould have a error handler registry, which maps names > to error handlers, then it would be possible to keep the > errors argument as "const char *" instead of "PyObject *". > Currently PyCodec_UnicodeEncodeHandlerForObject is a > backwards compatibility hack that will never go away, > because > it's always more convenient to type > u"...".encode("...", "strict") > instead of > import codecs > u"...".encode("...", codecs.raise_encode_errors) > > But with an error handler registry this function would > become the official lookup method for error handlers. > (PyCodec_LookupUnicodeEncodeErrorHandler?) > Python code would look like this: > --- > def xmlreplace(encoding, unicode, pos, state): > return (u"&#%d;" % ord(uni[pos]), pos+1) > > import codec > > codec.registerError("xmlreplace",xmlreplace) > --- > and then the following call can be made: > u"äöü".encode("ascii", "xmlreplace") > As soon as the first error is encountered, the encoder uses > its builtin error handling method if it recognizes the name > ("strict", "replace" or "ignore") or looks up the error > handling function in the registry if it doesn't. In this way > the speed for the backwards compatible features is the same > as before and "const char *error" can be kept as the > parameter to all encoding functions. For speed common error > handling names could even be implemented in the encoder > itself. > > But for special one-shot error handlers, it might still be > useful to pass the error handler directly, so maybe we > should leave error as PyObject *, but implement the > registry anyway? Good idea ! One minor nit: codecs.registerError() should be named codecs.register_errorhandler() to be more inline with the Python coding style guide. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-12 04:03 Message: Logged In: YES user_id=89016 > > [...] > > so I guess we could change the replace handler > > to always return u'?'. This would make the > > implementation a little bit simpler, but the > > explanation of the callback feature *a lot* > > simpler. > > Go for it. OK, done! > [...] > > > Could you add these docs to the Misc/unicode.txt > > > file ? I will eventually take that file and turn > > > it into a PEP which will then serve as general > > > documentation for these things. > > > > I could, but first we should work out how the > > decoding callback API will work. > > Ok. BTW, Barry Warsaw already did the work of converting > the unicode.txt to PEP 100, so the docs should eventually > go there. OK. I guess it would be best to do this when everything is finished. > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > with \uxxxx replacement callback. > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > I'd rather leave the special encoder in place, > > > since it is being used a lot in Python and > > > probably some applications too. > > > > It would be a slowdown. But callbacks open many > > possiblities. > > True, but in this case I believe that we should stick with > the native implementation for "unicode-escape". Having > a standard callback error handler which does the \uXXXX > replacement would be nice to have though, since this would > also be usable with lots of other codecs (e.g. all the > code page ones). OK, done, now there's a PyCodec_EscapeReplaceUnicodeEncodeErrors/ codecs.escapereplace_unicodeencode_errors that uses \u (or \U if x>0xffff (with a wide build of Python)). > > For example: > > > > Why can't I print u"gürk"? > > > > is probably one of the most frequently asked > > questions in comp.lang.python. For printing > > Unicode stuff, print could be extended the use an > > error handling callback for Unicode strings (or > > objects where __str__ or tp_str returns a Unicode > > object) instead of using str() which always > > returns an 8bit string and uses strict encoding. > > There might even be a > > sys.setprintencodehandler()/sys.getprintencodehandler () > > There already is a print callback in Python (forgot the > name of the hook though), so this should be possible by > providing the encoding logic in the hook. True: sys.displayhook > [...] > > Should the old TranslateCharmap map to the new > > TranslateCharmapEx and inherit the > > "multicharacter replacement" feature, > > or should I leave it as it is? > > If possible, please also add the multichar replacement > to the old API. I think it is very useful and since the > old APIs work on raw buffers it would be a benefit to have > the functionality in the old implementation too. OK! I will try to find the time to implement that in the next days. > [Decoding error callbacks] > > About the return value: > > I'd suggest to always use the same tuple interface, e.g. > > callback(encoding, input_data, input_position, state) -> > (output_to_be_appended, new_input_position) > > (I think it's better to use absolute values for the > position rather than offsets.) > > Perhaps the encoding callbacks should use the same > interface... what do you think ? This would make the callback feature hypergeneric and a little slower, because tuples have to be created, but it (almost) unifies the encoding and decoding API. ("almost" because, for the encoder output_to_be_appended will be reencoded, for the decoder it will simply be appended.), so I'm for it. I implemented this and changed the encoders to only lookup the error handler on the first error. The UCS1 encoder now no longer uses the two-item stack strategy. (This strategy only makes sense for those encoder where the encoding itself is much more complicated than the looping/callback etc.) So now memory overflow tests are only done, when an unencodable error occurs, so now the UCS1 encoder should be as fast as it was without error callbacks. Do we want to enforce new_input_position>input_position, or should jumping back be allowed? > > > > One additional note: It is vital that errors > > > > is an assignable attribute of the StreamWriter. > > > > > > It is already ! > > > > I know, but IMHO it should be documented that an > > assignable errors attribute must be supported > > as part of the official codec API. > > > > Misc/unicode.txt is not clear on that: > > """ > > It is not required by the Unicode implementation > > to use these base classes, only the interfaces must > > match; this allows writing Codecs as extension types. > > """ > > Good point. I'll add that to the PEP 100. OK. Here's is the current todo list: 1. implement a new TranslateCharmap and fix the old. 2. New encoding API for string objects too. 3. Decoding 4. Documentation 5. Test cases I'm thinking about a different strategy for implementing callbacks (see http://mail.python.org/pipermail/i18n-sig/2001- July/001262.html) We coould have a error handler registry, which maps names to error handlers, then it would be possible to keep the errors argument as "const char *" instead of "PyObject *". Currently PyCodec_UnicodeEncodeHandlerForObject is a backwards compatibility hack that will never go away, because it's always more convenient to type u"...".encode("...", "strict") instead of import codecs u"...".encode("...", codecs.raise_encode_errors) But with an error handler registry this function would become the official lookup method for error handlers. (PyCodec_LookupUnicodeEncodeErrorHandler?) Python code would look like this: --- def xmlreplace(encoding, unicode, pos, state): return (u"&#%d;" % ord(uni[pos]), pos+1) import codec codec.registerError("xmlreplace",xmlreplace) --- and then the following call can be made: u"äöü".encode("ascii", "xmlreplace") As soon as the first error is encountered, the encoder uses its builtin error handling method if it recognizes the name ("strict", "replace" or "ignore") or looks up the error handling function in the registry if it doesn't. In this way the speed for the backwards compatible features is the same as before and "const char *error" can be kept as the parameter to all encoding functions. For speed common error handling names could even be implemented in the encoder itself. But for special one-shot error handlers, it might still be useful to pass the error handler directly, so maybe we should leave error as PyObject *, but implement the registry anyway? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-10 05:29 Message: Logged In: YES user_id=38388 Ok, here we go... > > > raise an exception). U+FFFD characters in the > replacement > > > string will be replaced with a character that the > encoder > > > chooses ('?' in all cases). > > > > Nice. > > But the special casing of U+FFFD makes the interface > somewhat > less clean than it could be. It was only done to be 100% > backwards compatible. With the original "replace" > error > handling the codec chose the replacement character. But as > far as I can tell none of the codecs uses anything other > than '?', True. > so I guess we could change the replace handler > to always return u'?'. This would make the implementation a > little bit simpler, but the explanation of the callback > feature *a lot* simpler. Go for it. > And if you still want to handle > an unencodable U+FFFD, you can write a special callback for > that, e.g. > > def FFFDreplace(enc, uni, pos): > if uni[pos] == "\ufffd": > return u"?" > else: > raise UnicodeError(...) > > > ...docs... > > > > Could you add these docs to the Misc/unicode.txt file ? I > > will eventually take that file and turn it into a PEP > which > > will then serve as general documentation for these things. > > I could, but first we should work out how the decoding > callback API will work. Ok. BTW, Barry Warsaw already did the work of converting the unicode.txt to PEP 100, so the docs should eventually go there. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > > replacement callback. > > > > Hmm, wouldn't that result in a slowdown ? If so, I'd > rather > > leave the special encoder in place, since it is being > used a > > lot in Python and probably some applications too. > > It would be a slowdown. But callbacks open many > possiblities. True, but in this case I believe that we should stick with the native implementation for "unicode-escape". Having a standard callback error handler which does the \uXXXX replacement would be nice to have though, since this would also be usable with lots of other codecs (e.g. all the code page ones). > For example: > > Why can't I print u"gürk"? > > is probably one of the most frequently asked questions in > comp.lang.python. For printing Unicode stuff, print could be > extended the use an error handling callback for Unicode > strings (or objects where __str__ or tp_str returns a > Unicode object) instead of using str() which always returns > an 8bit string and uses strict encoding. There might even > be a > sys.setprintencodehandler()/sys.getprintencodehandler() There already is a print callback in Python (forgot the name of the hook though), so this should be possible by providing the encoding logic in the hook. > > > I have not touched PyUnicode_TranslateCharmap yet, > > > should this function also support error callbacks? Why > > > would one want the insert None into the mapping to > call > > > the callback? > > > > 1. Yes. > > 2. The user may want to e.g. restrict usage of certain > > character ranges. In this case the codec would be used to > > verify the input and an exception would indeed be useful > > (e.g. say you want to restrict input to Hangul + ASCII). > > OK, do we want TranslateCharmap to work exactly like > encoding, > i.e. in case of an error should the returned replacement > string again be mapped through the translation mapping or > should it be copied to the output directly? The former would > be more in line with encoding, but IMHO the latter would > be much more useful. It's better to take the second approach (copy the callback output directly to the output string) to avoid endless recursion and other pitfalls. I suppose this will also simplify the implementation somewhat. > BTW, when I implement it I can implement patch #403100 > ("Multicharacter replacements in > PyUnicode_TranslateCharmap") > along the way. I've seen it; will comment on it later. > Should the old TranslateCharmap map to the new > TranslateCharmapEx > and inherit the "multicharacter replacement" feature, > or > should I leave it as it is? If possible, please also add the multichar replacement to the old API. I think it is very useful and since the old APIs work on raw buffers it would be a benefit to have the functionality in the old implementation too. [Decoding error callbacks] > > > A remaining problem is how to implement decoding error > > > callbacks. In Python 2.1 encoding and decoding errors > are > > > handled in the same way with a string value. But with > > > callbacks it doesn't make sense to use the same > callback > > > for encoding and decoding (like > codecs.StreamReaderWriter > > > and codecs.StreamRecoder do). Decoding callbacks have > a > > > different API. Which arguments should be passed to the > > > decoding callback, and what is the decoding callback > > > supposed to do? > > > > I'd suggest adding another set of PyCodec_UnicodeDecode... > () > > APIs for this. We'd then have to augment the base classes > of > > the StreamCodecs to provide two attributes for .errors > with > > a fallback solution for the string case (i.s. "strict" > can > > still be used for both directions). > > Sounds good. Now what is the decoding callback supposed to > do? > I guess it will be called in the same way as the encoding > callback, i.e. with encoding name, original string and > position of the error. It might returns a Unicode string > (i.e. an object of the decoding target type), that will be > emitted from the codec instead of the one offending byte. Or > it might return a tuple with replacement Unicode object and > a resynchronisation offset, i.e. returning (u"?", 1) > means > emit a '?' and skip the offending character. But to make > the offset really useful the callback has to know something > about the encoding, perhaps the codec should be allowed to > pass an additional state object to the callback? > > Maybe the same should be added to the encoding callbacks to? > Maybe the encoding callback should be able to tell the > encoder if the replacement returned should be reencoded > (in which case it's a Unicode object), or directly emitted > (in which case it's an 8bit string)? I like the idea of having an optional state object (basically this should be a codec-defined arbitrary Python object) which then allow the callback to apply additional tricks. The object should be documented to be modifyable in place (simplifies the interface). About the return value: I'd suggest to always use the same tuple interface, e.g. callback(encoding, input_data, input_position, state) -> (output_to_be_appended, new_input_position) (I think it's better to use absolute values for the position rather than offsets.) Perhaps the encoding callbacks should use the same interface... what do you think ? > > > One additional note: It is vital that errors is an > > > assignable attribute of the StreamWriter. > > > > It is already ! > > I know, but IMHO it should be documented that an assignable > errors attribute must be supported as part of the official > codec API. > > Misc/unicode.txt is not clear on that: > """ > It is not required by the Unicode implementation to use > these base classes, only the interfaces must match; this > allows writing Codecs as extension types. > """ Good point. I'll add that to the PEP 100. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-22 13:51 Message: Logged In: YES user_id=38388 Sorry to keep you waiting, Walter. I will look into this again next week -- this week was way too busy... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 10:00 Message: Logged In: YES user_id=38388 On your comment about the non-Unicode codecs: let's keep this separated from the current patch. Don't have much time today. I'll comment on the other things tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 08:49 Message: Logged In: YES user_id=89016 Guido van Rossum wrote in python-dev: > True, the "codec" pattern can be used for other > encodings than Unicode. But it seems to me that the > entire codecs architecture is rather strongly geared > towards en/decoding Unicode, and it's not clear > how well other codecs fit in this pattern (e.g. I > noticed that all the non-Unicode codecs ignore the > error handling parameter or assert that > it is set to 'strict'). I noticed that too. asserting that errors=='strict' would mean that the encoder is not able to deal in any other way with unencodable stuff than by raising an error. But that is not the problem here, because for zlib, base64, quopri, hex and uu encoding there can be no unencodable characters. The encoders can simply ignore the errors parameter. Should I remove the asserts from those codecs and change the docstrings accordingly, or will this be done separately? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 06:57 Message: Logged In: YES user_id=89016 > > [...] > > raise an exception). U+FFFD characters in the replacement > > string will be replaced with a character that the encoder > > chooses ('?' in all cases). > > Nice. But the special casing of U+FFFD makes the interface somewhat less clean than it could be. It was only done to be 100% backwards compatible. With the original "replace" error handling the codec chose the replacement character. But as far as I can tell none of the codecs uses anything other than '?', so I guess we could change the replace handler to always return u'?'. This would make the implementation a little bit simpler, but the explanation of the callback feature *a lot* simpler. And if you still want to handle an unencodable U+FFFD, you can write a special callback for that, e.g. def FFFDreplace(enc, uni, pos): if uni[pos] == "\ufffd": return u"?" else: raise UnicodeError(...) > > The implementation of the loop through the string is done > > in the following way. A stack with two strings is kept > > and the loop always encodes a character from the string > > at the stacktop. If an error is encountered and the stack > > has only one entry (during encoding of the original string) > > the callback is called and the unicode object returned is > > pushed on the stack, so the encoding continues with the > > replacement string. If the stack has two entries when an > > error is encountered, the replacement string itself has > > an unencodable character and a normal exception raised. > > When the encoder has reached the end of it's current string > > there are two possibilities: when the stack contains two > > entries, this was the replacement string, so the replacement > > string will be poppep from the stack and encoding continues > > with the next character from the original string. If the > > stack had only one entry, encoding is finished. > > Very elegant solution ! I'll put it as a comment in the source. > > (I hope that's enough explanation of the API and > implementation) > > Could you add these docs to the Misc/unicode.txt file ? I > will eventually take that file and turn it into a PEP which > will then serve as general documentation for these things. I could, but first we should work out how the decoding callback API will work. > > I have renamed the static ...121 function to all lowercase > > names. > > Ok. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > replacement callback. > > Hmm, wouldn't that result in a slowdown ? If so, I'd rather > leave the special encoder in place, since it is being used a > lot in Python and probably some applications too. It would be a slowdown. But callbacks open many possiblities. For example: Why can't I print u"gürk"? is probably one of the most frequently asked questions in comp.lang.python. For printing Unicode stuff, print could be extended the use an error handling callback for Unicode strings (or objects where __str__ or tp_str returns a Unicode object) instead of using str() which always returns an 8bit string and uses strict encoding. There might even be a sys.setprintencodehandler()/sys.getprintencodehandler() > [...] > I think it would be worthwhile to rename the callbacks to > include "Unicode" somewhere, e.g. > PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but > then it points out the application field of the callback > rather well. Same for the callbacks exposed through the > _codecsmodule. OK, done (and PyCodec_XMLCharRefReplaceUnicodeEncodeErrors really is a long name ;)) > > I have not touched PyUnicode_TranslateCharmap yet, > > should this function also support error callbacks? Why > > would one want the insert None into the mapping to call > > the callback? > > 1. Yes. > 2. The user may want to e.g. restrict usage of certain > character ranges. In this case the codec would be used to > verify the input and an exception would indeed be useful > (e.g. say you want to restrict input to Hangul + ASCII). OK, do we want TranslateCharmap to work exactly like encoding, i.e. in case of an error should the returned replacement string again be mapped through the translation mapping or should it be copied to the output directly? The former would be more in line with encoding, but IMHO the latter would be much more useful. BTW, when I implement it I can implement patch #403100 ("Multicharacter replacements in PyUnicode_TranslateCharmap") along the way. Should the old TranslateCharmap map to the new TranslateCharmapEx and inherit the "multicharacter replacement" feature, or should I leave it as it is? > > A remaining problem is how to implement decoding error > > callbacks. In Python 2.1 encoding and decoding errors are > > handled in the same way with a string value. But with > > callbacks it doesn't make sense to use the same callback > > for encoding and decoding (like codecs.StreamReaderWriter > > and codecs.StreamRecoder do). Decoding callbacks have a > > different API. Which arguments should be passed to the > > decoding callback, and what is the decoding callback > > supposed to do? > > I'd suggest adding another set of PyCodec_UnicodeDecode... () > APIs for this. We'd then have to augment the base classes of > the StreamCodecs to provide two attributes for .errors with > a fallback solution for the string case (i.s. "strict" can > still be used for both directions). Sounds good. Now what is the decoding callback supposed to do? I guess it will be called in the same way as the encoding callback, i.e. with encoding name, original string and position of the error. It might returns a Unicode string (i.e. an object of the decoding target type), that will be emitted from the codec instead of the one offending byte. Or it might return a tuple with replacement Unicode object and a resynchronisation offset, i.e. returning (u"?", 1) means emit a '?' and skip the offending character. But to make the offset really useful the callback has to know something about the encoding, perhaps the codec should be allowed to pass an additional state object to the callback? Maybe the same should be added to the encoding callbacks to? Maybe the encoding callback should be able to tell the encoder if the replacement returned should be reencoded (in which case it's a Unicode object), or directly emitted (in which case it's an 8bit string)? > > One additional note: It is vital that errors is an > > assignable attribute of the StreamWriter. > > It is already ! I know, but IMHO it should be documented that an assignable errors attribute must be supported as part of the official codec API. Misc/unicode.txt is not clear on that: """ It is not required by the Unicode implementation to use these base classes, only the interfaces must match; this allows writing Codecs as extension types. """ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 01:05 Message: Logged In: YES user_id=38388 > How the callbacks work: > > A PyObject * named errors is passed in. This may by NULL, > Py_None, 'strict', u'strict', 'ignore', u'ignore', > 'replace', u'replace' or a callable object. > PyCodec_EncodeHandlerForObject maps all of these objects to > one of the three builtin error callbacks > PyCodec_RaiseEncodeErrors (raises an exception), > PyCodec_IgnoreEncodeErrors (returns an empty replacement > string, in effect ignoring the error), > PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode > replacement character to signify to the encoder that it > should choose a suitable replacement character) or directly > returns errors if it is a callable object. When an > unencodable character is encounterd the error handling > callback will be called with the encoding name, the original > unicode object and the error position and must return a > unicode object that will be encoded instead of the offending > character (or the callback may of course raise an > exception). U+FFFD characters in the replacement string will > be replaced with a character that the encoder chooses ('?' > in all cases). Nice. > The implementation of the loop through the string is done in > the following way. A stack with two strings is kept and the > loop always encodes a character from the string at the > stacktop. If an error is encountered and the stack has only > one entry (during encoding of the original string) the > callback is called and the unicode object returned is pushed > on the stack, so the encoding continues with the replacement > string. If the stack has two entries when an error is > encountered, the replacement string itself has an > unencodable character and a normal exception raised. When > the encoder has reached the end of it's current string there > are two possibilities: when the stack contains two entries, > this was the replacement string, so the replacement string > will be poppep from the stack and encoding continues with > the next character from the original string. If the stack > had only one entry, encoding is finished. Very elegant solution ! > (I hope that's enough explanation of the API and implementation) Could you add these docs to the Misc/unicode.txt file ? I will eventually take that file and turn it into a PEP which will then serve as general documentation for these things. > I have renamed the static ...121 function to all lowercase > names. Ok. > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > replacement callback. Hmm, wouldn't that result in a slowdown ? If so, I'd rather leave the special encoder in place, since it is being used a lot in Python and probably some applications too. > PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, > PyCodec_ReplaceEncodeErrors are globally visible because > they have to be available in _codecsmodule.c to wrap them as > Python function objects, but they can't be implemented in > _codecsmodule, because they need to be available to the > encoders in unicodeobject.c (through > PyCodec_EncodeHandlerForObject), but importing the codecs > module might result in an endless recursion, because > importing a module requires unpickling of the bytecode, > which might require decoding utf8, which ... (but this will > only happen, if we implement the same mechanism for the > decoding API) I think that codecs.c is the right place for these APIs. _codecsmodule.c is only meant as Python access wrapper for the internal codecs and nothing more. One thing I noted about the callbacks: they assume that they will always get Unicode objects as input. This is certainly not true in the general case (it is for the codecs you touch in the patch). I think it would be worthwhile to rename the callbacks to include "Unicode" somewhere, e.g. PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but then it points out the application field of the callback rather well. Same for the callbacks exposed through the _codecsmodule. > I have not touched PyUnicode_TranslateCharmap yet, > should this function also support error callbacks? Why would > one want the insert None into the mapping to call the callback? 1. Yes. 2. The user may want to e.g. restrict usage of certain character ranges. In this case the codec would be used to verify the input and an exception would indeed be useful (e.g. say you want to restrict input to Hangul + ASCII). > A remaining problem is how to implement decoding error > callbacks. In Python 2.1 encoding and decoding errors are > handled in the same way with a string value. But with > callbacks it doesn't make sense to use the same callback for > encoding and decoding (like codecs.StreamReaderWriter and > codecs.StreamRecoder do). Decoding callbacks have a > different API. Which arguments should be passed to the > decoding callback, and what is the decoding callback > supposed to do? I'd suggest adding another set of PyCodec_UnicodeDecode...() APIs for this. We'd then have to augment the base classes of the StreamCodecs to provide two attributes for .errors with a fallback solution for the string case (i.s. "strict" can still be used for both directions). > One additional note: It is vital that errors is an > assignable attribute of the StreamWriter. It is already ! > Consider the XML example: For writing an XML DOM tree one > StreamWriter object is used. When a text node is written, > the error handling has to be set to > codecs.xmlreplace_encode_errors, but inside a comment or > processing instruction replacing unencodable characters with > charrefs is not possible, so here codecs.raise_encode_errors > should be used (or better a custom error handler that raises > an error that says "sorry, you can't have unencodable > characters inside a comment") Sure. > BTW, should we continue the discussion in the i18n SIG > mailing list? An email program is much more comfortable than > a HTML textarea! ;) I'd rather keep the discussions on this patch here -- forking it off to the i18n sig will make it very hard to follow up on it. (This HTML area is indeed damn small ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 12:18 Message: Logged In: YES user_id=89016 One additional note: It is vital that errors is an assignable attribute of the StreamWriter. Consider the XML example: For writing an XML DOM tree one StreamWriter object is used. When a text node is written, the error handling has to be set to codecs.xmlreplace_encode_errors, but inside a comment or processing instruction replacing unencodable characters with charrefs is not possible, so here codecs.raise_encode_errors should be used (or better a custom error handler that raises an error that says "sorry, you can't have unencodable characters inside a comment") BTW, should we continue the discussion in the i18n SIG mailing list? An email program is much more comfortable than a HTML textarea! ;) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 11:59 Message: Logged In: YES user_id=89016 How the callbacks work: A PyObject * named errors is passed in. This may by NULL, Py_None, 'strict', u'strict', 'ignore', u'ignore', 'replace', u'replace' or a callable object. PyCodec_EncodeHandlerForObject maps all of these objects to one of the three builtin error callbacks PyCodec_RaiseEncodeErrors (raises an exception), PyCodec_IgnoreEncodeErrors (returns an empty replacement string, in effect ignoring the error), PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode replacement character to signify to the encoder that it should choose a suitable replacement character) or directly returns errors if it is a callable object. When an unencodable character is encounterd the error handling callback will be called with the encoding name, the original unicode object and the error position and must return a unicode object that will be encoded instead of the offending character (or the callback may of course raise an exception). U+FFFD characters in the replacement string will be replaced with a character that the encoder chooses ('?' in all cases). The implementation of the loop through the string is done in the following way. A stack with two strings is kept and the loop always encodes a character from the string at the stacktop. If an error is encountered and the stack has only one entry (during encoding of the original string) the callback is called and the unicode object returned is pushed on the stack, so the encoding continues with the replacement string. If the stack has two entries when an error is encountered, the replacement string itself has an unencodable character and a normal exception raised. When the encoder has reached the end of it's current string there are two possibilities: when the stack contains two entries, this was the replacement string, so the replacement string will be poppep from the stack and encoding continues with the next character from the original string. If the stack had only one entry, encoding is finished. (I hope that's enough explanation of the API and implementation) I have renamed the static ...121 function to all lowercase names. BTW, I guess PyUnicode_EncodeUnicodeEscape could be reimplemented as PyUnicode_EncodeASCII with a \uxxxx replacement callback. PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, PyCodec_ReplaceEncodeErrors are globally visible because they have to be available in _codecsmodule.c to wrap them as Python function objects, but they can't be implemented in _codecsmodule, because they need to be available to the encoders in unicodeobject.c (through PyCodec_EncodeHandlerForObject), but importing the codecs module might result in an endless recursion, because importing a module requires unpickling of the bytecode, which might require decoding utf8, which ... (but this will only happen, if we implement the same mechanism for the decoding API) I have not touched PyUnicode_TranslateCharmap yet, should this function also support error callbacks? Why would one want the insert None into the mapping to call the callback? A remaining problem is how to implement decoding error callbacks. In Python 2.1 encoding and decoding errors are handled in the same way with a string value. But with callbacks it doesn't make sense to use the same callback for encoding and decoding (like codecs.StreamReaderWriter and codecs.StreamRecoder do). Decoding callbacks have a different API. Which arguments should be passed to the decoding callback, and what is the decoding callback supposed to do? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 11:00 Message: Logged In: YES user_id=38388 About the Py_UNICODE*data, int size APIs: Ok, point taken. In general, I think we ought to keep the callback feature as open as possible, so passing in pointers and sizes would not be very useful. BTW, could you summarize how the callback works in a few lines ? About _Encode121: I'd name this _EncodeUCS1 since that's what it is ;-) About the new functions: I was referring to the new static functions which you gave PyUnicode_... names. If these are not supposed to turn into non-static functions, I'd rather have them use lower case names (since that's how the Python internals work too -- most of the times). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:56 Message: Logged In: YES user_id=89016 > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. Another problem is, that the callback requires a Python object, so in the PyObject *version, the refcount is incref'd and the object is passed to the callback. The Py_UNICODE*/int version would have to create a new Unicode object from the data. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:32 Message: Logged In: YES user_id=89016 > * please don't place more than one C statement on one line > like in: > """ > + unicode = unicode2; unicodepos = > unicode2pos; > + unicode2 = NULL; unicode2pos = 0; > """ OK, done! > * Comments should start with a capital letter and be > prepended > to the section they apply to Fixed! > * There should be spaces between arguments in compares > (a == b) not (a==b) Fixed! > * Where does the name "...Encode121" originate ? encode one-to-one, it implements both ASCII and latin-1 encoding. > * module internal APIs should use lower case names (you > converted some of these to PyUnicode_...() -- this is > normally reserved for APIs which are either marked as > potential candidates for the public API or are very > prominent in the code) Which ones? I introduced a new function for every old one, that had a "const char *errors" argument, and a few new ones in codecs.h, of those PyCodec_EncodeHandlerForObject is vital, because it is used to map for old string arguments to the new function objects. PyCodec_RaiseEncodeErrors can be used in the encoder implementation to raise an encode error, but it could be made static in unicodeobject.h so only those encoders implemented there have access to it. > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. I look through the code and found no situation where the Py_UNICODE*/int version is really used and having two (PyObject *)s (the original and the replacement string), instead of UNICODE*/int and PyObject * made the implementation a little easier, but I can fix that. > Please separate the errors.c patch from this patch -- it > seems totally unrelated to Unicode. PyCodec_RaiseEncodeErrors uses this the have a \Uxxxx with four hex digits. I removed it. I'll upload a revised patch as soon as it's done. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 07:29 Message: Logged In: YES user_id=38388 Thanks for the patch -- it looks very impressive !. I'll give it a try later this week. Some first cosmetic tidbits: * please don't place more than one C statement on one line like in: """ + unicode = unicode2; unicodepos = unicode2pos; + unicode2 = NULL; unicode2pos = 0; """ * Comments should start with a capital letter and be prepended to the section they apply to * There should be spaces between arguments in compares (a == b) not (a==b) * Where does the name "...Encode121" originate ? * module internal APIs should use lower case names (you converted some of these to PyUnicode_...() -- this is normally reserved for APIs which are either marked as potential candidates for the public API or are very prominent in the code) One thing which I don't like about your API change is that you removed the Py_UNICODE*data, int size style arguments -- this makes it impossible to use the new APIs on non-Python data or data which is not available as Unicode object. Please separate the errors.c patch from this patch -- it seems totally unrelated to Unicode. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 From noreply@sourceforge.net Thu Aug 16 12:20:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 04:20:44 -0700 Subject: [Patches] [ python-Patches-409444 ] Redirect stdout in distutils.spawn Message-ID: Patches item #409444, was opened at 2001-03-17 12:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409444&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Redirect stdout in distutils.spawn Initial Comment: The attached patch (yeah, right) modifies distutils/spawn.py to add the ability to redirect standard output to a file, at least on POSIX platforms. This would be needed for Barry's patch to support shar as a Distutils output format. Questions: * Is this a good idea? * Is the interface right? Should it take a file object instead of a filename? (It therefore always uses 'wb' mode, which may be bad.) * Can someone contribute the required changes to make this work on NT? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 04:20 Message: Logged In: YES user_id=21627 I recommend to reject this patch. Apparently, still nobody has contributed code to support this on NT; I believe you'd need to use CreateProcess(Ex?) to make it work, which is not exposed anywhere in standard Python. Furthermore, I don't like the posix approach, either. There is no guarantee that the next open will assign fd 1 again. If the assertion fails, I bet that spawn() will not raise a Distutils error, as it should. Instead, funny things may happen due to the AssertionError being raised. Instead, the right way probably is to use os.open/os.dup2/os.fdopen. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409444&group_id=5470 From noreply@sourceforge.net Thu Aug 16 13:49:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 05:49:54 -0700 Subject: [Patches] [ python-Patches-451538 ] L10n of pprint Message-ID: Patches item #451538, was opened at 2001-08-16 05:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451538&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Denis S. Otkidach (ods) Assigned to: Nobody/Anonymous (nobody) Summary: L10n of pprint Initial Comment: Representation of strings with non-latin national characters is quite unreadable. Although we can use current locale to determine full set of printable character. This patch in combination with dysplay_hook allows to get native representation for 8-bit strings, including ones in dictionaries, lists and tuples. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451538&group_id=5470 From noreply@sourceforge.net Thu Aug 16 13:53:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 05:53:05 -0700 Subject: [Patches] [ python-Patches-451538 ] L10n of pprint Message-ID: Patches item #451538, was opened at 2001-08-16 05:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451538&group_id=5470 >Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Denis S. Otkidach (ods) Assigned to: Nobody/Anonymous (nobody) Summary: L10n of pprint Initial Comment: Representation of strings with non-latin national characters is quite unreadable. Although we can use current locale to determine full set of printable character. This patch in combination with dysplay_hook allows to get native representation for 8-bit strings, including ones in dictionaries, lists and tuples. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451538&group_id=5470 From noreply@sourceforge.net Thu Aug 16 14:21:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 06:21:17 -0700 Subject: [Patches] [ python-Patches-427190 ] Speed-up "O" calls Message-ID: Patches item #427190, was opened at 2001-05-24 22:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=427190&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) >Summary: Speed-up "O" calls Initial Comment: This patch improves the performance of a few functions which have an "O" signature (ord, len, and list_append). On selected test cases, this patch gives a speed-up of 40%. If accepted, the approach can be extended to more signatures. E.g. "l" is already provided in the patch, but currently not used. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 06:21 Message: Logged In: YES user_id=21627 Committed as api.tex 1.140, NEWS 1.206, complexobject.c 2.38, descrobject.c 2.3, dictobject.c 2.109, fileobject.c 2.118, iterobject.c 1.7, listobject.c 2.99, methodobject.c 2.37, rangeobject.c 2.28, stringobject.c 2.123, typeobject.c 2.36, unicodeobject.c 2.108, bltinmodule.c 2.226, ceval.c 2.267, and sysmodule.c 2.91. There were only slight changes to the patch: a few additional METH_O usages, and get/setdlopenflags was restored. None of the modules uses the new calling convention, yet. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-13 15:47 Message: Logged In: YES user_id=31392 The attached patch applies cleanly against current CVS and implements the fast_cfunction() support for METH_O and METH_NOARGS. Does this patch still look okay to you, Martin? If so, I say we check it in. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-12 14:46 Message: Logged In: YES user_id=31392 Must also update fast_cfunction() to handle METH_NOARGS and METH_ARGS, as these can be done on the fast path. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-12 14:11 Message: Logged In: YES user_id=31392 I've updated the patch to compile against the current source tree. I also revised the switch statement that dispatches on function flags (METH_O, METH_VARARGS, ...) to avoid the goto. The big change for descr branch compatibility was to define the dispatch for C functions in methodobject.c as PyCFunction_Call() so that it can be used in ceval.c and methodobject.c. I'd approve right now, but it looks like there is a lot of unused code for calling functions in ceval.c, and I'd like to clean that up first. We also need to see if there are no opportunities to use METHO_O and METH_NOARGS, which I didn't do. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-17 18:41 Message: Logged In: YES user_id=21627 Uploaded new version which invokes string_join correctly from _PyString_Join. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-02 03:12 Message: Logged In: YES user_id=21627 New version uploaded. This uses functions with only the self argument for METH_NOARGS, and introduces PyNoArgsFunction for them. It also adds a section for api.tex documenting the METH_ flags, and an entry in NEWS mentioning the new METH_ flags. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-06-01 08:14 Message: Logged In: YES user_id=31392 Just took a quick look -- looks good. One question: Why does METH_NOARGS call the method with two arguments where the second is always NULL? Wouldn't it be clearer to have these functions take one argument? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-01 07:34 Message: Logged In: YES user_id=21627 I rewrote the patch to only support METH_NOARGS and METH_O, and to not use bit masks for them. I also changed calling conventions for all Object operations and bltin and sys functions. In the course of these changes, two functions got a changed meaning: - file.writelines accepts only exactly one argument - iter.next does not accept any arguments anymore As you can see in the patch,there is still a lot of places that continue to use OLDARGS (plus all the Modules functions that have not been changed in this patch), so OLDARGS will be needed for quite some time. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-05-29 13:59 Message: Logged In: YES user_id=31392 I like METH_O, but I'm not sure about METH_L. I'd rather see the call handling in ceval be type-neutral. It's easy enough for the callee to cast from an object to an int (or any other type). There should be no effect on performance and it reduces the amount of code in the core. I think the implementation could be simplified a lot if it defined METH_O -- or perhaps METH_NOARGS, METH_ONEARG, and maybe even METH_TWOARGS (but Tim has a pretty good argument against that one). I don't think there's any define METH_O via METH_SPECIAL and reserve all of 0xFFF0 for flags on METH_SPECIAL. Instead, I'd just use the next N bits to implement the next N flags. The SPECIALSIZE and extra stack used in the implementation seem like unneeded generality, too. If the implementation is only going to support 0 and 1 (and possibly 2) argument, there's no need for anything more general. Finally, I suggest appropriating fast_cfunction() for this purpose, rather than calling the new function do_call_special(), where "special" isn't a very specific meaning. If METH_NOARGS and METH_ONEARG are implemented, there is basically no reason to use METH_OLDARGS. So we can get rid of it in the code base and stop attempting to optimize it. Do you want to have a go at a smaller patch that just did METH_ONEARG and METH_NOARGS? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=427190&group_id=5470 From noreply@sourceforge.net Thu Aug 16 14:23:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 06:23:51 -0700 Subject: [Patches] [ python-Patches-424475 ] Speed-up tp_compare usage Message-ID: Patches item #424475, was opened at 2001-05-16 01:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Guido van Rossum (gvanrossum) Summary: Speed-up tp_compare usage Initial Comment: This patch tries to optimize PyObject_RichCompare for the common case of objects with equal types which support tp_compare. It gives a speed-up of roughly 7% for comparing strings in a loop. The patch also gives type objects a tp_compare function, so that they can make use of the improvement. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 02:58 Message: Logged In: YES user_id=21627 The instance-tp-compare-is-special assumption was introduced with rich comparisons. Currently, it is nowhere specified that tp_compare *must* return -1/0/1, so for other types, 2 may well mean "one is larger than the other". In fact, in Py 2.1, string_compare would return Py_CHARMASK(*a->ob_sval) - Py_CHARMASK(*b->ob_sval) if the first two letters of the string were different. It is probably ok to tighten this up, but in a phased manner: First (in 2.2), document that the return type really is {-1,0,1}; then (in 2.3) extend the documentation to cover +2 as well, and perhaps even -2 (exception). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-16 01:05 Message: Logged In: YES user_id=6380 Thanks for the quick fix. I'll check it in, because I want to commit some other changes to the same file. I still feel uneasy about the PyInstance_Check(). Shouldn't all types be allowed to return 2 from their tp_compare slot? (In general, the type/class unification makes me feel uneasy with *any* PyInstance_Check() special cases.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 00:43 Message: Logged In: YES user_id=21627 It appears that do_cmp does not take into account the special calling semantics of tp_compare for instances. The attached cmp.diff fixes this case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-15 13:51 Message: Logged In: YES user_id=6380 I have to reopen this, because I've encountered a bug (I think). Take a trivial class: class C: pass and compare two instances of it: cmp(C(), C()) In Python 2.1.1 and before, this returned the same as cmp(id(C()), id(C())) but currently it always returns the value 2! This 2 is supposed to be an internal value that should never be returned. I am not 100% sure that it is this patch that's at fault, but I selectively rolled the object.c part of this patch back, and then it started doing the right thing again. I'm going to check in a test that verifies the correct behavior. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-09 00:40 Message: Logged In: YES user_id=21627 Committed as object.c 2.132, typeobject.c 2.17, UserList.py 1.17. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:19 Message: Logged In: YES user_id=31435 Accepted and assigned back to Martin. This is too valuable to quibble over. Note that when calling a tp_compare slot, this kind of thing: . c = (*f)(v, w); . if (PyErr_Occurred()) is better spelled: . c = (*f)(v, w); . if (c < 0 && Py_Err_Occurred()) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-05-21 09:57 Message: Logged In: YES user_id=21627 The revised patch prefers tp_compare over tp_richcompare in do_cmp if both are available. It also restores UserList.__cmp__ from deprecation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 From noreply@sourceforge.net Thu Aug 16 14:50:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 06:50:34 -0700 Subject: [Patches] [ python-Patches-409444 ] Redirect stdout in distutils.spawn Message-ID: Patches item #409444, was opened at 2001-03-17 12:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409444&group_id=5470 Category: distutils Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Redirect stdout in distutils.spawn Initial Comment: The attached patch (yeah, right) modifies distutils/spawn.py to add the ability to redirect standard output to a file, at least on POSIX platforms. This would be needed for Barry's patch to support shar as a Distutils output format. Questions: * Is this a good idea? * Is the interface right? Should it take a file object instead of a filename? (It therefore always uses 'wb' mode, which may be bad.) * Can someone contribute the required changes to make this work on NT? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 06:50 Message: Logged In: YES user_id=11375 Agreed. Marking as rejected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 04:20 Message: Logged In: YES user_id=21627 I recommend to reject this patch. Apparently, still nobody has contributed code to support this on NT; I believe you'd need to use CreateProcess(Ex?) to make it work, which is not exposed anywhere in standard Python. Furthermore, I don't like the posix approach, either. There is no guarantee that the next open will assign fd 1 again. If the assertion fails, I bet that spawn() will not raise a Distutils error, as it should. Instead, funny things may happen due to the AssertionError being raised. Instead, the right way probably is to use os.open/os.dup2/os.fdopen. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409444&group_id=5470 From noreply@sourceforge.net Thu Aug 16 14:57:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 06:57:35 -0700 Subject: [Patches] [ python-Patches-442530 ] Distutils config buggy Message-ID: Patches item #442530, was opened at 2001-07-18 11:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442530&group_id=5470 Category: distutils Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: A.M. Kuchling (akuchling) Summary: Distutils config buggy Initial Comment: The config command of distutils has some types in it First every time the _preprocess or _compile method is called the include_dirs argument is omitted. Second the search_cpp method tries to do a re search with the line: if pattern.search(pattern): which should be if pattern.search(line): I've attached a complete corrected version from CVS. Tarn ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 06:57 Message: Logged In: YES user_id=11375 Thanks; accepted and checked in! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-13 07:18 Message: Logged In: YES user_id=11375 Taking over this patch... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442530&group_id=5470 From noreply@sourceforge.net Thu Aug 16 15:01:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 07:01:04 -0700 Subject: [Patches] [ python-Patches-451538 ] L10n of pprint Message-ID: Patches item #451538, was opened at 2001-08-16 05:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451538&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Denis S. Otkidach (ods) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: L10n of pprint Initial Comment: Representation of strings with non-latin national characters is quite unreadable. Although we can use current locale to determine full set of printable character. This patch in combination with dysplay_hook allows to get native representation for 8-bit strings, including ones in dictionaries, lists and tuples. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451538&group_id=5470 From noreply@sourceforge.net Thu Aug 16 15:01:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 07:01:10 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 9 Submitted By: Paul Moore (pmoore) Assigned to: Thomas Heller (theller) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:01 Message: Logged In: YES user_id=11375 Thomas, do you want to apply this patch or shall I do it? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Thu Aug 16 15:08:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 07:08:23 -0700 Subject: [Patches] [ python-Patches-444854 ] Distutils config _link doesn't clean up Message-ID: Patches item #444854, was opened at 2001-07-26 09:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444854&group_id=5470 Category: distutils Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils config _link doesn't clean up Initial Comment: The distutils.config.config._link method doesn't return the right program name for win32 and hence doesn't clean up after itself properly. There's a comment about this in the source...is there a reason this isn't done? Anyways, the offending code is: prog = os.path.splitext(os.path.basename(src))[0] self.temp_files.append(prog) which should be changed to prog = os.path.splitext(os.path.basename(src))[0] if sys.platform == 'win32': prog = prog + '.exe' self.temp_files.append(prog) The sys module needs to imported also. thanks, Tarn ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:08 Message: Logged In: YES user_id=11375 Actually I think it can be made simpler still, by just doing 'prog = prog + self.compiler.exe_extension'. I'll check it in using this approach. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-07-26 13:45 Message: Logged In: YES user_id=21784 Sorry, previous fix doesn't quite work. The lines: if sys.platform == 'win32': prog = prog + '.exe' self.temp_files.append(prog) need to be placed after the line: self.compiler.link_executable(... otherwise the executable gets the wrong name ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444854&group_id=5470 From noreply@sourceforge.net Thu Aug 16 15:12:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 07:12:10 -0700 Subject: [Patches] [ python-Patches-441350 ] Disutils config try_run broken Message-ID: Patches item #441350, was opened at 2001-07-14 15:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441350&group_id=5470 Category: distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: A.M. Kuchling (akuchling) Summary: Disutils config try_run broken Initial Comment: The distutils.command.config try_run method is broken. First it doesn't save the name of the compiled prog, then it tries to execute the non-existent symbol "exe" Here is what it does now: --------- try: self._link(body, headers, include_dirs, libraries, library_dirs, lang) self.spawn([exe]) ok = 1 except (CompileError, LinkError, DistutilsExecError): ok = 0 --------- This will fix it: --------- try: src, obj, prog = self._link(body, headers, include_dirs, libraries, library_dirs, lang) self.spawn([prog]) ok = 1 except (CompileError, LinkError, DistutilsExecError): ok = 0 ---------- Tarn twburton@users.sf.net ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:12 Message: Logged In: YES user_id=11375 Fixed in revision 1.7 of config.py; thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441350&group_id=5470 From noreply@sourceforge.net Thu Aug 16 19:42:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 11:42:17 -0700 Subject: [Patches] [ python-Patches-443899 ] Minor fix to gzip.py module. Message-ID: Patches item #443899, was opened at 2001-07-23 12:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Jeremy Hylton (jhylton) Summary: Minor fix to gzip.py module. Initial Comment: --- from cStringIO import StringIO from gzip import GzipFile stringFile = StringIO() gzFile = GzipFile("test1", 'wb', 9, stringFile) gzFile.write('howdy there!') r = gzFile.read() --- the above code fragment gave a nonintuitive error response (attribute missing). Now, an exception is raised stating that the file is not opened for reading or writing. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 11:42 Message: Logged In: YES user_id=21627 Please always submit context (-c) or unified (-u) diffs; I've reformatted your patch by retrieving 1.24, applying the patch, updating to the current version, and regenerating the patch. Apart from that, the patch looks fine to me, and I recommend to approve it. One consideration is the exception being raised: Maybe IOError is more appropriate. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 12:15 Message: Logged In: YES user_id=23486 (sorry -- misunderstanding of how the changelog view works) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 From noreply@sourceforge.net Thu Aug 16 20:02:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 12:02:39 -0700 Subject: [Patches] [ python-Patches-421709 ] Access { thread id : frame } dict Message-ID: Patches item #421709, was opened at 2001-05-05 13:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421709&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John D. Heintz (jheintz) Assigned to: Barry Warsaw (bwarsaw) Summary: Access { thread id : frame } dict Initial Comment: This patch adds a new function sys._getframes() that returns a dictionary mapping from thread id to current frame object. This is very useful when diagnosing deadlock issues in Python code. The new C code function is purely additive except for modifying the PyThreadState struct (adding a long thread_ident) and modifying PyThreadState_New() function to set this new long. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 12:02 Message: Logged In: YES user_id=21627 I propose to close this patch if it is not updated by Oct 1, 2001. If it is not updated by the time the last alpha is released, it probably has no chance to go into Python 2.2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-05 01:00 Message: Logged In: YES user_id=21627 There is a difference between these two functions. _getframe is not an official API; inspect.currentframe is the official API. It seems that your function is meant to be used via sys, so it would be public there. In any case, I also think that the sys._getframe doc string should not talk about intended uses - if anything, it should mention what function to call instead. ---------------------------------------------------------------------- Comment By: John D. Heintz (jheintz) Date: 2001-06-04 10:52 Message: Logged In: YES user_id=20438 Martin: I agree with you on the documentation issue and will look into the tuple size issue you raised. The docstring is modeled on the sys._getframe() function so I figured it would be sufficient to follow the leader. (I think that both sys._getframe() and sys._getframes() should be part of the public api for the sys module by the way.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 10:28 Message: Logged In: YES user_id=21627 I think the patch could use some more documentation, e.g. as a patch to Doc/lib/libsys.tex. E.g. what are the tuples that are put into the dictionaries? Also, isn't there a problem with the tuple size? The patch allocates tuples of size 0, but then puts things into index 0. Is there any kind of test case for this code? Finally, I don't think the docstring should say that the function is for internal and specialized purposes only (what specialized purposes, anyway), if you think its primary use is in diagnosing deadlocks. It should only document what the function does, not what you intend it to use for. For these reasons, I also think its name should not start with an underscore. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421709&group_id=5470 From noreply@sourceforge.net Thu Aug 16 21:18:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 13:18:06 -0700 Subject: [Patches] [ python-Patches-441691 ] BCPP Preprocessor Message-ID: Patches item #441691, was opened at 2001-07-16 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441691&group_id=5470 Category: distutils Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: A.M. Kuchling (akuchling) Summary: BCPP Preprocessor Initial Comment: Preprocessor method for bcppcompiler. The only missing functionality is the ability to send the output to stdout. cpp32 can't seem to do this. This doesn't really seem needed anyways. Tarn ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 13:18 Message: Logged In: YES user_id=11375 Looks good, though I have no way of testing it. Applied to revision 1.10 of bcppcompiler.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441691&group_id=5470 From noreply@sourceforge.net Thu Aug 16 21:21:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 13:21:07 -0700 Subject: [Patches] [ python-Patches-441528 ] MSVC Preprocessor Message-ID: Patches item #441528, was opened at 2001-07-15 15:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: MSVC Preprocessor Initial Comment: The attached script has a preprocessor method for the MSVC compiler. Tarn twburton@users.sf.net ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 13:21 Message: Logged In: YES user_id=11375 config.py doesn't actually do anything when run; it's a copy of distutils.commands.config.py. Was it intended to be a setup.py script? ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-07-18 11:59 Message: Logged In: YES user_id=21784 Added test script config.py To run: "python config.py config" Also added msvccompiler.py which fixes a bug from my first post of pp.py, and is a modification of the current CVS version. Tarn ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-07-18 00:58 Message: Logged In: YES user_id=11105 Tarn, can you supply an example where this code would be executed? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 06:40 Message: Logged In: YES user_id=11375 Reassigning to Thomas, since I can't test anything with MSVC. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-16 06:23 Message: Logged In: YES user_id=6380 Or should this go to Thomas Heller? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 From noreply@sourceforge.net Thu Aug 16 21:33:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 13:33:01 -0700 Subject: [Patches] [ python-Patches-443899 ] Minor fix to gzip.py module. Message-ID: Patches item #443899, was opened at 2001-07-23 12:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Jeremy Hylton (jhylton) Summary: Minor fix to gzip.py module. Initial Comment: --- from cStringIO import StringIO from gzip import GzipFile stringFile = StringIO() gzFile = GzipFile("test1", 'wb', 9, stringFile) gzFile.write('howdy there!') r = gzFile.read() --- the above code fragment gave a nonintuitive error response (attribute missing). Now, an exception is raised stating that the file is not opened for reading or writing. ---------------------------------------------------------------------- >Comment By: Titus Brown (titus) Date: 2001-08-16 13:33 Message: Logged In: YES user_id=23486 Re: context diff, thanks & sorry for the trouble; my newer patches are being submitted this way. Re: IOError, I wasn't sure which exception to use at the time. I therefore took my cue from other code in the gzip module, which raises a ValueError when self.fileobj is closed. The only IO errors raised in the module are those that pertain to incorrect file formats. I'd be happy to change any and all of the ValueErrors that are raised into IOErrors, but I think the current consistency of errors should be maintained ;). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-16 11:42 Message: Logged In: YES user_id=21627 Please always submit context (-c) or unified (-u) diffs; I've reformatted your patch by retrieving 1.24, applying the patch, updating to the current version, and regenerating the patch. Apart from that, the patch looks fine to me, and I recommend to approve it. One consideration is the exception being raised: Maybe IOError is more appropriate. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 12:15 Message: Logged In: YES user_id=23486 (sorry -- misunderstanding of how the changelog view works) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 From noreply@sourceforge.net Thu Aug 16 21:49:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 13:49:51 -0700 Subject: [Patches] [ python-Patches-441528 ] MSVC Preprocessor Message-ID: Patches item #441528, was opened at 2001-07-15 15:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: MSVC Preprocessor Initial Comment: The attached script has a preprocessor method for the MSVC compiler. Tarn twburton@users.sf.net ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-08-16 13:49 Message: Logged In: YES user_id=21784 Oops, sorry. Added test.py, i.e. run with test.py config Also the msvccompiler.py file has a print line which should probably be removed ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 13:21 Message: Logged In: YES user_id=11375 config.py doesn't actually do anything when run; it's a copy of distutils.commands.config.py. Was it intended to be a setup.py script? ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-07-18 11:59 Message: Logged In: YES user_id=21784 Added test script config.py To run: "python config.py config" Also added msvccompiler.py which fixes a bug from my first post of pp.py, and is a modification of the current CVS version. Tarn ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-07-18 00:58 Message: Logged In: YES user_id=11105 Tarn, can you supply an example where this code would be executed? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 06:40 Message: Logged In: YES user_id=11375 Reassigning to Thomas, since I can't test anything with MSVC. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-16 06:23 Message: Logged In: YES user_id=6380 Or should this go to Thomas Heller? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 From noreply@sourceforge.net Fri Aug 17 06:23:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 22:23:39 -0700 Subject: [Patches] [ python-Patches-450710 ] 2.2a1 Bug fixes and UnixWare 7 port Message-ID: Patches item #450710, was opened at 2001-08-13 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 Category: Build Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1 Bug fixes and UnixWare 7 port Initial Comment: The attached patches fixes the followin problems and updates the UnixWare 7.0 port as follows: Problems: --------- 1. The code to build the readline module in setup.py did not work if the termcap library did not exist in /usr/lib/termcap. It will now search for the curses libarary or the termcap library and used the first one found. 2. The code in distutils/ccompiler.py makes an invalid assumption about the runtime libraries -- it assumes that each runtime library generates a seperate command line arguement, the same as the library_dirs element does. That choice is best made by the particular compiler implementation. The changed code now passes the entire list to runtime_library_dir_option(), where the decision of how to process the list is best made. 3. The code for runtime_library_dir_option() in distutils/unixccompiler.py was changed to accept a list of directories instead of a string. It now returns a single option string in the form '-Rdir1:dir2:dir2...' instead of multiple options (i.e. '-Rdir1 -Rdir2 -Rdir3 ...'). 4. In the socket module, accept() would return an error if the accept() call was interrupted. The code was changed so that the accept call is made again if the accept() failed because it was interrupted. UnixWare 7 specific changes: ---------------------------- 1. LD_RUN_PATH no longer needs to be set. -R is used supply the executable and dynamically loaded modules with the runtime directory search path. Both configure.in and setup.py now set the appropiate -R options when building. 2. -Kpthread is used instead of -Kthread. 3. Code was added to work around two know bugs in SCO UnixWare 7: a) A bug in accept() does not set the sa_family value correctly for the AF_UNIX family. b) atan2() does returns pi instead of zero for atan2(0, x). This code is enabled by defining SCO_ACCEPT_BUG and SCO_ATAN2_BUG. 4. The python library is still built as a shared library. When building on UnixWare, it now only necessary to add a period (.) to the LD_LIBRARY_PATH environment variable. This is only necessary when building Python so that the shared library (libpythonX.Y.so) is found during the './python setup.py build' phase. Once python is installed, it does not require LD_RUN_PATH or LD_LIBRARY_PATH to be set. NOTE: If item #2 and #3 in the Problems section are not implemented, do not apply the any of UnixWare specific changes in setup.py as those change depend on the changes to ccompiler.py and unixccompiler.py. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:23 Message: Logged In: YES user_id=8500 The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use ===== the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-14 09:43 Message: Logged In: YES user_id=8500 I will obtain the latest CVS files and re-make the patches. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:15 Message: Logged In: YES user_id=21627 Both the configure.in and the mathmodule patch fail to apply, since the code has significantly changed since 2.2a1. In particular, libpython is not build as a shared library anymore on Unixware, so the addition of -R does not apply anymore. Of the remaining changes, I think the setup.py changes that specifically mention unixware7 should not be applied. Instead, it should be researched whether there is a larger class of operating systems that could make use of such changes. Please indicate whether you want to provide an updated patch. If so, I'd strongly advise to have it operate against the current CVS; waiting for 2.2a2 might result in the patch not being available early enough before the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 From noreply@sourceforge.net Fri Aug 17 06:33:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 22:33:44 -0700 Subject: [Patches] [ python-Patches-450710 ] 2.2a1 Bug fixes and UnixWare 7 port Message-ID: Patches item #450710, was opened at 2001-08-13 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 Category: Build Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1 Bug fixes and UnixWare 7 port Initial Comment: The attached patches fixes the followin problems and updates the UnixWare 7.0 port as follows: Problems: --------- 1. The code to build the readline module in setup.py did not work if the termcap library did not exist in /usr/lib/termcap. It will now search for the curses libarary or the termcap library and used the first one found. 2. The code in distutils/ccompiler.py makes an invalid assumption about the runtime libraries -- it assumes that each runtime library generates a seperate command line arguement, the same as the library_dirs element does. That choice is best made by the particular compiler implementation. The changed code now passes the entire list to runtime_library_dir_option(), where the decision of how to process the list is best made. 3. The code for runtime_library_dir_option() in distutils/unixccompiler.py was changed to accept a list of directories instead of a string. It now returns a single option string in the form '-Rdir1:dir2:dir2...' instead of multiple options (i.e. '-Rdir1 -Rdir2 -Rdir3 ...'). 4. In the socket module, accept() would return an error if the accept() call was interrupted. The code was changed so that the accept call is made again if the accept() failed because it was interrupted. UnixWare 7 specific changes: ---------------------------- 1. LD_RUN_PATH no longer needs to be set. -R is used supply the executable and dynamically loaded modules with the runtime directory search path. Both configure.in and setup.py now set the appropiate -R options when building. 2. -Kpthread is used instead of -Kthread. 3. Code was added to work around two know bugs in SCO UnixWare 7: a) A bug in accept() does not set the sa_family value correctly for the AF_UNIX family. b) atan2() does returns pi instead of zero for atan2(0, x). This code is enabled by defining SCO_ACCEPT_BUG and SCO_ATAN2_BUG. 4. The python library is still built as a shared library. When building on UnixWare, it now only necessary to add a period (.) to the LD_LIBRARY_PATH environment variable. This is only necessary when building Python so that the shared library (libpythonX.Y.so) is found during the './python setup.py build' phase. Once python is installed, it does not require LD_RUN_PATH or LD_LIBRARY_PATH to be set. NOTE: If item #2 and #3 in the Problems section are not implemented, do not apply the any of UnixWare specific changes in setup.py as those change depend on the changes to ccompiler.py and unixccompiler.py. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:33 Message: Logged In: YES user_id=8500 Here is my last note reformtted to a line length of 60. The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:23 Message: Logged In: YES user_id=8500 The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use ===== the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-14 09:43 Message: Logged In: YES user_id=8500 I will obtain the latest CVS files and re-make the patches. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:15 Message: Logged In: YES user_id=21627 Both the configure.in and the mathmodule patch fail to apply, since the code has significantly changed since 2.2a1. In particular, libpython is not build as a shared library anymore on Unixware, so the addition of -R does not apply anymore. Of the remaining changes, I think the setup.py changes that specifically mention unixware7 should not be applied. Instead, it should be researched whether there is a larger class of operating systems that could make use of such changes. Please indicate whether you want to provide an updated patch. If so, I'd strongly advise to have it operate against the current CVS; waiting for 2.2a2 might result in the patch not being available early enough before the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 From noreply@sourceforge.net Fri Aug 17 06:34:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 Aug 2001 22:34:39 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Tim Peters (tim_one) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-16 22:34 Message: Logged In: YES user_id=31435 This is looking good! I think I know how to get doctest to use it too (to emulate the future settings of the doctest'ed module) -- which would remove an unpleasant wart in current CVS (doctest imports generators from __future__ now, despite that it doesn't use any generators; else test_generators.py would fail). Leaving assigned to me since Michael's on vacation now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-14 14:27 Message: Logged In: YES user_id=6656 I think this latest version actually compiles (ahem). As far as I'm concerned, the coding is now done. Also attach a first cut at some doc updates. Fred will definitely need to fiddle these to get them to compile (there's no latex here on the starship). I should probably do some test cases.. later. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-10 15:41 Message: Logged In: YES user_id=6656 Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly). No rest for the wicked: more docs and some tests still needed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Fri Aug 17 10:10:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 02:10:38 -0700 Subject: [Patches] [ python-Patches-450710 ] 2.2a1 Bug fixes and UnixWare 7 port Message-ID: Patches item #450710, was opened at 2001-08-13 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 Category: Build Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1 Bug fixes and UnixWare 7 port Initial Comment: The attached patches fixes the followin problems and updates the UnixWare 7.0 port as follows: Problems: --------- 1. The code to build the readline module in setup.py did not work if the termcap library did not exist in /usr/lib/termcap. It will now search for the curses libarary or the termcap library and used the first one found. 2. The code in distutils/ccompiler.py makes an invalid assumption about the runtime libraries -- it assumes that each runtime library generates a seperate command line arguement, the same as the library_dirs element does. That choice is best made by the particular compiler implementation. The changed code now passes the entire list to runtime_library_dir_option(), where the decision of how to process the list is best made. 3. The code for runtime_library_dir_option() in distutils/unixccompiler.py was changed to accept a list of directories instead of a string. It now returns a single option string in the form '-Rdir1:dir2:dir2...' instead of multiple options (i.e. '-Rdir1 -Rdir2 -Rdir3 ...'). 4. In the socket module, accept() would return an error if the accept() call was interrupted. The code was changed so that the accept call is made again if the accept() failed because it was interrupted. UnixWare 7 specific changes: ---------------------------- 1. LD_RUN_PATH no longer needs to be set. -R is used supply the executable and dynamically loaded modules with the runtime directory search path. Both configure.in and setup.py now set the appropiate -R options when building. 2. -Kpthread is used instead of -Kthread. 3. Code was added to work around two know bugs in SCO UnixWare 7: a) A bug in accept() does not set the sa_family value correctly for the AF_UNIX family. b) atan2() does returns pi instead of zero for atan2(0, x). This code is enabled by defining SCO_ACCEPT_BUG and SCO_ATAN2_BUG. 4. The python library is still built as a shared library. When building on UnixWare, it now only necessary to add a period (.) to the LD_LIBRARY_PATH environment variable. This is only necessary when building Python so that the shared library (libpythonX.Y.so) is found during the './python setup.py build' phase. Once python is installed, it does not require LD_RUN_PATH or LD_LIBRARY_PATH to be set. NOTE: If item #2 and #3 in the Problems section are not implemented, do not apply the any of UnixWare specific changes in setup.py as those change depend on the changes to ccompiler.py and unixccompiler.py. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 02:10 Message: Logged In: YES user_id=21627 Where is the patch (uw7-20011018.patch)? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:33 Message: Logged In: YES user_id=8500 Here is my last note reformtted to a line length of 60. The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:23 Message: Logged In: YES user_id=8500 The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use ===== the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-14 09:43 Message: Logged In: YES user_id=8500 I will obtain the latest CVS files and re-make the patches. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:15 Message: Logged In: YES user_id=21627 Both the configure.in and the mathmodule patch fail to apply, since the code has significantly changed since 2.2a1. In particular, libpython is not build as a shared library anymore on Unixware, so the addition of -R does not apply anymore. Of the remaining changes, I think the setup.py changes that specifically mention unixware7 should not be applied. Instead, it should be researched whether there is a larger class of operating systems that could make use of such changes. Please indicate whether you want to provide an updated patch. If so, I'd strongly advise to have it operate against the current CVS; waiting for 2.2a2 might result in the patch not being available early enough before the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 From noreply@sourceforge.net Fri Aug 17 11:59:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 03:59:59 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Tim Peters (tim_one) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 03:59 Message: Logged In: YES user_id=6380 What's stopping this from being checked in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-16 22:34 Message: Logged In: YES user_id=31435 This is looking good! I think I know how to get doctest to use it too (to emulate the future settings of the doctest'ed module) -- which would remove an unpleasant wart in current CVS (doctest imports generators from __future__ now, despite that it doesn't use any generators; else test_generators.py would fail). Leaving assigned to me since Michael's on vacation now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-14 14:27 Message: Logged In: YES user_id=6656 I think this latest version actually compiles (ahem). As far as I'm concerned, the coding is now done. Also attach a first cut at some doc updates. Fred will definitely need to fiddle these to get them to compile (there's no latex here on the starship). I should probably do some test cases.. later. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-10 15:41 Message: Logged In: YES user_id=6656 Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly). No rest for the wicked: more docs and some tests still needed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Fri Aug 17 16:10:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 08:10:02 -0700 Subject: [Patches] [ python-Patches-452110 ] socketmodule ssl: server & thread Message-ID: Patches item #452110, was opened at 2001-08-17 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jozef Hatala (jhatala) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule ssl: server & thread Initial Comment: Simple enhancement to the SSL support in module socket : - support for writing SSL servers (as well as clients) - Py_*_ALLOW_THREADS arround blocking calls to openssl - rsa temp key to work with older export netscape - renamed attribute server to peer This patch allows for powerfull application servers like the following one to be accessed with "netscape https://localhost:1443/" from socket import * p=socket(AF_INET,SOCK_STREAM) p.bind(('localhost',1443)) p.listen(1) while 1 : s,a = p.accept() c = sslserver(s,'server.key','server.crt') print "They said:", c.read() c.write('HTTP/1.0 200 OK\r\n') c.write('Content-Type: text/plain\r\n\r\n** Hi! **') c.close() TODO: a kind of makefile() on the ssl object like on a socket would be welcome. Have fun, jh ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 From noreply@sourceforge.net Fri Aug 17 16:35:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 08:35:57 -0700 Subject: [Patches] [ python-Patches-450710 ] 2.2a1 Bug fixes and UnixWare 7 port Message-ID: Patches item #450710, was opened at 2001-08-13 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 Category: Build Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1 Bug fixes and UnixWare 7 port Initial Comment: The attached patches fixes the followin problems and updates the UnixWare 7.0 port as follows: Problems: --------- 1. The code to build the readline module in setup.py did not work if the termcap library did not exist in /usr/lib/termcap. It will now search for the curses libarary or the termcap library and used the first one found. 2. The code in distutils/ccompiler.py makes an invalid assumption about the runtime libraries -- it assumes that each runtime library generates a seperate command line arguement, the same as the library_dirs element does. That choice is best made by the particular compiler implementation. The changed code now passes the entire list to runtime_library_dir_option(), where the decision of how to process the list is best made. 3. The code for runtime_library_dir_option() in distutils/unixccompiler.py was changed to accept a list of directories instead of a string. It now returns a single option string in the form '-Rdir1:dir2:dir2...' instead of multiple options (i.e. '-Rdir1 -Rdir2 -Rdir3 ...'). 4. In the socket module, accept() would return an error if the accept() call was interrupted. The code was changed so that the accept call is made again if the accept() failed because it was interrupted. UnixWare 7 specific changes: ---------------------------- 1. LD_RUN_PATH no longer needs to be set. -R is used supply the executable and dynamically loaded modules with the runtime directory search path. Both configure.in and setup.py now set the appropiate -R options when building. 2. -Kpthread is used instead of -Kthread. 3. Code was added to work around two know bugs in SCO UnixWare 7: a) A bug in accept() does not set the sa_family value correctly for the AF_UNIX family. b) atan2() does returns pi instead of zero for atan2(0, x). This code is enabled by defining SCO_ACCEPT_BUG and SCO_ATAN2_BUG. 4. The python library is still built as a shared library. When building on UnixWare, it now only necessary to add a period (.) to the LD_LIBRARY_PATH environment variable. This is only necessary when building Python so that the shared library (libpythonX.Y.so) is found during the './python setup.py build' phase. Once python is installed, it does not require LD_RUN_PATH or LD_LIBRARY_PATH to be set. NOTE: If item #2 and #3 in the Problems section are not implemented, do not apply the any of UnixWare specific changes in setup.py as those change depend on the changes to ccompiler.py and unixccompiler.py. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 08:35 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 02:10 Message: Logged In: YES user_id=21627 Where is the patch (uw7-20011018.patch)? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:33 Message: Logged In: YES user_id=8500 Here is my last note reformtted to a line length of 60. The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:23 Message: Logged In: YES user_id=8500 The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use ===== the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-14 09:43 Message: Logged In: YES user_id=8500 I will obtain the latest CVS files and re-make the patches. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:15 Message: Logged In: YES user_id=21627 Both the configure.in and the mathmodule patch fail to apply, since the code has significantly changed since 2.2a1. In particular, libpython is not build as a shared library anymore on Unixware, so the addition of -R does not apply anymore. Of the remaining changes, I think the setup.py changes that specifically mention unixware7 should not be applied. Instead, it should be researched whether there is a larger class of operating systems that could make use of such changes. Please indicate whether you want to provide an updated patch. If so, I'd strongly advise to have it operate against the current CVS; waiting for 2.2a2 might result in the patch not being available early enough before the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 From noreply@sourceforge.net Fri Aug 17 18:10:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 10:10:30 -0700 Subject: [Patches] [ python-Patches-450702 ] zlibmodule ALLOW_THREADS update Message-ID: Patches item #450702, was opened at 2001-08-13 22:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: zlibmodule ALLOW_THREADS update Initial Comment: When using e.g. the gzip module in a threaded Python embedding (PyWX, pywx.idyll.org) all other Python threads halt, because no thread interleaving is done by the time-intensive commands in zlib.so. This leads to serious lags when compressing 5 MB files... I have wrapped all of the inflate and deflate commands in Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, which fixes this problem. Note that this fix is backwards compatible to 2.1, at least, as zlibmodule.c has not changed since then. As requested, a _context_ diff from the head of the current CVS tree is attached ;). ---------------------------------------------------------------------- >Comment By: Titus Brown (titus) Date: 2001-08-17 10:10 Message: Logged In: YES user_id=23486 This new patch makes the zlibmodule reentrant by using a global zlib_lock. Also included is the addition of BEGIN/END_ALLOW_THREADS macros around the actual calls to compress/decompress data, which significantly improves the thread-friendliness of this module. Most of the code changes are simple rearrangements of the same old code to adapt it to the requirements of the ENTER and LEAVE_ZLIB macros, which create new blocks; thus, any code from which a 'return' was done had to be changed to exit only after LEAVE_ZLIB was called. Note that because zlib itself is re-entrant, we really only had to worry about making methods on de/compress objects reentrant. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 12:13 Message: Logged In: YES user_id=23486 N.B. I've found that zlib _is_ threadsafe. I still need to determine if the way in which objects are passed around in the zlibmodule.c can potentially cause problems; it seems like it can. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 09:06 Message: Logged In: YES user_id=23486 I think there may be a 2nd problem: I have to look into some of the Python calls used to transfer data around, but it may be possible for threads with access to the compression objects to retrieve data in an indeterminate state, i.e. mid-compression. Luckily a module-wide lock should take care of both this problem AND resolve threadsafety issues with zlib! I'll look into this & fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:21 Message: Logged In: YES user_id=21627 The patch looks good, however there is a major problem with the approach taken: zlib itself might not be threadsafe. Please try to find out whether zlib indeed is thread-safe; if it isn't, I think you need to add another lock to prevent multiple Python threads from accessing zlib simultaneously. You may want to take a look at _tkinter, which has similar code to prevent multiple Python threads from accessing Tk simultaneously. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 From noreply@sourceforge.net Fri Aug 17 18:17:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 10:17:33 -0700 Subject: [Patches] [ python-Patches-450710 ] 2.2a1 Bug fixes and UnixWare 7 port Message-ID: Patches item #450710, was opened at 2001-08-13 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 Category: Build Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1 Bug fixes and UnixWare 7 port Initial Comment: The attached patches fixes the followin problems and updates the UnixWare 7.0 port as follows: Problems: --------- 1. The code to build the readline module in setup.py did not work if the termcap library did not exist in /usr/lib/termcap. It will now search for the curses libarary or the termcap library and used the first one found. 2. The code in distutils/ccompiler.py makes an invalid assumption about the runtime libraries -- it assumes that each runtime library generates a seperate command line arguement, the same as the library_dirs element does. That choice is best made by the particular compiler implementation. The changed code now passes the entire list to runtime_library_dir_option(), where the decision of how to process the list is best made. 3. The code for runtime_library_dir_option() in distutils/unixccompiler.py was changed to accept a list of directories instead of a string. It now returns a single option string in the form '-Rdir1:dir2:dir2...' instead of multiple options (i.e. '-Rdir1 -Rdir2 -Rdir3 ...'). 4. In the socket module, accept() would return an error if the accept() call was interrupted. The code was changed so that the accept call is made again if the accept() failed because it was interrupted. UnixWare 7 specific changes: ---------------------------- 1. LD_RUN_PATH no longer needs to be set. -R is used supply the executable and dynamically loaded modules with the runtime directory search path. Both configure.in and setup.py now set the appropiate -R options when building. 2. -Kpthread is used instead of -Kthread. 3. Code was added to work around two know bugs in SCO UnixWare 7: a) A bug in accept() does not set the sa_family value correctly for the AF_UNIX family. b) atan2() does returns pi instead of zero for atan2(0, x). This code is enabled by defining SCO_ACCEPT_BUG and SCO_ATAN2_BUG. 4. The python library is still built as a shared library. When building on UnixWare, it now only necessary to add a period (.) to the LD_LIBRARY_PATH environment variable. This is only necessary when building Python so that the shared library (libpythonX.Y.so) is found during the './python setup.py build' phase. Once python is installed, it does not require LD_RUN_PATH or LD_LIBRARY_PATH to be set. NOTE: If item #2 and #3 in the Problems section are not implemented, do not apply the any of UnixWare specific changes in setup.py as those change depend on the changes to ccompiler.py and unixccompiler.py. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 10:17 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 08:35 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 02:10 Message: Logged In: YES user_id=21627 Where is the patch (uw7-20011018.patch)? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:33 Message: Logged In: YES user_id=8500 Here is my last note reformtted to a line length of 60. The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:23 Message: Logged In: YES user_id=8500 The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use ===== the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-14 09:43 Message: Logged In: YES user_id=8500 I will obtain the latest CVS files and re-make the patches. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:15 Message: Logged In: YES user_id=21627 Both the configure.in and the mathmodule patch fail to apply, since the code has significantly changed since 2.2a1. In particular, libpython is not build as a shared library anymore on Unixware, so the addition of -R does not apply anymore. Of the remaining changes, I think the setup.py changes that specifically mention unixware7 should not be applied. Instead, it should be researched whether there is a larger class of operating systems that could make use of such changes. Please indicate whether you want to provide an updated patch. If so, I'd strongly advise to have it operate against the current CVS; waiting for 2.2a2 might result in the patch not being available early enough before the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 From noreply@sourceforge.net Fri Aug 17 19:20:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 11:20:10 -0700 Subject: [Patches] [ python-Patches-452174 ] cgi: new methods: getfirst(), getlist() Message-ID: Patches item #452174, was opened at 2001-08-17 11:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: cgi: new methods: getfirst(), getlist() Initial Comment: I find very annoying the need to check whether a user checked one or more checkboxes in a form like this: Currently, I must do something like this: value = form.getvalue("item") if type(value) is type([]): # Multiple items checked. else: # One item checked. I added two methods to cgi.py that simplify and make CGI value processing much more readable and intuitive. The first method ALWAYS returns a single value. Even if more values of the same name were posted, this method always returns only the first one, as a string. scalar_value = form.getfirst("item") scalar_value is now: '1' The second method ALWAYS returns a list. If only one value was posted then the method returns a list which contains this one value. list_values = form.getlist("item") list_values is now: ['1', '2'] This allows me to write much more compact code like: for item in form.getlist("item"): do_something() Using the getfirst() method I don't need to worry about a malicious user posting two values in a query string where I expect only one value. Documentation says: "If the submitted form data contains more than one field with the same name, the object retrieved by "form[key]" is not a FieldStorage or MiniFieldStorage instance but a list of such instances. Similarly, in this situation, "form.getvalue(key)" would return a list of strings. If you expect this possibility (i.e., when your HTML form contains multiple fields with the same name), use the type() function to determine whether you have a single instance or a list of instances." That's IMHO wrong - one shouldn't count on a client to provide valid input. If it doesn't, the script crashes. That's bad. So I added these two very simple methods to the FieldStorage class. The patch is against version 2.6 of the cgi.py module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 From noreply@sourceforge.net Fri Aug 17 19:28:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 11:28:32 -0700 Subject: [Patches] [ python-Patches-452174 ] cgi: new methods: getfirst(), getlist() Message-ID: Patches item #452174, was opened at 2001-08-17 11:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: cgi: new methods: getfirst(), getlist() Initial Comment: I find very annoying the need to check whether a user checked one or more checkboxes in a form like this: Currently, I must do something like this: value = form.getvalue("item") if type(value) is type([]): # Multiple items checked. else: # One item checked. I added two methods to cgi.py that simplify and make CGI value processing much more readable and intuitive. The first method ALWAYS returns a single value. Even if more values of the same name were posted, this method always returns only the first one, as a string. scalar_value = form.getfirst("item") scalar_value is now: '1' The second method ALWAYS returns a list. If only one value was posted then the method returns a list which contains this one value. list_values = form.getlist("item") list_values is now: ['1', '2'] This allows me to write much more compact code like: for item in form.getlist("item"): do_something() Using the getfirst() method I don't need to worry about a malicious user posting two values in a query string where I expect only one value. Documentation says: "If the submitted form data contains more than one field with the same name, the object retrieved by "form[key]" is not a FieldStorage or MiniFieldStorage instance but a list of such instances. Similarly, in this situation, "form.getvalue(key)" would return a list of strings. If you expect this possibility (i.e., when your HTML form contains multiple fields with the same name), use the type() function to determine whether you have a single instance or a list of instances." That's IMHO wrong - one shouldn't count on a client to provide valid input. If it doesn't, the script crashes. That's bad. So I added these two very simple methods to the FieldStorage class. The patch is against version 2.6 of the cgi.py module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 11:28 Message: Logged In: YES user_id=6380 Nice idea, but I wouldn't use "default=[]" in the argument list. If the user modifies the list it returns, the default is permanently changed! I suggest that there's no need to allow the user to specify an alternate default for getlist(), so you can just delete this argument and say "return []" in the default case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 From noreply@sourceforge.net Fri Aug 17 19:30:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 11:30:07 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Tim Peters (tim_one) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-17 11:30 Message: Logged In: YES user_id=31435 Testing turned up bugs, and I'm fixing them. Gross example: the anonymous hex constant attached to nested_scopes in the patched __future__.py was actually the constant for the CO_GENERATOR flag, not the constant for the correct CO_NESTED flag. I've reworked the code to repair that, but also to make it harder for that to happen again; ideally, Python-level CO_xxx flags should be exported by a builtin C module, and so that Jeremy's pyassem.py can use them too (it's got its own hardcoded (re) definitions), but I'm not being that ambitious. The simplest thing that could possibly work is that a global search on, e.g., CO_NESTED, find its use and value in __future__.py too, so that's what I'm settling for. I'll check it in when it all works. That won't be this instant, but will certainly be today. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 03:59 Message: Logged In: YES user_id=6380 What's stopping this from being checked in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-16 22:34 Message: Logged In: YES user_id=31435 This is looking good! I think I know how to get doctest to use it too (to emulate the future settings of the doctest'ed module) -- which would remove an unpleasant wart in current CVS (doctest imports generators from __future__ now, despite that it doesn't use any generators; else test_generators.py would fail). Leaving assigned to me since Michael's on vacation now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-14 14:27 Message: Logged In: YES user_id=6656 I think this latest version actually compiles (ahem). As far as I'm concerned, the coding is now done. Also attach a first cut at some doc updates. Fred will definitely need to fiddle these to get them to compile (there's no latex here on the starship). I should probably do some test cases.. later. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-10 15:41 Message: Logged In: YES user_id=6656 Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly). No rest for the wicked: more docs and some tests still needed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Fri Aug 17 19:44:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 11:44:34 -0700 Subject: [Patches] [ python-Patches-445762 ] Support --disable-unicode Message-ID: Patches item #445762, was opened at 2001-07-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support --disable-unicode Initial Comment: This patch implements the option --disable-unicode. In particular, it: - does not compile unicodeobject, unicodectype, _codecsmodule, and unicodedata if Unicode is disabled - checks for Py_Unicode in all places that use Unicode functions - disables unicode literals, the builtin functions, and the string encode and decode methods, - avoids Unicode literals in a few places in the libraries - adds the types.StringTypes list Most of the test suite passes with these changes. A number of tests fail, mostly because they use Unicode literals. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 11:44 Message: Logged In: YES user_id=21627 Committed as Makefile.pre.in:1.53 configure:1.240 configure.in:1.248 setup.py:1.50 Include/intobject.h:2.22 Include/longobject.h:2.21 Include/object.h:2.86 Include/unicodeobject.h:2.31 Lib/ConfigParser.py:1.36 Lib/copy.py:1.20 Lib/site.py:1.35 Lib/types.py:1.20 Lib/test/pickletester.py:1.7 Lib/test/string_tests.py:1.10 Lib/test/test_b1.py:1.38 Lib/test/test_contains.py:1.8 Lib/test/test_format.py:1.12 Lib/test/test_iter.py:1.18 Lib/test/test_pprint.py:1.5 Lib/test/test_sre.py:1.27 Lib/test/test_support.py:1.25 Lib/test/test_winreg.py:1.10 Misc/NEWS:1.207 Modules/_codecsmodule.c:2.9 Modules/_sre.c:2.63 Modules/_tkinter.c:1.119 Modules/cPickle.c:2.62 Modules/pyexpat.c:2.48 Objects/abstract.c:2.72 Objects/complexobject.c:2.39 Objects/floatobject.c:2.86 Objects/intobject.c:2.62 Objects/longobject.c:1.92 Objects/object.c:2.139 Objects/stringobject.c:2.124 Python/bltinmodule.c:2.227 Python/compile.c:2.218 Python/getargs.c:2.62 Python/marshal.c:1.65 Python/modsupport.c:2.58 Python/pythonrun.c:2.147 Python/sysmodule.c:2.92 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-03 00:45 Message: Logged In: YES user_id=21627 I've added an additional test.patch file, which only records the changes to Lib/test. With this patch, I get the following failures: test_grammar test___all__ test_charmapcodec test_codecs test_gettext test_minidom test_pyexpat test_sax test_string test_ucn test_unicode test_unicodedata test_urllib test_zipfile1 I don't think this list cannot be reduced much further without seriously impacting the strength of the test suite. To reduce the number of failures to this list, I also had to modify pickle.py to not use Unicode literals anymore. I'm not sure whether this is a good idea, as it impacts performance; the pickle.patch is attached separately. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-02 09:29 Message: Logged In: YES user_id=38388 Uploaded a revised patch. The test suite still fails -- it would be nice if you could work this out; I don't want to check the patch in before the test suite runs through without failures. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-01 23:09 Message: Logged In: YES user_id=21627 Updated patch after merger with descr_branch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:56 Message: Logged In: YES user_id=21627 Replaced patch, since it contained unrelated fragments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:48 Message: Logged In: YES user_id=21627 The new version of the patch implements all features that have been discussed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 07:39 Message: Logged In: YES user_id=38388 Ok, I see your point about the API references. About the PyString_Encode/Decode: on platforms without Unicode, the encoding should not have a default, so passing NULL as encoding should result in an error. I am not even sure, whether it should have a default on Unicode builds... probably not. Trimming down the _codecmodule.c to register and lookup is OK; there are a few codecs in 2.2 which don't use Unicode at all. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 07:30 Message: Logged In: YES user_id=21627 This patch already makes use of the assumption that PyUnicode_Check will always return 0. In all the remaining cases, the code will also call some function of the Unicode module, which will result in a compile time error since the functions are not declared anymore. Even if it was declared, it would probably result in a linker error since not all compilers will remove the entire code block. Only in cases where the if-block does not call any Unicode functions directly, that approach can be used. I can try to re-enable the _codecs module, although only register and lookup would remain. I cannot re-enable PyString_Decode/Encode, since they use PyUnicode_GetDefaultEncoding, which is not available since unicodeobject.c is not compiled. I will try to have the tokenizer generate more specific error messages. Support for "es", "et" is still there; they only work for strings, though, and they never call any codecs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 06:06 Message: Logged In: YES user_id=38388 Nice work, Martin ! Some comments: - I think that we could save some of the #ifdefs by simply assuming that an optimizing will not generate code for "if (0)" == "if (PyUnicode_Check(obj))"; this would make the code more readable - the _codecmodule.c should not be disabled by the configure option... codecs are useful for non-Unicode applications as well - the PyString_Encode/Decode() APIs should not be disabled for the same reason - the tokenizer/compiler should generate errors with an explicit message stating that the Python version was compiled without Unicode support - dito for the Unicode parser markers (I think that open() on Windows will fail without "es"... ?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 From noreply@sourceforge.net Fri Aug 17 20:17:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 12:17:49 -0700 Subject: [Patches] [ python-Patches-450710 ] 2.2a1 Bug fixes and UnixWare 7 port Message-ID: Patches item #450710, was opened at 2001-08-13 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 Category: Build Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1 Bug fixes and UnixWare 7 port Initial Comment: The attached patches fixes the followin problems and updates the UnixWare 7.0 port as follows: Problems: --------- 1. The code to build the readline module in setup.py did not work if the termcap library did not exist in /usr/lib/termcap. It will now search for the curses libarary or the termcap library and used the first one found. 2. The code in distutils/ccompiler.py makes an invalid assumption about the runtime libraries -- it assumes that each runtime library generates a seperate command line arguement, the same as the library_dirs element does. That choice is best made by the particular compiler implementation. The changed code now passes the entire list to runtime_library_dir_option(), where the decision of how to process the list is best made. 3. The code for runtime_library_dir_option() in distutils/unixccompiler.py was changed to accept a list of directories instead of a string. It now returns a single option string in the form '-Rdir1:dir2:dir2...' instead of multiple options (i.e. '-Rdir1 -Rdir2 -Rdir3 ...'). 4. In the socket module, accept() would return an error if the accept() call was interrupted. The code was changed so that the accept call is made again if the accept() failed because it was interrupted. UnixWare 7 specific changes: ---------------------------- 1. LD_RUN_PATH no longer needs to be set. -R is used supply the executable and dynamically loaded modules with the runtime directory search path. Both configure.in and setup.py now set the appropiate -R options when building. 2. -Kpthread is used instead of -Kthread. 3. Code was added to work around two know bugs in SCO UnixWare 7: a) A bug in accept() does not set the sa_family value correctly for the AF_UNIX family. b) atan2() does returns pi instead of zero for atan2(0, x). This code is enabled by defining SCO_ACCEPT_BUG and SCO_ATAN2_BUG. 4. The python library is still built as a shared library. When building on UnixWare, it now only necessary to add a period (.) to the LD_LIBRARY_PATH environment variable. This is only necessary when building Python so that the shared library (libpythonX.Y.so) is found during the './python setup.py build' phase. Once python is installed, it does not require LD_RUN_PATH or LD_LIBRARY_PATH to be set. NOTE: If item #2 and #3 in the Problems section are not implemented, do not apply the any of UnixWare specific changes in setup.py as those change depend on the changes to ccompiler.py and unixccompiler.py. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 12:17 Message: Logged In: YES user_id=8500 Here is the file. I've added two more patches then those listed in my previous note: 1. Added a missing argument to the definition of readfp() in Lib/mimetypes.py 2. Added a list of expected skipped tests for UnixWare to Lib/test/regrtest.py. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 10:17 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 08:35 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 02:10 Message: Logged In: YES user_id=21627 Where is the patch (uw7-20011018.patch)? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:33 Message: Logged In: YES user_id=8500 Here is my last note reformtted to a line length of 60. The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:23 Message: Logged In: YES user_id=8500 The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use ===== the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-14 09:43 Message: Logged In: YES user_id=8500 I will obtain the latest CVS files and re-make the patches. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:15 Message: Logged In: YES user_id=21627 Both the configure.in and the mathmodule patch fail to apply, since the code has significantly changed since 2.2a1. In particular, libpython is not build as a shared library anymore on Unixware, so the addition of -R does not apply anymore. Of the remaining changes, I think the setup.py changes that specifically mention unixware7 should not be applied. Instead, it should be researched whether there is a larger class of operating systems that could make use of such changes. Please indicate whether you want to provide an updated patch. If so, I'd strongly advise to have it operate against the current CVS; waiting for 2.2a2 might result in the patch not being available early enough before the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 From noreply@sourceforge.net Fri Aug 17 20:51:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 12:51:11 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Tim Peters (tim_one) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-17 12:51 Message: Logged In: YES user_id=31435 I'm going to do this in pieces. First checked in a reworked version of __future__.py, and added verification to test___future__.py: Lib/__future__.py; new revision: 1.9 Lib/test/test___future__.py; new revision: 1.3 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 11:30 Message: Logged In: YES user_id=31435 Testing turned up bugs, and I'm fixing them. Gross example: the anonymous hex constant attached to nested_scopes in the patched __future__.py was actually the constant for the CO_GENERATOR flag, not the constant for the correct CO_NESTED flag. I've reworked the code to repair that, but also to make it harder for that to happen again; ideally, Python-level CO_xxx flags should be exported by a builtin C module, and so that Jeremy's pyassem.py can use them too (it's got its own hardcoded (re) definitions), but I'm not being that ambitious. The simplest thing that could possibly work is that a global search on, e.g., CO_NESTED, find its use and value in __future__.py too, so that's what I'm settling for. I'll check it in when it all works. That won't be this instant, but will certainly be today. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 03:59 Message: Logged In: YES user_id=6380 What's stopping this from being checked in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-16 22:34 Message: Logged In: YES user_id=31435 This is looking good! I think I know how to get doctest to use it too (to emulate the future settings of the doctest'ed module) -- which would remove an unpleasant wart in current CVS (doctest imports generators from __future__ now, despite that it doesn't use any generators; else test_generators.py would fail). Leaving assigned to me since Michael's on vacation now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-14 14:27 Message: Logged In: YES user_id=6656 I think this latest version actually compiles (ahem). As far as I'm concerned, the coding is now done. Also attach a first cut at some doc updates. Fred will definitely need to fiddle these to get them to compile (there's no latex here on the starship). I should probably do some test cases.. later. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-10 15:41 Message: Logged In: YES user_id=6656 Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly). No rest for the wicked: more docs and some tests still needed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Fri Aug 17 22:12:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 14:12:23 -0700 Subject: [Patches] [ python-Patches-452219 ] timestamp function for time module Message-ID: Patches item #452219, was opened at 2001-08-17 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452219&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp function for time module Initial Comment: A timestamp function should be part of the time module. It is often needed outside of database or xml operations. This version provides both ISO and ODBC timestamps. It can use local or UTC timezones. Any improvement or standardization is welcome. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452219&group_id=5470 From noreply@sourceforge.net Fri Aug 17 22:16:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 14:16:16 -0700 Subject: [Patches] [ python-Patches-452219 ] timestamp function for time module Message-ID: Patches item #452219, was opened at 2001-08-17 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452219&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp function for time module Initial Comment: A timestamp function should be part of the time module. It is often needed outside of database or xml operations. This version provides both ISO and ODBC timestamps. It can use local or UTC timezones. Any improvement or standardization is welcome. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 14:16 Message: Logged In: YES user_id=6380 Dear Anonymous, please state your name :-) Please try the upload again -- the file attachment only works if you check the checkbox (and maybe only if you are registered / logged in). :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452219&group_id=5470 From noreply@sourceforge.net Fri Aug 17 22:30:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 14:30:32 -0700 Subject: [Patches] [ python-Patches-450710 ] 2.2a1 Bug fixes and UnixWare 7 port Message-ID: Patches item #450710, was opened at 2001-08-13 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 Category: Build Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1 Bug fixes and UnixWare 7 port Initial Comment: The attached patches fixes the followin problems and updates the UnixWare 7.0 port as follows: Problems: --------- 1. The code to build the readline module in setup.py did not work if the termcap library did not exist in /usr/lib/termcap. It will now search for the curses libarary or the termcap library and used the first one found. 2. The code in distutils/ccompiler.py makes an invalid assumption about the runtime libraries -- it assumes that each runtime library generates a seperate command line arguement, the same as the library_dirs element does. That choice is best made by the particular compiler implementation. The changed code now passes the entire list to runtime_library_dir_option(), where the decision of how to process the list is best made. 3. The code for runtime_library_dir_option() in distutils/unixccompiler.py was changed to accept a list of directories instead of a string. It now returns a single option string in the form '-Rdir1:dir2:dir2...' instead of multiple options (i.e. '-Rdir1 -Rdir2 -Rdir3 ...'). 4. In the socket module, accept() would return an error if the accept() call was interrupted. The code was changed so that the accept call is made again if the accept() failed because it was interrupted. UnixWare 7 specific changes: ---------------------------- 1. LD_RUN_PATH no longer needs to be set. -R is used supply the executable and dynamically loaded modules with the runtime directory search path. Both configure.in and setup.py now set the appropiate -R options when building. 2. -Kpthread is used instead of -Kthread. 3. Code was added to work around two know bugs in SCO UnixWare 7: a) A bug in accept() does not set the sa_family value correctly for the AF_UNIX family. b) atan2() does returns pi instead of zero for atan2(0, x). This code is enabled by defining SCO_ACCEPT_BUG and SCO_ATAN2_BUG. 4. The python library is still built as a shared library. When building on UnixWare, it now only necessary to add a period (.) to the LD_LIBRARY_PATH environment variable. This is only necessary when building Python so that the shared library (libpythonX.Y.so) is found during the './python setup.py build' phase. Once python is installed, it does not require LD_RUN_PATH or LD_LIBRARY_PATH to be set. NOTE: If item #2 and #3 in the Problems section are not implemented, do not apply the any of UnixWare specific changes in setup.py as those change depend on the changes to ccompiler.py and unixccompiler.py. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 14:30 Message: Logged In: YES user_id=21627 Overall, the patch looks fine to me. Unfortunately, I won't have the time to review it for the next two weeks. Some comments from a first glance: - it looks quite big, and appears to combine issues that are only related due to the fact that they all occur on UnixWare. I'd recommend to split them into smaller parts, unless somebody is willing to approve the entire patch as-is. For example, I wonder what the regrtest chunk does in here when the patch is titled "bug fixes". E.g. the bug fixing should go in one patch, the setup.py stuff in a second one, the USLCCompiler in a third one. - the mimetypes problem was fixed in 1.16 - Could you somehow put SCO_*_BUG into pyconfig.h, or perhaps even check the preprocessor inside the files that have the work-arounds? It only applies to a few files and clutters the command line. _SCO_VERSION or __USLC__ might be appropriate - unless you can come up with a test for the bug itself, rather than asking what operating system it is. - What is the rationale for the addrinfo.h chunk? If the system has getaddrinfo, we should not declare it. Also, the file seems to have changed since you made the patch. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 12:17 Message: Logged In: YES user_id=8500 Here is the file. I've added two more patches then those listed in my previous note: 1. Added a missing argument to the definition of readfp() in Lib/mimetypes.py 2. Added a list of expected skipped tests for UnixWare to Lib/test/regrtest.py. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 10:17 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 08:35 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 02:10 Message: Logged In: YES user_id=21627 Where is the patch (uw7-20011018.patch)? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:33 Message: Logged In: YES user_id=8500 Here is my last note reformtted to a line length of 60. The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:23 Message: Logged In: YES user_id=8500 The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use ===== the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-14 09:43 Message: Logged In: YES user_id=8500 I will obtain the latest CVS files and re-make the patches. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:15 Message: Logged In: YES user_id=21627 Both the configure.in and the mathmodule patch fail to apply, since the code has significantly changed since 2.2a1. In particular, libpython is not build as a shared library anymore on Unixware, so the addition of -R does not apply anymore. Of the remaining changes, I think the setup.py changes that specifically mention unixware7 should not be applied. Instead, it should be researched whether there is a larger class of operating systems that could make use of such changes. Please indicate whether you want to provide an updated patch. If so, I'd strongly advise to have it operate against the current CVS; waiting for 2.2a2 might result in the patch not being available early enough before the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 From noreply@sourceforge.net Fri Aug 17 22:37:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 14:37:38 -0700 Subject: [Patches] [ python-Patches-452232 ] timestamp function for time module Message-ID: Patches item #452232, was opened at 2001-08-17 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452232&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gareth Harris (garethharris) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp function for time module Initial Comment: Timestamp creates timestamp strings in ISO or ODBC format in UTC or local timezones. It can also add microseconds where needed. Timestamps are often needed outside database or XML activities, so its proposed location is the time module. timestamp(secs=None,fmt='ISO',TZ=None,fracsec=None): '''Make ISO or ODBC timestamp from [current] time. Parameters: secs= float seconds, else default = time() fmt = 'ISO' use ISO 8601 standard format = "YYYY-MM-DDTHH:MM:SS.mmmmmmZ" Zulu or "YYYY-MM-DDTHH:MM:SS.mmmmmm-hh:mm" local else "YYYY-MM-DD HH:MM:SS.mmmmmm" ODBC TZ = None=GMT/UTC/Zulu, else local time zone fracsec = None, else add microseconds to string ''' Any improvement or standardization is welcome. Gareth Harris gharris@nrao.edu 2001-08-17T21:36:00Z ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452232&group_id=5470 From noreply@sourceforge.net Fri Aug 17 22:42:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 14:42:33 -0700 Subject: [Patches] [ python-Patches-452219 ] timestamp function for time module Message-ID: Patches item #452219, was opened at 2001-08-17 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452219&group_id=5470 Category: Modules Group: None >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp function for time module Initial Comment: A timestamp function should be part of the time module. It is often needed outside of database or xml operations. This version provides both ISO and ODBC timestamps. It can use local or UTC timezones. Any improvement or standardization is welcome. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 14:42 Message: Logged In: YES user_id=6380 Deleted this; the uploaded patch is #452232. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 14:16 Message: Logged In: YES user_id=6380 Dear Anonymous, please state your name :-) Please try the upload again -- the file attachment only works if you check the checkbox (and maybe only if you are registered / logged in). :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452219&group_id=5470 From noreply@sourceforge.net Fri Aug 17 22:43:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 14:43:14 -0700 Subject: [Patches] [ python-Patches-452239 ] cPickle patch for bug 451547 Message-ID: Patches item #452239, was opened at 2001-08-17 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452239&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gordon B. McMillan (gmcm) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle patch for bug 451547 Initial Comment: This patch attempts to do to cPickle what Guido did for pickle.py v 1.50. That is: save_global tries importing the module, and fetching the name from the module. If that fails, or the returned object is not the same one we started with, it raises a PicklingError. (All this so pickling a lambda will fail at save time, rather than load time). Modules/cPickle.c is current CVS from view cvs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452239&group_id=5470 From noreply@sourceforge.net Fri Aug 17 23:17:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 15:17:39 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-17 15:17 Message: Logged In: YES user_id=31435 Reassigned to Fred for the doc patch (and I deleted the other attachments). Checked in the rest (repair of PyEval_MergeCompilerFlags came in between): Lib/code.py; new revision: 1.17 Lib/codeop.py; new revision: 1.5 Misc/NEWS; new revision: 1.209 Python/bltinmodule.c; new revision: 2.228 This seems solid now so far as it goes, and, e.g., IDLE now "does the right thing" for __future__ statements by magic. I still need to teach doctest how to exploit it. Testing got artificially confused by a different bug (that new division doesn't propagate to 'eval'), so I'm going to fix that bug next and then get back to stressing this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 12:51 Message: Logged In: YES user_id=31435 I'm going to do this in pieces. First checked in a reworked version of __future__.py, and added verification to test___future__.py: Lib/__future__.py; new revision: 1.9 Lib/test/test___future__.py; new revision: 1.3 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 11:30 Message: Logged In: YES user_id=31435 Testing turned up bugs, and I'm fixing them. Gross example: the anonymous hex constant attached to nested_scopes in the patched __future__.py was actually the constant for the CO_GENERATOR flag, not the constant for the correct CO_NESTED flag. I've reworked the code to repair that, but also to make it harder for that to happen again; ideally, Python-level CO_xxx flags should be exported by a builtin C module, and so that Jeremy's pyassem.py can use them too (it's got its own hardcoded (re) definitions), but I'm not being that ambitious. The simplest thing that could possibly work is that a global search on, e.g., CO_NESTED, find its use and value in __future__.py too, so that's what I'm settling for. I'll check it in when it all works. That won't be this instant, but will certainly be today. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 03:59 Message: Logged In: YES user_id=6380 What's stopping this from being checked in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-16 22:34 Message: Logged In: YES user_id=31435 This is looking good! I think I know how to get doctest to use it too (to emulate the future settings of the doctest'ed module) -- which would remove an unpleasant wart in current CVS (doctest imports generators from __future__ now, despite that it doesn't use any generators; else test_generators.py would fail). Leaving assigned to me since Michael's on vacation now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-14 14:27 Message: Logged In: YES user_id=6656 I think this latest version actually compiles (ahem). As far as I'm concerned, the coding is now done. Also attach a first cut at some doc updates. Fred will definitely need to fiddle these to get them to compile (there's no latex here on the starship). I should probably do some test cases.. later. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-10 15:41 Message: Logged In: YES user_id=6656 Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly). No rest for the wicked: more docs and some tests still needed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Fri Aug 17 23:24:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 15:24:33 -0700 Subject: [Patches] [ python-Patches-450710 ] 2.2a1 Bug fixes and UnixWare 7 port Message-ID: Patches item #450710, was opened at 2001-08-13 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 Category: Build Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1 Bug fixes and UnixWare 7 port Initial Comment: The attached patches fixes the followin problems and updates the UnixWare 7.0 port as follows: Problems: --------- 1. The code to build the readline module in setup.py did not work if the termcap library did not exist in /usr/lib/termcap. It will now search for the curses libarary or the termcap library and used the first one found. 2. The code in distutils/ccompiler.py makes an invalid assumption about the runtime libraries -- it assumes that each runtime library generates a seperate command line arguement, the same as the library_dirs element does. That choice is best made by the particular compiler implementation. The changed code now passes the entire list to runtime_library_dir_option(), where the decision of how to process the list is best made. 3. The code for runtime_library_dir_option() in distutils/unixccompiler.py was changed to accept a list of directories instead of a string. It now returns a single option string in the form '-Rdir1:dir2:dir2...' instead of multiple options (i.e. '-Rdir1 -Rdir2 -Rdir3 ...'). 4. In the socket module, accept() would return an error if the accept() call was interrupted. The code was changed so that the accept call is made again if the accept() failed because it was interrupted. UnixWare 7 specific changes: ---------------------------- 1. LD_RUN_PATH no longer needs to be set. -R is used supply the executable and dynamically loaded modules with the runtime directory search path. Both configure.in and setup.py now set the appropiate -R options when building. 2. -Kpthread is used instead of -Kthread. 3. Code was added to work around two know bugs in SCO UnixWare 7: a) A bug in accept() does not set the sa_family value correctly for the AF_UNIX family. b) atan2() does returns pi instead of zero for atan2(0, x). This code is enabled by defining SCO_ACCEPT_BUG and SCO_ATAN2_BUG. 4. The python library is still built as a shared library. When building on UnixWare, it now only necessary to add a period (.) to the LD_LIBRARY_PATH environment variable. This is only necessary when building Python so that the shared library (libpythonX.Y.so) is found during the './python setup.py build' phase. Once python is installed, it does not require LD_RUN_PATH or LD_LIBRARY_PATH to be set. NOTE: If item #2 and #3 in the Problems section are not implemented, do not apply the any of UnixWare specific changes in setup.py as those change depend on the changes to ccompiler.py and unixccompiler.py. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 15:24 Message: Logged In: YES user_id=8500 Ok. I will split the patch into 3 groups: 1. setup.py and distutils changes to allow the detection of needed runtime search paths and setting of runtime_library_dirs. This will allow setup to build shared modules that reference shared libraries correctly (controlled by the choice of the compiler class). 2. Change that fix bugs not related to the UnixWare port. 3. Changes related to the UnixWare port. I will add the SCO_*_BUG definitions in pyconfig.h. The will be enabled if both __SCO_VERSION__ and __USLC__ are defined. I will investigate the changes to configure to detect the bug at configure time and taking appropiate action (if I have the time). I've looked at the new addrinfo.h and the patch I submitted for it is no longer needed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 14:30 Message: Logged In: YES user_id=21627 Overall, the patch looks fine to me. Unfortunately, I won't have the time to review it for the next two weeks. Some comments from a first glance: - it looks quite big, and appears to combine issues that are only related due to the fact that they all occur on UnixWare. I'd recommend to split them into smaller parts, unless somebody is willing to approve the entire patch as-is. For example, I wonder what the regrtest chunk does in here when the patch is titled "bug fixes". E.g. the bug fixing should go in one patch, the setup.py stuff in a second one, the USLCCompiler in a third one. - the mimetypes problem was fixed in 1.16 - Could you somehow put SCO_*_BUG into pyconfig.h, or perhaps even check the preprocessor inside the files that have the work-arounds? It only applies to a few files and clutters the command line. _SCO_VERSION or __USLC__ might be appropriate - unless you can come up with a test for the bug itself, rather than asking what operating system it is. - What is the rationale for the addrinfo.h chunk? If the system has getaddrinfo, we should not declare it. Also, the file seems to have changed since you made the patch. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 12:17 Message: Logged In: YES user_id=8500 Here is the file. I've added two more patches then those listed in my previous note: 1. Added a missing argument to the definition of readfp() in Lib/mimetypes.py 2. Added a list of expected skipped tests for UnixWare to Lib/test/regrtest.py. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 10:17 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 08:35 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 02:10 Message: Logged In: YES user_id=21627 Where is the patch (uw7-20011018.patch)? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:33 Message: Logged In: YES user_id=8500 Here is my last note reformtted to a line length of 60. The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:23 Message: Logged In: YES user_id=8500 The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use ===== the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-14 09:43 Message: Logged In: YES user_id=8500 I will obtain the latest CVS files and re-make the patches. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:15 Message: Logged In: YES user_id=21627 Both the configure.in and the mathmodule patch fail to apply, since the code has significantly changed since 2.2a1. In particular, libpython is not build as a shared library anymore on Unixware, so the addition of -R does not apply anymore. Of the remaining changes, I think the setup.py changes that specifically mention unixware7 should not be applied. Instead, it should be researched whether there is a larger class of operating systems that could make use of such changes. Please indicate whether you want to provide an updated patch. If so, I'd strongly advise to have it operate against the current CVS; waiting for 2.2a2 might result in the patch not being available early enough before the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 From noreply@sourceforge.net Fri Aug 17 23:21:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 15:21:14 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-17 15:21 Message: Logged In: YES user_id=31435 Just changed Resolution to Accepted, but should remain Open until the doc patch is processed too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 15:17 Message: Logged In: YES user_id=31435 Reassigned to Fred for the doc patch (and I deleted the other attachments). Checked in the rest (repair of PyEval_MergeCompilerFlags came in between): Lib/code.py; new revision: 1.17 Lib/codeop.py; new revision: 1.5 Misc/NEWS; new revision: 1.209 Python/bltinmodule.c; new revision: 2.228 This seems solid now so far as it goes, and, e.g., IDLE now "does the right thing" for __future__ statements by magic. I still need to teach doctest how to exploit it. Testing got artificially confused by a different bug (that new division doesn't propagate to 'eval'), so I'm going to fix that bug next and then get back to stressing this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 12:51 Message: Logged In: YES user_id=31435 I'm going to do this in pieces. First checked in a reworked version of __future__.py, and added verification to test___future__.py: Lib/__future__.py; new revision: 1.9 Lib/test/test___future__.py; new revision: 1.3 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 11:30 Message: Logged In: YES user_id=31435 Testing turned up bugs, and I'm fixing them. Gross example: the anonymous hex constant attached to nested_scopes in the patched __future__.py was actually the constant for the CO_GENERATOR flag, not the constant for the correct CO_NESTED flag. I've reworked the code to repair that, but also to make it harder for that to happen again; ideally, Python-level CO_xxx flags should be exported by a builtin C module, and so that Jeremy's pyassem.py can use them too (it's got its own hardcoded (re) definitions), but I'm not being that ambitious. The simplest thing that could possibly work is that a global search on, e.g., CO_NESTED, find its use and value in __future__.py too, so that's what I'm settling for. I'll check it in when it all works. That won't be this instant, but will certainly be today. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 03:59 Message: Logged In: YES user_id=6380 What's stopping this from being checked in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-16 22:34 Message: Logged In: YES user_id=31435 This is looking good! I think I know how to get doctest to use it too (to emulate the future settings of the doctest'ed module) -- which would remove an unpleasant wart in current CVS (doctest imports generators from __future__ now, despite that it doesn't use any generators; else test_generators.py would fail). Leaving assigned to me since Michael's on vacation now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-14 14:27 Message: Logged In: YES user_id=6656 I think this latest version actually compiles (ahem). As far as I'm concerned, the coding is now done. Also attach a first cut at some doc updates. Fred will definitely need to fiddle these to get them to compile (there's no latex here on the starship). I should probably do some test cases.. later. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-10 15:41 Message: Logged In: YES user_id=6656 Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly). No rest for the wicked: more docs and some tests still needed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Sat Aug 18 01:10:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 17:10:35 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Sat Aug 18 02:15:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 18:15:01 -0700 Subject: [Patches] [ python-Patches-452174 ] cgi: new methods: getfirst(), getlist() Message-ID: Patches item #452174, was opened at 2001-08-17 11:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: cgi: new methods: getfirst(), getlist() Initial Comment: I find very annoying the need to check whether a user checked one or more checkboxes in a form like this: Currently, I must do something like this: value = form.getvalue("item") if type(value) is type([]): # Multiple items checked. else: # One item checked. I added two methods to cgi.py that simplify and make CGI value processing much more readable and intuitive. The first method ALWAYS returns a single value. Even if more values of the same name were posted, this method always returns only the first one, as a string. scalar_value = form.getfirst("item") scalar_value is now: '1' The second method ALWAYS returns a list. If only one value was posted then the method returns a list which contains this one value. list_values = form.getlist("item") list_values is now: ['1', '2'] This allows me to write much more compact code like: for item in form.getlist("item"): do_something() Using the getfirst() method I don't need to worry about a malicious user posting two values in a query string where I expect only one value. Documentation says: "If the submitted form data contains more than one field with the same name, the object retrieved by "form[key]" is not a FieldStorage or MiniFieldStorage instance but a list of such instances. Similarly, in this situation, "form.getvalue(key)" would return a list of strings. If you expect this possibility (i.e., when your HTML form contains multiple fields with the same name), use the type() function to determine whether you have a single instance or a list of instances." That's IMHO wrong - one shouldn't count on a client to provide valid input. If it doesn't, the script crashes. That's bad. So I added these two very simple methods to the FieldStorage class. The patch is against version 2.6 of the cgi.py module. ---------------------------------------------------------------------- Comment By: Tomas Styblo (tripiecz) Date: 2001-08-17 18:15 Message: Logged In: YES user_id=295775 Sorry for the anonymous posting, I had forgotten to login before I submitted the patch. Of course, you are absolutely true. That's quite a shame I have been completely unaware of this trap for all the months I've been using Python. Thanks for the correction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 11:28 Message: Logged In: YES user_id=6380 Nice idea, but I wouldn't use "default=[]" in the argument list. If the user modifies the list it returns, the default is permanently changed! I suggest that there's no need to allow the user to specify an alternate default for getlist(), so you can just delete this argument and say "return []" in the default case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 From noreply@sourceforge.net Sat Aug 18 10:23:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 Aug 2001 02:23:34 -0700 Subject: [Patches] [ python-Patches-449367 ] HTTPS client authentication in httplib Message-ID: Patches item #449367, was opened at 2001-08-08 19:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449367&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yang (gyang) Assigned to: Greg Stein (gstein) Summary: HTTPS client authentication in httplib Initial Comment: HTTPS is different from HTTP only by: --connection_class In HTTP.__Init__: the old code use self._connection_class(host, port) It fails to pass the x509 argument to the HTTPSConnection, which makes SSL client authentication fails. So, it should be self._connection_class(host, port, **x509) ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-18 02:23 Message: Logged In: YES user_id=6501 I resolved this a bit differently, to prevent the **x509 from being attached to HTTPConnection (which would allow arbitrary params where there shouldn't be). ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2001-08-09 12:34 Message: Logged In: YES user_id=6501 Seems reasonable at first glance. I'll handle this next week with the other HTTP/proxy/DAV work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 06:25 Message: Logged In: YES user_id=6380 Greg, what he says seems to make sense, but I dun't understand the code enough -- and I thought that https:// URLs actually worked, so I'm not sure when they don't work. Can you review the patch and check it in if it's right? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449367&group_id=5470 From noreply@sourceforge.net Sat Aug 18 18:56:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 Aug 2001 10:56:46 -0700 Subject: [Patches] [ python-Patches-452174 ] cgi: new methods: getfirst(), getlist() Message-ID: Patches item #452174, was opened at 2001-08-17 11:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: cgi: new methods: getfirst(), getlist() Initial Comment: I find very annoying the need to check whether a user checked one or more checkboxes in a form like this: Currently, I must do something like this: value = form.getvalue("item") if type(value) is type([]): # Multiple items checked. else: # One item checked. I added two methods to cgi.py that simplify and make CGI value processing much more readable and intuitive. The first method ALWAYS returns a single value. Even if more values of the same name were posted, this method always returns only the first one, as a string. scalar_value = form.getfirst("item") scalar_value is now: '1' The second method ALWAYS returns a list. If only one value was posted then the method returns a list which contains this one value. list_values = form.getlist("item") list_values is now: ['1', '2'] This allows me to write much more compact code like: for item in form.getlist("item"): do_something() Using the getfirst() method I don't need to worry about a malicious user posting two values in a query string where I expect only one value. Documentation says: "If the submitted form data contains more than one field with the same name, the object retrieved by "form[key]" is not a FieldStorage or MiniFieldStorage instance but a list of such instances. Similarly, in this situation, "form.getvalue(key)" would return a list of strings. If you expect this possibility (i.e., when your HTML form contains multiple fields with the same name), use the type() function to determine whether you have a single instance or a list of instances." That's IMHO wrong - one shouldn't count on a client to provide valid input. If it doesn't, the script crashes. That's bad. So I added these two very simple methods to the FieldStorage class. The patch is against version 2.6 of the cgi.py module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 10:56 Message: Logged In: YES user_id=6380 So are yo gonna upload a new patch or do I have to do everything myself? :-) ---------------------------------------------------------------------- Comment By: Tomas Styblo (tripiecz) Date: 2001-08-17 18:15 Message: Logged In: YES user_id=295775 Sorry for the anonymous posting, I had forgotten to login before I submitted the patch. Of course, you are absolutely true. That's quite a shame I have been completely unaware of this trap for all the months I've been using Python. Thanks for the correction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 11:28 Message: Logged In: YES user_id=6380 Nice idea, but I wouldn't use "default=[]" in the argument list. If the user modifies the list it returns, the default is permanently changed! I suggest that there's no need to allow the user to specify an alternate default for getlist(), so you can just delete this argument and say "return []" in the default case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 From noreply@sourceforge.net Sat Aug 18 21:28:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 Aug 2001 13:28:06 -0700 Subject: [Patches] [ python-Patches-452174 ] cgi: new methods: getfirst(), getlist() Message-ID: Patches item #452174, was opened at 2001-08-17 11:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: cgi: new methods: getfirst(), getlist() Initial Comment: I find very annoying the need to check whether a user checked one or more checkboxes in a form like this: Currently, I must do something like this: value = form.getvalue("item") if type(value) is type([]): # Multiple items checked. else: # One item checked. I added two methods to cgi.py that simplify and make CGI value processing much more readable and intuitive. The first method ALWAYS returns a single value. Even if more values of the same name were posted, this method always returns only the first one, as a string. scalar_value = form.getfirst("item") scalar_value is now: '1' The second method ALWAYS returns a list. If only one value was posted then the method returns a list which contains this one value. list_values = form.getlist("item") list_values is now: ['1', '2'] This allows me to write much more compact code like: for item in form.getlist("item"): do_something() Using the getfirst() method I don't need to worry about a malicious user posting two values in a query string where I expect only one value. Documentation says: "If the submitted form data contains more than one field with the same name, the object retrieved by "form[key]" is not a FieldStorage or MiniFieldStorage instance but a list of such instances. Similarly, in this situation, "form.getvalue(key)" would return a list of strings. If you expect this possibility (i.e., when your HTML form contains multiple fields with the same name), use the type() function to determine whether you have a single instance or a list of instances." That's IMHO wrong - one shouldn't count on a client to provide valid input. If it doesn't, the script crashes. That's bad. So I added these two very simple methods to the FieldStorage class. The patch is against version 2.6 of the cgi.py module. ---------------------------------------------------------------------- Comment By: Tomas Styblo (tripiecz) Date: 2001-08-18 13:28 Message: Logged In: YES user_id=295775 Yes, I am. I'll update also the documentation. Some English native speaker will have to review the result, though ;) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 10:56 Message: Logged In: YES user_id=6380 So are yo gonna upload a new patch or do I have to do everything myself? :-) ---------------------------------------------------------------------- Comment By: Tomas Styblo (tripiecz) Date: 2001-08-17 18:15 Message: Logged In: YES user_id=295775 Sorry for the anonymous posting, I had forgotten to login before I submitted the patch. Of course, you are absolutely true. That's quite a shame I have been completely unaware of this trap for all the months I've been using Python. Thanks for the correction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 11:28 Message: Logged In: YES user_id=6380 Nice idea, but I wouldn't use "default=[]" in the argument list. If the user modifies the list it returns, the default is permanently changed! I suggest that there's no need to allow the user to specify an alternate default for getlist(), so you can just delete this argument and say "return []" in the default case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 From noreply@sourceforge.net Sat Aug 18 22:22:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 Aug 2001 14:22:30 -0700 Subject: [Patches] [ python-Patches-452239 ] cPickle patch for bug 451547 Message-ID: Patches item #452239, was opened at 2001-08-17 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452239&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gordon B. McMillan (gmcm) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle patch for bug 451547 Initial Comment: This patch attempts to do to cPickle what Guido did for pickle.py v 1.50. That is: save_global tries importing the module, and fetching the name from the module. If that fails, or the returned object is not the same one we started with, it raises a PicklingError. (All this so pickling a lambda will fail at save time, rather than load time). Modules/cPickle.c is current CVS from view cvs. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 14:22 Message: Logged In: YES user_id=6380 Thanks! Works like a charm. Checked in as cPickle.c 2.63. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452239&group_id=5470 From noreply@sourceforge.net Sun Aug 19 02:34:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 Aug 2001 18:34:50 -0700 Subject: [Patches] [ python-Patches-452767 ] enhancements for cgitb Message-ID: Patches item #452767, was opened at 2001-08-18 18:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452767&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Guido van Rossum (gvanrossum) Summary: enhancements for cgitb Initial Comment: Since the module is short and some code got rearranged, the patch is longer than the module. Enhancements: - file URL now starts with "file://" (standard) rather than "file:" - new optional argument 'context' to enable() - repeated variable names don't have their values shown twice - dotted attributes are shown; missing attributes handled reasonably - highlight the whole logical line even if it has multiple physical lines - use nice generator interface to tokenize - formatting fixed so that it looks good in lynx, links, and w3m too Tested under varying conditions: - with or withour 'display' turned on - with or without 'logdir' specified for saving files - pydoc module missing (still prints text traceback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452767&group_id=5470 From noreply@sourceforge.net Sun Aug 19 05:54:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 Aug 2001 21:54:33 -0700 Subject: [Patches] [ python-Patches-452767 ] enhancements for cgitb Message-ID: Patches item #452767, was opened at 2001-08-18 18:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452767&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Guido van Rossum (gvanrossum) Summary: enhancements for cgitb Initial Comment: Since the module is short and some code got rearranged, the patch is longer than the module. Enhancements: - file URL now starts with "file://" (standard) rather than "file:" - new optional argument 'context' to enable() - repeated variable names don't have their values shown twice - dotted attributes are shown; missing attributes handled reasonably - highlight the whole logical line even if it has multiple physical lines - use nice generator interface to tokenize - formatting fixed so that it looks good in lynx, links, and w3m too Tested under varying conditions: - with or withour 'display' turned on - with or without 'logdir' specified for saving files - pydoc module missing (still prints text traceback) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 21:54 Message: Logged In: YES user_id=6380 Error in sys.excepthook: Traceback (most recent call last): File "/home/guido/python/dist/src/Lib/cgitb.py", line 158, in __call__ self.handle((etype, evalue, etb)) File "/home/guido/python/dist/src/Lib/cgitb.py", line 166, in handle text, doc = 0, html(info, self.context) File "/home/guido/python/dist/src/Lib/cgitb.py", line 99, in html vars = scanvars(reader, frame, locals) File "/home/guido/python/dist/src/Lib/cgitb.py", line 52, in scanvars if lasttoken == '.': UnboundLocalError: local variable 'lasttoken' referenced before assignment ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452767&group_id=5470 From noreply@sourceforge.net Sun Aug 19 07:01:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 Aug 2001 23:01:28 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Sun Aug 19 07:17:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 Aug 2001 23:17:59 -0700 Subject: [Patches] [ python-Patches-452110 ] socketmodule ssl: server & thread Message-ID: Patches item #452110, was opened at 2001-08-17 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 Category: library Group: None Status: Open Resolution: None >Priority: 4 Submitted By: Jozef Hatala (jhatala) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule ssl: server & thread Initial Comment: Simple enhancement to the SSL support in module socket : - support for writing SSL servers (as well as clients) - Py_*_ALLOW_THREADS arround blocking calls to openssl - rsa temp key to work with older export netscape - renamed attribute server to peer This patch allows for powerfull application servers like the following one to be accessed with "netscape https://localhost:1443/" from socket import * p=socket(AF_INET,SOCK_STREAM) p.bind(('localhost',1443)) p.listen(1) while 1 : s,a = p.accept() c = sslserver(s,'server.key','server.crt') print "They said:", c.read() c.write('HTTP/1.0 200 OK\r\n') c.write('Content-Type: text/plain\r\n\r\n** Hi! **') c.close() TODO: a kind of makefile() on the ssl object like on a socket would be welcome. Have fun, jh ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:17 Message: Logged In: YES user_id=6380 Nice, but where's the documentation? (Thanks for the docstrings though!) And the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 From noreply@sourceforge.net Sun Aug 19 07:27:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 Aug 2001 23:27:38 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 >Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) >Assigned to: Tim Peters (tim_one) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Sun Aug 19 20:12:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 Aug 2001 12:12:54 -0700 Subject: [Patches] [ python-Patches-453035 ] shrink frame objects Message-ID: Patches item #453035, was opened at 2001-08-19 12:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453035&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: shrink frame objects Initial Comment: This patch reduces the size of frame objects. A lot of memory is used for the f_blockstack array. Deeply nested blocks are rarely used. I believe the standard test suite never uses any more than three blocks. The patch reduces the size of the f_blockstack array from 20 elements to 4. The rest of the block stack is allocated only if needed. On my machine this change reduces the size of the frameobject struct from 336 bytes to 148. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453035&group_id=5470 From noreply@sourceforge.net Sun Aug 19 21:36:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 Aug 2001 13:36:20 -0700 Subject: [Patches] [ python-Patches-453035 ] shrink frame objects Message-ID: Patches item #453035, was opened at 2001-08-19 12:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453035&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: shrink frame objects Initial Comment: This patch reduces the size of frame objects. A lot of memory is used for the f_blockstack array. Deeply nested blocks are rarely used. I believe the standard test suite never uses any more than three blocks. The patch reduces the size of the f_blockstack array from 20 elements to 4. The rest of the block stack is allocated only if needed. On my machine this change reduces the size of the frameobject struct from 336 bytes to 148. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-19 13:36 Message: Logged In: YES user_id=31435 Hmm! Offhand I'm -0 on this: I can see that it makes block-related operations more expensive, but don't know why I should care so much about how big a frame is that I should be keen to slow it in return for some space. If you leave test_generators out of the test suite, only 115 unique frame objects are allocated (on Windows -- perhaps a little different on Linux, since different tests get skipped), so this is a total savings of about 21KB. That seems trivial compared to the total MBs allocated. If you include test_generators, it zooms to about 1800 frame allocations (and so about 330KB potential saving) -- but test_generators is deliberately stressing the system. In most programs, the # of frames allocated is equal to the maximum call depth, and very deep recursion is avoided in Python for lots of reasons. So, what's the value to you? I suppose I'd like it better if you gave back 4 bytes to hold a pointer to the block stack (pointing either to the static stack or the malloc'ed one), so that PyFrame_BlockSetup and PyFrame_BlockPop didn't have to *compute* which stack to use on each call. This would require computing the max block stack depth at compile time. BTW, I don't think you intended to inculde a setup.py patch in the attachment. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 12:45 Message: Logged In: YES user_id=35752 Argh, forgot to check the upload box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453035&group_id=5470 From noreply@sourceforge.net Sun Aug 19 22:24:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 Aug 2001 14:24:53 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) >Assigned to: Guido van Rossum (gvanrossum) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-19 14:24 Message: Logged In: YES user_id=31435 I've never called TerminateThread() on Win32, and given the dire wngs about it in the MS docs, never will. IMO Python shouldn't be in this business unless it can guarantee to do it safely. But it can't, so -1 from me. Java did get out of this business: What Java has that Python lacks (follow the link) is a way to "interrupt" a thread, and there's nothing that was possible with thread.stop() that isn't possible by building on interruption (although the places where people really want this are places where thread.stop() never worked anyway -- Java never had a gimmick as Draconian as Win32's TerminateThread() -- Java's thread.stop() was "stop if you can, but there are many reasons you may not be able to"). I'd be +1 on a thread interruption facility for Python, which amounts to a way to raise an exception in a different thread. But like Java's facility, it couldn't always guarantee the target thread would respond. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Sun Aug 19 20:59:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 Aug 2001 12:59:28 -0700 Subject: [Patches] [ python-Patches-421893 ] Cleanup GC API Message-ID: Patches item #421893, was opened at 2001-05-06 14:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Guido van Rossum (gvanrossum) Summary: Cleanup GC API Initial Comment: This patch adds three new APIs: PyObject_GC_New PyObject_GC_NewVar PyObject_GC_Resize PyObject_GC_Del and renames PyObject_GC_Init and PyObject_GC_Fini to: PyObject_GC_Track PyObject_GC_Ignore respectively. Objects that wish to be tracked by the collector must use these new APIs. Many more details about the GC implementation are hidden inside gcmodule.c. There seems to be no change in performance. Note that PyObject_GC_{New,NewVar} automatically adds the object to the GC lists. There is no need to call PyObject_GC_Track. PyObject_GC_Del automatically removes the object from the GC list but usually you want to call PyObject_GC_Ignore yourself (DECREFs can end up running arbitrary code). It should be more difficult to corrupt the GC linked lists now. Also, you can now call PyObject_GC_Ignore on objects that you know will not create RCs. The _weakref module does this. Previously, every object that had the GC type flag set and could be found by using tp_traverse had to be in a GC linked list. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 12:59 Message: Logged In: YES user_id=35752 I've brought the patch up to date. I'm not sure if we really need this patch. The current approach works okay. I think this patch improves things since more details about the GC implementation are hidden. This would give us more freedom to change the implementation in the future. Also, I think the patch makes it easier for extension types to support GC. The patch is somewhat backwards compatible now. Types that use the old interface will still compile but will not be GCed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:32 Message: Logged In: YES user_id=6380 Neil, do we still need this? I've marked it out-of-date because I'm sure that it won't apply cleanly any more. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-16 09:25 Message: Logged In: YES user_id=6380 I think I know a way to fix the incompatibility, by switching to a different flag bit. I'll try to work this into the descr-branch code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 10:13 Message: Logged In: YES user_id=21627 I have two problems with this patch: 1. It comes with no documentation. 2. It breaks existing third-party modules which use the GC API as defined in Python 2. Consequently, I recommend rejection of the patch in its current form. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 From noreply@sourceforge.net Sun Aug 19 22:09:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 Aug 2001 14:09:37 -0700 Subject: [Patches] [ python-Patches-453035 ] shrink frame objects Message-ID: Patches item #453035, was opened at 2001-08-19 12:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453035&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: shrink frame objects Initial Comment: This patch reduces the size of frame objects. A lot of memory is used for the f_blockstack array. Deeply nested blocks are rarely used. I believe the standard test suite never uses any more than three blocks. The patch reduces the size of the f_blockstack array from 20 elements to 4. The rest of the block stack is allocated only if needed. On my machine this change reduces the size of the frameobject struct from 336 bytes to 148. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 14:09 Message: Logged In: YES user_id=35752 I had the patch around so I thought I would run it past someone. If it only saves 21KB for the average program then it's not worth complicating the code. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-19 13:36 Message: Logged In: YES user_id=31435 Hmm! Offhand I'm -0 on this: I can see that it makes block-related operations more expensive, but don't know why I should care so much about how big a frame is that I should be keen to slow it in return for some space. If you leave test_generators out of the test suite, only 115 unique frame objects are allocated (on Windows -- perhaps a little different on Linux, since different tests get skipped), so this is a total savings of about 21KB. That seems trivial compared to the total MBs allocated. If you include test_generators, it zooms to about 1800 frame allocations (and so about 330KB potential saving) -- but test_generators is deliberately stressing the system. In most programs, the # of frames allocated is equal to the maximum call depth, and very deep recursion is avoided in Python for lots of reasons. So, what's the value to you? I suppose I'd like it better if you gave back 4 bytes to hold a pointer to the block stack (pointing either to the static stack or the malloc'ed one), so that PyFrame_BlockSetup and PyFrame_BlockPop didn't have to *compute* which stack to use on each call. This would require computing the max block stack depth at compile time. BTW, I don't think you intended to inculde a setup.py patch in the attachment. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 12:45 Message: Logged In: YES user_id=35752 Argh, forgot to check the upload box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453035&group_id=5470 From noreply@sourceforge.net Sun Aug 19 20:45:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 Aug 2001 12:45:36 -0700 Subject: [Patches] [ python-Patches-453035 ] shrink frame objects Message-ID: Patches item #453035, was opened at 2001-08-19 12:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453035&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: shrink frame objects Initial Comment: This patch reduces the size of frame objects. A lot of memory is used for the f_blockstack array. Deeply nested blocks are rarely used. I believe the standard test suite never uses any more than three blocks. The patch reduces the size of the f_blockstack array from 20 elements to 4. The rest of the block stack is allocated only if needed. On my machine this change reduces the size of the frameobject struct from 336 bytes to 148. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 12:45 Message: Logged In: YES user_id=35752 Argh, forgot to check the upload box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453035&group_id=5470 From noreply@sourceforge.net Mon Aug 20 04:21:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 Aug 2001 20:21:13 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Guido van Rossum (gvanrossum) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Jason Petrone (jpetrone) Date: 2001-08-19 20:21 Message: Logged In: YES user_id=71210 While I would very much like to have full interruption functionality, I'm not sure how easily it could be done on all platforms. At the least it would be nice to have SOME sort of thread signalling. What guarantees about safety should python make? I've considered trying to add cleanup handlers to release interpreter locks and such, but didn't feel like putting that much effort into a patch that would likely be rejected anyway. I will look into adding cleanup routines if we can establish some requirements. I think I can do it in pthreads pretty easily. Dunno how easy the rest will be. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-19 14:24 Message: Logged In: YES user_id=31435 I've never called TerminateThread() on Win32, and given the dire wngs about it in the MS docs, never will. IMO Python shouldn't be in this business unless it can guarantee to do it safely. But it can't, so -1 from me. Java did get out of this business: What Java has that Python lacks (follow the link) is a way to "interrupt" a thread, and there's nothing that was possible with thread.stop() that isn't possible by building on interruption (although the places where people really want this are places where thread.stop() never worked anyway -- Java never had a gimmick as Draconian as Win32's TerminateThread() -- Java's thread.stop() was "stop if you can, but there are many reasons you may not be able to"). I'd be +1 on a thread interruption facility for Python, which amounts to a way to raise an exception in a different thread. But like Java's facility, it couldn't always guarantee the target thread would respond. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Mon Aug 20 05:38:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 Aug 2001 21:38:15 -0700 Subject: [Patches] [ python-Patches-453199 ] Cosmetic changes to libframework.tex Message-ID: Patches item #453199, was opened at 2001-08-19 21:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453199&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Cosmetic changes to libframework.tex Initial Comment: Most changes here are grammatical or cosmetic, to fit more in line with the documentation guidelines. In a few cases, parameter names were changed to match the source code (important for keyword argument passing). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453199&group_id=5470 From noreply@sourceforge.net Mon Aug 20 06:22:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 Aug 2001 22:22:01 -0700 Subject: [Patches] [ python-Patches-453204 ] GetArgv and ProgressBars (libmacui.tex) Message-ID: Patches item #453204, was opened at 2001-08-19 22:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453204&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: GetArgv and ProgressBars (libmacui.tex) Initial Comment: Documentation for the fairly recently added GetArgv function in Mac/Lib/EasyDialogs.py is included. Also, the documentation for ProgressBar objects has been greatly expanded. Further, many minor changes and corrections have been made throughout. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453204&group_id=5470 From noreply@sourceforge.net Mon Aug 20 14:01:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 06:01:26 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Guido van Rossum (gvanrossum) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 06:01 Message: Logged In: YES user_id=6380 Thanks to Tim for jogging my memory. I think an interruption facility should be a way to send an exception to a thread, similar to KeyboardInterrupt -- the thread can then decide what to do (and since exceptions can happen anyway, the safety guarantee is not violated -- if the application doesn't release locks on exceptions, it is already unsafe). One problem is that it's probably most important to be able to stop a thread while it's blocked for I/O (a socket connect() or recv() from a non-responding host is a typical example). Unfortunately, the only way to do that on Unix is to send a real signal to the thread. On Windows, I have no idea. Note that part of this patch would still be useful: start_new_thread() should return a thread-id. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-19 20:21 Message: Logged In: YES user_id=71210 While I would very much like to have full interruption functionality, I'm not sure how easily it could be done on all platforms. At the least it would be nice to have SOME sort of thread signalling. What guarantees about safety should python make? I've considered trying to add cleanup handlers to release interpreter locks and such, but didn't feel like putting that much effort into a patch that would likely be rejected anyway. I will look into adding cleanup routines if we can establish some requirements. I think I can do it in pthreads pretty easily. Dunno how easy the rest will be. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-19 14:24 Message: Logged In: YES user_id=31435 I've never called TerminateThread() on Win32, and given the dire wngs about it in the MS docs, never will. IMO Python shouldn't be in this business unless it can guarantee to do it safely. But it can't, so -1 from me. Java did get out of this business: What Java has that Python lacks (follow the link) is a way to "interrupt" a thread, and there's nothing that was possible with thread.stop() that isn't possible by building on interruption (although the places where people really want this are places where thread.stop() never worked anyway -- Java never had a gimmick as Draconian as Win32's TerminateThread() -- Java's thread.stop() was "stop if you can, but there are many reasons you may not be able to"). I'd be +1 on a thread interruption facility for Python, which amounts to a way to raise an exception in a different thread. But like Java's facility, it couldn't always guarantee the target thread would respond. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Mon Aug 20 21:30:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 13:30:15 -0700 Subject: [Patches] [ python-Patches-403671 ] Allow jython to complete the test_class test Message-ID: Patches item #403671, was opened at 2001-02-07 13:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403671&group_id=5470 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to complete the test_class test Initial Comment: A breakdown of the changes: - the __del__ method must be present at class definition time for jython to use it. - slices pass into __xxxitem__ works, but the default values are not "0, maxint, None" but "None, None, 1". At this time this is a known difference. - in jython the __int__, __long__ etc methods must return a correctly typed value. The test that just return None is skipped. - An explicit call to GC is required to force a call to __del__. The two changes that just adds a print "the expected result" is really ugly, but it is necessary for jython to generate the same output as python. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 13:30 Message: Logged In: YES user_id=12800 Applied to the Py2.2 trunk and 2.2a2 branch. ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-08-09 11:40 Message: Logged In: YES user_id=4201 Yes, combatibility have not improved in any of these areas. Jython still needs helps like this patch to pass the test. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:23 Message: Logged In: YES user_id=6380 Accepted. I'll leave it to Barry to check this in. (Finn, do you still need this? I assume so!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403671&group_id=5470 From noreply@sourceforge.net Mon Aug 20 23:06:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 15:06:54 -0700 Subject: [Patches] [ python-Patches-445770 ] Make calendar.py work forever. Message-ID: Patches item #445770, was opened at 2001-07-29 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Postponed Priority: 5 Submitted By: Joseph A Knapka (jknapka) Assigned to: Skip Montanaro (montanaro) Summary: Make calendar.py work forever. Initial Comment: Changes to calendar.py (using a lot of code stolen from Pmw) to make it work for essentially any date, and handle Julian vs. Gregorian dating properly. julian=[-1|0|1] and papal=[0|1] arguments added to many functions, with appropriate defaults. If julian==1, Julian dating is used; if julian==0 Gregorian dating is used; if julian==-1 the code decides based on the date which dating system to use. If papal==1 the Gregorian reformation is applied in October 1582, the year of the edict; if papal==0 the reformation is applied in September 1752, the year in which Britain applied the change. julian defaults to -1 and papal to 0, so normally no one will need to care about them. Dependencies on the "time" module have been removed. Added functions: ymdtojdn(y,m,d) - convert year,month,day to Julian day number jdntoymd(jdn) - convert jdn to (year,month,day) tuple. jdntodow(jdn) - compute the day-of-week (0-6) of a Julian day number. Modified all existing code to use the new date and day-of-week code. So "prcal()" for example does the right thing. Testing: it gets the same answers as the "cal" program for a selection of months between 01/01 and 9999/12, including Oct 1582 and Sept 1752, when papal=0. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-08-20 15:06 Message: Logged In: YES user_id=44345 I'm closing this patch and marking it postponed. Having calendar.py in the core was probably a good idea when it was first written, but it's not clear that it's all that generally useful now. I agree that removing the limitations imposed by the chronologically challenged time module is a good thing. If you'd like to move it along, here are a couple suggestions: 1. Make it available somewhere on the web and announce it on c.l.py. Also, submit it to the Vaults of Parnassus. 2. Check out Marc-Andre Lemburg's mx.DateTime module. You might be able to reuse a lot of code from there. You might even get MAL to add the unique stuff from your calendar module to his code. In the long run, I don't see calendar.py being all that different from the soundex module that was removed around the 2.0 release. It's fairly old, and not all that widely used. As a result there's now a Python replacement (soundex.py) on my website. ---------------------------------------------------------------------- Comment By: Joseph A Knapka (jknapka) Date: 2001-08-01 09:42 Message: Logged In: YES user_id=118570 The current calendar.py code only works after 1900AD. I can think of a number of applications (library catalogs, or any other kind of historical record-keeping, for example) that need to represent dates before 1900. Furthermore, this code will work into the indefinite future, barring further Papal edicts, whereas the current calendar.py code is bound by the limitations of the "time" module. What's the point of keeping arbitrary limitations in the standard library? Essentially this code was written because I had an application that could use it, and I thought it might be a nice improvement to the existing calendar code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-29 15:29 Message: Logged In: YES user_id=6380 Apart from the novelty value, what's the point of supporting calendars hundreds of years back? Why does this belong in the standard library? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470 From noreply@sourceforge.net Mon Aug 20 23:48:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 15:48:25 -0700 Subject: [Patches] [ python-Patches-449444 ] MimeWriter: add RFC-required header Message-ID: Patches item #449444, was opened at 2001-08-09 03:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449444&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michael Strasser (strasser) Assigned to: Barry Warsaw (bwarsaw) Summary: MimeWriter: add RFC-required header Initial Comment: RFC 1521 states that Internet messages (multi-part?) must include the header "MIME-Version: 1.0". Many mail agents ignore its absence but some do not. I have added this header to the __init__ method of MimeWriter. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 15:48 Message: Logged In: YES user_id=12800 Rejecting because this really isn't the right place to add this header. The header should only be added to the top level container, but this patch will add it to all the subparts as well. Better if application writers simply adds the appropriate header to the top level container themselves. ---------------------------------------------------------------------- Comment By: Michael Strasser (strasser) Date: 2001-08-09 04:01 Message: Logged In: YES user_id=37262 I forgot to attach the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449444&group_id=5470 From noreply@sourceforge.net Tue Aug 21 04:16:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 20:16:55 -0700 Subject: [Patches] [ python-Patches-452767 ] enhancements for cgitb Message-ID: Patches item #452767, was opened at 2001-08-18 18:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452767&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Ka-Ping Yee (ping) >Assigned to: Ka-Ping Yee (ping) Summary: enhancements for cgitb Initial Comment: Since the module is short and some code got rearranged, the patch is longer than the module. Enhancements: - file URL now starts with "file://" (standard) rather than "file:" - new optional argument 'context' to enable() - repeated variable names don't have their values shown twice - dotted attributes are shown; missing attributes handled reasonably - highlight the whole logical line even if it has multiple physical lines - use nice generator interface to tokenize - formatting fixed so that it looks good in lynx, links, and w3m too Tested under varying conditions: - with or withour 'display' turned on - with or without 'logdir' specified for saving files - pydoc module missing (still prints text traceback) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 21:54 Message: Logged In: YES user_id=6380 Error in sys.excepthook: Traceback (most recent call last): File "/home/guido/python/dist/src/Lib/cgitb.py", line 158, in __call__ self.handle((etype, evalue, etb)) File "/home/guido/python/dist/src/Lib/cgitb.py", line 166, in handle text, doc = 0, html(info, self.context) File "/home/guido/python/dist/src/Lib/cgitb.py", line 99, in html vars = scanvars(reader, frame, locals) File "/home/guido/python/dist/src/Lib/cgitb.py", line 52, in scanvars if lasttoken == '.': UnboundLocalError: local variable 'lasttoken' referenced before assignment ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452767&group_id=5470 From noreply@sourceforge.net Tue Aug 21 05:04:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 21:04:25 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 9 Submitted By: Paul Moore (pmoore) >Assigned to: Tim Peters (tim_one) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:04 Message: Logged In: YES user_id=12800 Assigning to Tim. Isn't this already in the Py2.2 tree? Can't we close this patch now? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:01 Message: Logged In: YES user_id=11375 Thomas, do you want to apply this patch or shall I do it? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Tue Aug 21 05:10:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 21:10:34 -0700 Subject: [Patches] [ python-Patches-450710 ] 2.2a1 Bug fixes and UnixWare 7 port Message-ID: Patches item #450710, was opened at 2001-08-13 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 Category: Build Group: None >Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1 Bug fixes and UnixWare 7 port Initial Comment: The attached patches fixes the followin problems and updates the UnixWare 7.0 port as follows: Problems: --------- 1. The code to build the readline module in setup.py did not work if the termcap library did not exist in /usr/lib/termcap. It will now search for the curses libarary or the termcap library and used the first one found. 2. The code in distutils/ccompiler.py makes an invalid assumption about the runtime libraries -- it assumes that each runtime library generates a seperate command line arguement, the same as the library_dirs element does. That choice is best made by the particular compiler implementation. The changed code now passes the entire list to runtime_library_dir_option(), where the decision of how to process the list is best made. 3. The code for runtime_library_dir_option() in distutils/unixccompiler.py was changed to accept a list of directories instead of a string. It now returns a single option string in the form '-Rdir1:dir2:dir2...' instead of multiple options (i.e. '-Rdir1 -Rdir2 -Rdir3 ...'). 4. In the socket module, accept() would return an error if the accept() call was interrupted. The code was changed so that the accept call is made again if the accept() failed because it was interrupted. UnixWare 7 specific changes: ---------------------------- 1. LD_RUN_PATH no longer needs to be set. -R is used supply the executable and dynamically loaded modules with the runtime directory search path. Both configure.in and setup.py now set the appropiate -R options when building. 2. -Kpthread is used instead of -Kthread. 3. Code was added to work around two know bugs in SCO UnixWare 7: a) A bug in accept() does not set the sa_family value correctly for the AF_UNIX family. b) atan2() does returns pi instead of zero for atan2(0, x). This code is enabled by defining SCO_ACCEPT_BUG and SCO_ATAN2_BUG. 4. The python library is still built as a shared library. When building on UnixWare, it now only necessary to add a period (.) to the LD_LIBRARY_PATH environment variable. This is only necessary when building Python so that the shared library (libpythonX.Y.so) is found during the './python setup.py build' phase. Once python is installed, it does not require LD_RUN_PATH or LD_LIBRARY_PATH to be set. NOTE: If item #2 and #3 in the Problems section are not implemented, do not apply the any of UnixWare specific changes in setup.py as those change depend on the changes to ccompiler.py and unixccompiler.py. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:10 Message: Logged In: YES user_id=12800 You really need to supply separate patches for each issue that you're trying to address. It will be impossible for someone to review and selectively apply only the patches that are still necessary. I'm closing this patch report. Please try to make your submissions as small and as self contained as possible. We're much more likely to be able to review and accept them that way. Thanks! ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 15:24 Message: Logged In: YES user_id=8500 Ok. I will split the patch into 3 groups: 1. setup.py and distutils changes to allow the detection of needed runtime search paths and setting of runtime_library_dirs. This will allow setup to build shared modules that reference shared libraries correctly (controlled by the choice of the compiler class). 2. Change that fix bugs not related to the UnixWare port. 3. Changes related to the UnixWare port. I will add the SCO_*_BUG definitions in pyconfig.h. The will be enabled if both __SCO_VERSION__ and __USLC__ are defined. I will investigate the changes to configure to detect the bug at configure time and taking appropiate action (if I have the time). I've looked at the new addrinfo.h and the patch I submitted for it is no longer needed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 14:30 Message: Logged In: YES user_id=21627 Overall, the patch looks fine to me. Unfortunately, I won't have the time to review it for the next two weeks. Some comments from a first glance: - it looks quite big, and appears to combine issues that are only related due to the fact that they all occur on UnixWare. I'd recommend to split them into smaller parts, unless somebody is willing to approve the entire patch as-is. For example, I wonder what the regrtest chunk does in here when the patch is titled "bug fixes". E.g. the bug fixing should go in one patch, the setup.py stuff in a second one, the USLCCompiler in a third one. - the mimetypes problem was fixed in 1.16 - Could you somehow put SCO_*_BUG into pyconfig.h, or perhaps even check the preprocessor inside the files that have the work-arounds? It only applies to a few files and clutters the command line. _SCO_VERSION or __USLC__ might be appropriate - unless you can come up with a test for the bug itself, rather than asking what operating system it is. - What is the rationale for the addrinfo.h chunk? If the system has getaddrinfo, we should not declare it. Also, the file seems to have changed since you made the patch. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 12:17 Message: Logged In: YES user_id=8500 Here is the file. I've added two more patches then those listed in my previous note: 1. Added a missing argument to the definition of readfp() in Lib/mimetypes.py 2. Added a list of expected skipped tests for UnixWare to Lib/test/regrtest.py. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 10:17 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-17 08:35 Message: Logged In: YES user_id=8500 I thought I uploaded it. Of course it was late at night and I could of imagined it :-) I will upload it when I get home from work tonite. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-17 02:10 Message: Logged In: YES user_id=21627 Where is the patch (uw7-20011018.patch)? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:33 Message: Logged In: YES user_id=8500 Here is my last note reformtted to a line length of 60. The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-16 22:23 Message: Logged In: YES user_id=8500 The attached patch (uw7-20011018.patch) makes the following changes: configure.in: ------------- 1. Updates $OPT for the UnixWare port to define the macros that controls the conditional compilation of code to work around UnixWare's known bugs. The macros are SCO_ACCEPT_BUG and SCO_ATAN2_BUG. Note: I did not modify configure to generate a shared Python library pending discussion on how to best allow for the user to tell configure which type of library to generate. I did, however, modify setup.py and some of the distutil modules to generate (if needed) the option needed to add runtime library search paths to any loadable modules that uses third party shared libraries (in my case, ssl, tcl, tk, and readline). I believe that the modification I made will not break anything, but I do not have all the possible systems available to me so I can test that. setup.py: --------- 1. Changed the function, find_library_file, to return a tuple containing two (2) lists. The first (possibly empty) list containing the directory where the library is located. The second (possibly empty) list contains the directories that will have to be added to the runtime directory search list, runtime_library_dirs. The second list can only have an item when the located library is a shared library. 2. Change the code where find_library_file was called to handle the new return value and to set runtime_library_dirs as appropriate. 3. Added '/usr/ccs/lib' to the lib_dirs variable. This directory is common on System V operating systems (UnixWare, Solaris, etc.) 4. Changed the readline build so that termcap does not have to exist in /usr/local/termcap, and to use the curses or terminfo libraries if available. Lib/distutils/ccompiler.py: --------------------------- 1. Changed runtime_library_dir_option() so that the default implementation is to return an empty list instead of raising the not implemented exception. The reason for this change is that it is possible that runtime_library_dirs can contain a non-empty list of directories to search even if there is no need to specify a runtime directory search path. For example, on Linux the default compiler does not use any options to set the runtime directory search path. It is handled by an external file (ld.so.conf). In this manner, systems that need to specify a runtime directory search path can do so using the value in runtime_library_dirs, while other systems that don't can just ignore the runtime_library_dirs, and return an empty list from runtime_library_dir_option(). 2. Added a new compiler, USLCCompiler. This module is a sub-class of the UnixCCompiler. This module supports Unix System Labs style compilers common on System V Unix. It basically implements the required generation of the -R option for setting the runtime directory search path. 3. Changed how runtime_library_dir_option() is called. It now is passed a list of directories and returns a list of options. This was done so that the decision of how to implement the runtime directory search option. The previous code assumed that generating multiple -R options, one per directory was correct. This assumption is false for at least the UnixWare system which wants only one (1) -R option followed by a colon separated list of directories to search. This change lets the compiler decide, which is where the decision should reside. Lib/distutils/mvccompiler.py: ----------------------------- 1. Removed it's implementation of runtime_library__dir_option() so that the CCompiler implementation will be used (i.e. an empty list is returned). Lib/distutils/mwerkscompiler.py: -------------------------------- 1. Changed code so that having a non-empty runtime_library_dirs list prints a warning instead of raising an exception. Lib/distutils/unixccompiler.py: ------------------------------- 1. Removed it's implementation of runtime_library_dir_option() so that an empty list is returned (via CCompiler.runtime_library_dir_option()) if it is called. Lib/distutils/uslccompiler.py: ------------------------------ This is a new file. It provides support for Unix System Labs style compilers usually found on System V Unix. Note: I believe that Solaris systems using Sun's compiler will have to use ===== the USLCCompiler class. Unfortunately, I no longer have access to a Solaris system on which I can test that belief. Modules/_cursesmodule.c: ------------------------ 1. Added code to set STRICT_SYSV_CURSES for UnixWare systems. Modules/addrinfo.h: ------------------- 1. Removed the enclosing "#ifndef HAVE_GETADDRINFO ... #endif". This caused problems on systems that have getaddreinfo() but still needed to have struct sockaddr_storage defined (i.e. UnixWare). This does not cause a problem because everything else in the file has it's own individual "#ifndef ... #endif" wrapper. Modules/cmathmodule.c: Modules/mathmodule.c: Objects/complexobject.c: ------------------------ 1. Added code to work around the UnixWare atan2() bug. This code will only be compiled in if the macro, SCO_ATAN2_BUG, is defined. Modules/socketmodule.c ---------------------- 1. Added code to work around the UnixWare accept() bug. This code will only be compiled in if the macro, SCO_ACCEPT_BUG is defined. 2. Changed code so that accept() call will be re-started if accept fails because the system call was interrupted. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-14 09:43 Message: Logged In: YES user_id=8500 I will obtain the latest CVS files and re-make the patches. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:15 Message: Logged In: YES user_id=21627 Both the configure.in and the mathmodule patch fail to apply, since the code has significantly changed since 2.2a1. In particular, libpython is not build as a shared library anymore on Unixware, so the addition of -R does not apply anymore. Of the remaining changes, I think the setup.py changes that specifically mention unixware7 should not be applied. Instead, it should be researched whether there is a larger class of operating systems that could make use of such changes. Please indicate whether you want to provide an updated patch. If so, I'd strongly advise to have it operate against the current CVS; waiting for 2.2a2 might result in the patch not being available early enough before the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450710&group_id=5470 From noreply@sourceforge.net Tue Aug 21 05:12:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 21:12:56 -0700 Subject: [Patches] [ python-Patches-442351 ] Copy of classes with __del_ in jython Message-ID: Patches item #442351, was opened at 2001-07-18 03:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442351&group_id=5470 >Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Barry Warsaw (bwarsaw) Summary: Copy of classes with __del_ in jython Initial Comment: The __del__ method is somewhat special in jython because it must exists when the instance is created. Adding a __del__ method to an existing instance have no effect in jython. This patch will ensure that the new copy will be created with a __del__ method if the source defined a __del__ method. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:12 Message: Logged In: YES user_id=12800 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442351&group_id=5470 From noreply@sourceforge.net Tue Aug 21 05:14:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 21:14:16 -0700 Subject: [Patches] [ python-Patches-441348 ] Allow jython to complete test_charmap Message-ID: Patches item #441348, was opened at 2001-07-14 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to complete test_charmap Initial Comment: The repr of unicode strings in the output is different for jython. The attached patch allow jython to complete the test_charmapcodec test. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:14 Message: Logged In: YES user_id=12800 Assigned to Barry for review. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:29 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 From noreply@sourceforge.net Tue Aug 21 05:14:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 21:14:38 -0700 Subject: [Patches] [ python-Patches-441348 ] Allow jython to complete test_charmap Message-ID: Patches item #441348, was opened at 2001-07-14 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 >Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Barry Warsaw (bwarsaw) Summary: Allow jython to complete test_charmap Initial Comment: The repr of unicode strings in the output is different for jython. The attached patch allow jython to complete the test_charmapcodec test. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:14 Message: Logged In: YES user_id=12800 Assigned to Barry for review. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:29 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 From noreply@sourceforge.net Tue Aug 21 05:16:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 21:16:53 -0700 Subject: [Patches] [ python-Patches-417795 ] Fix memory cycles in Weak*Dictionary Message-ID: Patches item #417795, was opened at 2001-04-20 21:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417795&group_id=5470 Category: library Group: None Status: Open Resolution: None >Priority: 6 Submitted By: David Allouche (ddaa10) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix memory cycles in Weak*Dictionary Initial Comment: There is a subtle bug in WeakValueDictionary and WeakKeyDictonary that cause them to create reference cycles. This does not break anything by itself, but: 1/ it's bad to rely on the garbage collector; 2/ this could lead to uncollectable cycles if a subclass of Weak*Dictionary defines __del__. The trick is that deletions of a key/value of a item trigger a remove function. That remove function is strong referenced inside the weakref object. That function internally stores a strong reference to the self.data (dictionary) object. self.data obviously strong references the weakref object. The minimal overhead solution would be to use a __del__ method that would empty the self.data dictionary (thus breaking the references loops at Weak*Dictionary destruction). This solution is not acceptable since a key (for WeakValueDictionnary) or a value (for WeakKeyDictionary) can be a composite object. Such composite object can contain a reference which ultimately loops back to the Weak*Dictionary. Ok that's an user ref cycle, but the library __del__ method makes it uncollectable. The solution I propose is to change the remove function to contain, not a strong reference to the dictionary, but a weak reference to the Weak*Dictionary object. If the weakref has expired when the remove function is called; we just do nothing. This can lead to a silent change in behavior if the user has broken the encapsulation of the Weak*Dictionary and stored an external reference to the data dictionary. I think the best possible solution would be to give the choice between the two remove functions at runtime through a module variable. The attached patch makes a "weakref-patched.py" file from the "weakref.py" file of the 2.1 distribution. That file implements my proposed solution. It has been regression tested. It would make sense to add test units for memory cycles int test_weakref.py, but I'm too newbie (and do not have enough time) to do it myself. Keep on the good work. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:16 Message: Logged In: YES user_id=12800 Bumping the priority to 6 since It Would Be Good if Fred could look at this before 2.2a2, but not critical. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417795&group_id=5470 From noreply@sourceforge.net Tue Aug 21 05:21:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 21:21:36 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Guido van Rossum (gvanrossum) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Jason Petrone (jpetrone) Date: 2001-08-20 21:21 Message: Logged In: YES user_id=71210 Sending SIGINT to a thread is pretty easy. Is the hard part of killing a thread with signals getting python to process signals outside of the main thread? At any rate, I'm attaching a new patch that returns the thread id from start_new_thread, without any of the kill_thread() stuff. It includes a change to libthread.tex. For platforms I don't really know I just had them return -1 on failure and 0 on success so they at least run. o Solaris, pthreads, pth - returns thread id, tested o NT - returns thread id, (should work, haven't tested after removing kill) o SGI, BeOS - returns thread id, untested o wince, OS/2, LWP, cthread, foobar - returns -1 on failure, 0 on success ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 06:01 Message: Logged In: YES user_id=6380 Thanks to Tim for jogging my memory. I think an interruption facility should be a way to send an exception to a thread, similar to KeyboardInterrupt -- the thread can then decide what to do (and since exceptions can happen anyway, the safety guarantee is not violated -- if the application doesn't release locks on exceptions, it is already unsafe). One problem is that it's probably most important to be able to stop a thread while it's blocked for I/O (a socket connect() or recv() from a non-responding host is a typical example). Unfortunately, the only way to do that on Unix is to send a real signal to the thread. On Windows, I have no idea. Note that part of this patch would still be useful: start_new_thread() should return a thread-id. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-19 20:21 Message: Logged In: YES user_id=71210 While I would very much like to have full interruption functionality, I'm not sure how easily it could be done on all platforms. At the least it would be nice to have SOME sort of thread signalling. What guarantees about safety should python make? I've considered trying to add cleanup handlers to release interpreter locks and such, but didn't feel like putting that much effort into a patch that would likely be rejected anyway. I will look into adding cleanup routines if we can establish some requirements. I think I can do it in pthreads pretty easily. Dunno how easy the rest will be. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-19 14:24 Message: Logged In: YES user_id=31435 I've never called TerminateThread() on Win32, and given the dire wngs about it in the MS docs, never will. IMO Python shouldn't be in this business unless it can guarantee to do it safely. But it can't, so -1 from me. Java did get out of this business: What Java has that Python lacks (follow the link) is a way to "interrupt" a thread, and there's nothing that was possible with thread.stop() that isn't possible by building on interruption (although the places where people really want this are places where thread.stop() never worked anyway -- Java never had a gimmick as Draconian as Win32's TerminateThread() -- Java's thread.stop() was "stop if you can, but there are many reasons you may not be able to"). I'd be +1 on a thread interruption facility for Python, which amounts to a way to raise an exception in a different thread. But like Java's facility, it couldn't always guarantee the target thread would respond. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Tue Aug 21 06:05:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 22:05:12 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 9 Submitted By: Paul Moore (pmoore) >Assigned to: A.M. Kuchling (akuchling) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-20 22:05 Message: Logged In: YES user_id=31435 I'm not checking this in: I don't understand it, and it's been assigned to two distutils folks who declined to check it in for unrecorded reasons. Assigning to Andrew: please check it in or explain why not? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:04 Message: Logged In: YES user_id=12800 Assigning to Tim. Isn't this already in the Py2.2 tree? Can't we close this patch now? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:01 Message: Logged In: YES user_id=11375 Thomas, do you want to apply this patch or shall I do it? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Tue Aug 21 06:42:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 22:42:09 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From content-management@high-tech-communcations.com Tue Aug 21 08:08:17 2001 From: content-management@high-tech-communcations.com (Victor Black) Date: Tue, 21 Aug 2001 00:08:17 -0700 Subject: [Patches] New web utility Message-ID: <200108210708.f7L78HO01919@mail.high-tech-communications.com>

I noticed your email address on a list serve related to technology and web development.  With your permission, we
would like to send you information regarding new web tools and utilities based on your interests.  Please click the
following link and opt-in to our product updates and e-newsletter, click here: http://216.133.228.90/cm/

Cordially,

Victor Black
High-Tech-Communications.com

If you would like to be removed from our database, please click here: http://216.133.228.90/cm/remove.cgi

 

From noreply@sourceforge.net Tue Aug 21 07:55:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 23:55:36 -0700 Subject: [Patches] [ python-Patches-450702 ] zlibmodule ALLOW_THREADS update Message-ID: Patches item #450702, was opened at 2001-08-13 22:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: zlibmodule ALLOW_THREADS update Initial Comment: When using e.g. the gzip module in a threaded Python embedding (PyWX, pywx.idyll.org) all other Python threads halt, because no thread interleaving is done by the time-intensive commands in zlib.so. This leads to serious lags when compressing 5 MB files... I have wrapped all of the inflate and deflate commands in Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, which fixes this problem. Note that this fix is backwards compatible to 2.1, at least, as zlibmodule.c has not changed since then. As requested, a _context_ diff from the head of the current CVS tree is attached ;). ---------------------------------------------------------------------- >Comment By: Titus Brown (titus) Date: 2001-08-20 23:55 Message: Logged In: YES user_id=23486 One last patch: Alex Martelli pointed out that C functions do not automatically take on ownership of passed-in strings, and, under circumstances where multiple threads have access to the same namespace, thread A might be involved in a time-consuming command and thread B (now allowed to execute) could then delete the input string out from under it. Attached is the complete patch, this time including the appropriate INCREF and DECREF of the input string. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-17 10:10 Message: Logged In: YES user_id=23486 This new patch makes the zlibmodule reentrant by using a global zlib_lock. Also included is the addition of BEGIN/END_ALLOW_THREADS macros around the actual calls to compress/decompress data, which significantly improves the thread-friendliness of this module. Most of the code changes are simple rearrangements of the same old code to adapt it to the requirements of the ENTER and LEAVE_ZLIB macros, which create new blocks; thus, any code from which a 'return' was done had to be changed to exit only after LEAVE_ZLIB was called. Note that because zlib itself is re-entrant, we really only had to worry about making methods on de/compress objects reentrant. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 12:13 Message: Logged In: YES user_id=23486 N.B. I've found that zlib _is_ threadsafe. I still need to determine if the way in which objects are passed around in the zlibmodule.c can potentially cause problems; it seems like it can. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 09:06 Message: Logged In: YES user_id=23486 I think there may be a 2nd problem: I have to look into some of the Python calls used to transfer data around, but it may be possible for threads with access to the compression objects to retrieve data in an indeterminate state, i.e. mid-compression. Luckily a module-wide lock should take care of both this problem AND resolve threadsafety issues with zlib! I'll look into this & fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-14 07:21 Message: Logged In: YES user_id=21627 The patch looks good, however there is a major problem with the approach taken: zlib itself might not be threadsafe. Please try to find out whether zlib indeed is thread-safe; if it isn't, I think you need to add another lock to prevent multiple Python threads from accessing zlib simultaneously. You may want to take a look at _tkinter, which has similar code to prevent multiple Python threads from accessing Tk simultaneously. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 From noreply@sourceforge.net Tue Aug 21 12:47:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 Aug 2001 04:47:38 -0700 Subject: [Patches] [ python-Patches-453691 ] CGI: NEW: methods getfirst(), getlist() Message-ID: Patches item #453691, was opened at 2001-08-21 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453691&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tomas Styblo (tripiecz) Assigned to: Nobody/Anonymous (nobody) Summary: CGI: NEW: methods getfirst(), getlist() Initial Comment: This is updated version of my cgi.py patch #452174. The attached file 'pycgi.patch' modifies 'Doc/lib/libcgi.tex' and 'Lib/cgi.py'. It's based on current CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453691&group_id=5470 From noreply@sourceforge.net Tue Aug 21 12:49:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 Aug 2001 04:49:14 -0700 Subject: [Patches] [ python-Patches-452174 ] cgi: new methods: getfirst(), getlist() Message-ID: Patches item #452174, was opened at 2001-08-17 11:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: cgi: new methods: getfirst(), getlist() Initial Comment: I find very annoying the need to check whether a user checked one or more checkboxes in a form like this: Currently, I must do something like this: value = form.getvalue("item") if type(value) is type([]): # Multiple items checked. else: # One item checked. I added two methods to cgi.py that simplify and make CGI value processing much more readable and intuitive. The first method ALWAYS returns a single value. Even if more values of the same name were posted, this method always returns only the first one, as a string. scalar_value = form.getfirst("item") scalar_value is now: '1' The second method ALWAYS returns a list. If only one value was posted then the method returns a list which contains this one value. list_values = form.getlist("item") list_values is now: ['1', '2'] This allows me to write much more compact code like: for item in form.getlist("item"): do_something() Using the getfirst() method I don't need to worry about a malicious user posting two values in a query string where I expect only one value. Documentation says: "If the submitted form data contains more than one field with the same name, the object retrieved by "form[key]" is not a FieldStorage or MiniFieldStorage instance but a list of such instances. Similarly, in this situation, "form.getvalue(key)" would return a list of strings. If you expect this possibility (i.e., when your HTML form contains multiple fields with the same name), use the type() function to determine whether you have a single instance or a list of instances." That's IMHO wrong - one shouldn't count on a client to provide valid input. If it doesn't, the script crashes. That's bad. So I added these two very simple methods to the FieldStorage class. The patch is against version 2.6 of the cgi.py module. ---------------------------------------------------------------------- Comment By: Tomas Styblo (tripiecz) Date: 2001-08-21 04:49 Message: Logged In: YES user_id=295775 Updated version of this patch is #453691 2001-08-21. This entry is now obsolete. ---------------------------------------------------------------------- Comment By: Tomas Styblo (tripiecz) Date: 2001-08-18 13:28 Message: Logged In: YES user_id=295775 Yes, I am. I'll update also the documentation. Some English native speaker will have to review the result, though ;) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 10:56 Message: Logged In: YES user_id=6380 So are yo gonna upload a new patch or do I have to do everything myself? :-) ---------------------------------------------------------------------- Comment By: Tomas Styblo (tripiecz) Date: 2001-08-17 18:15 Message: Logged In: YES user_id=295775 Sorry for the anonymous posting, I had forgotten to login before I submitted the patch. Of course, you are absolutely true. That's quite a shame I have been completely unaware of this trap for all the months I've been using Python. Thanks for the correction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 11:28 Message: Logged In: YES user_id=6380 Nice idea, but I wouldn't use "default=[]" in the argument list. If the user modifies the list it returns, the default is permanently changed! I suggest that there's no need to allow the user to specify an alternate default for getlist(), so you can just delete this argument and say "return []" in the default case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 From noreply@sourceforge.net Tue Aug 21 12:55:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 Aug 2001 04:55:35 -0700 Subject: [Patches] [ python-Patches-453691 ] CGI: NEW: methods getfirst(), getlist() Message-ID: Patches item #453691, was opened at 2001-08-21 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453691&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tomas Styblo (tripiecz) >Assigned to: Guido van Rossum (gvanrossum) Summary: CGI: NEW: methods getfirst(), getlist() Initial Comment: This is updated version of my cgi.py patch #452174. The attached file 'pycgi.patch' modifies 'Doc/lib/libcgi.tex' and 'Lib/cgi.py'. It's based on current CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453691&group_id=5470 From noreply@sourceforge.net Tue Aug 21 15:17:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 Aug 2001 07:17:45 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 9 Submitted By: Paul Moore (pmoore) Assigned to: A.M. Kuchling (akuchling) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2001-08-21 07:17 Message: Logged In: YES user_id=113328 Thomas seems to be unavailable - I've had no response from him since before I submitted this patch. Can someone please apply this patch. Once this patch is in, there's a patch required to the bdist_wininst installer, which Thomas has promised. But until he reappears, this isn't going to happen. But this patch does *not* depend on Thomas' - so there is no reason to miss the 2.2 deadline because of that. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-20 22:05 Message: Logged In: YES user_id=31435 I'm not checking this in: I don't understand it, and it's been assigned to two distutils folks who declined to check it in for unrecorded reasons. Assigning to Andrew: please check it in or explain why not? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:04 Message: Logged In: YES user_id=12800 Assigning to Tim. Isn't this already in the Py2.2 tree? Can't we close this patch now? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:01 Message: Logged In: YES user_id=11375 Thomas, do you want to apply this patch or shall I do it? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Tue Aug 21 20:47:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 Aug 2001 12:47:03 -0700 Subject: [Patches] [ python-Patches-453914 ] bad example in pickle documentation Message-ID: Patches item #453914, was opened at 2001-08-21 12:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453914&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tomas Styblo (tripiecz) Assigned to: Nobody/Anonymous (nobody) Summary: bad example in pickle documentation Initial Comment: There's a bad example of pickle usage in the library reference. Some very hard to find bugs could emerge from that code. Here is the __getstate__() method from the example: 
def __getstate__(self):
    odict = self.__dict__
    del odict['fh']
    return odict
This code corrupts data of the instance that is being pickled, making it silently no longer usable. There's no warranty that pickled instances will not be used after they are pickled. The code should rather make a shallow copy of the self.__dict__ and then delete the filehandle from the copy. This makes the instance usable even after it's pickled. The appended patch modifies 'Doc/lib/libpickle.tex'. It's based on current CVS version of that file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453914&group_id=5470 From noreply@sourceforge.net Tue Aug 21 23:51:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 Aug 2001 15:51:00 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Wed Aug 22 00:05:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 Aug 2001 16:05:15 -0700 Subject: [Patches] [ python-Patches-441348 ] Allow jython to complete test_charmap Message-ID: Patches item #441348, was opened at 2001-07-14 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 Category: library Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: Allow jython to complete test_charmap Initial Comment: The repr of unicode strings in the output is different for jython. The attached patch allow jython to complete the test_charmapcodec test. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-21 16:05 Message: Logged In: YES user_id=12800 Look okay to me, although I haven't tried the patch. If the standard test suite continues to pass, then it should be okay to check this into the trunk. Note: don't merge this into the 2.2a2 branch. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:14 Message: Logged In: YES user_id=12800 Assigned to Barry for review. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:29 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 From noreply@sourceforge.net Wed Aug 22 00:06:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 Aug 2001 16:06:08 -0700 Subject: [Patches] [ python-Patches-442351 ] Copy of classes with __del_ in jython Message-ID: Patches item #442351, was opened at 2001-07-18 03:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442351&group_id=5470 Category: library Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: Copy of classes with __del_ in jython Initial Comment: The __del__ method is somewhat special in jython because it must exists when the instance is created. Adding a __del__ method to an existing instance have no effect in jython. This patch will ensure that the new copy will be created with a __del__ method if the source defined a __del__ method. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-21 16:06 Message: Logged In: YES user_id=12800 This one looks fine to me too. Same caveat with passing the standard test suite for CPython applies. Note: do not merge this into the 2.2a2 branch. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:12 Message: Logged In: YES user_id=12800 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442351&group_id=5470 From noreply@sourceforge.net Wed Aug 22 02:01:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 Aug 2001 18:01:59 -0700 Subject: [Patches] [ python-Patches-454041 ] Setup and distutils changes. Message-ID: Patches item #454041, was opened at 2001-08-21 18:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454041&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Setup and distutils changes. Initial Comment: The attached patches change setup.py and the distutils compiler modules to allow dynamically loaded modules that are built against shared libraries to be built with the appropriate runtime library search directories set as needed. The attached patches and a description of what they do follows: 1. uw7_setup.patch This patch modifies setup.py to: * have find_library_file() search for the directory where a given library file is lo- cated, and returns a tuple '(dirs, rt_dirs)' where 'dirs' is a possibly-empty list of additional directories and 'rt_dirs' is a possibly-empty list of directories to be searched at runtime. If the file couldn't be found at all, None is returned. * use the modified find_library_file() to set the runtime_library_dirs parameter to Extension() method so that the appropriate linker option to embed the runtime library directory search path in the dynamically load module will be gener- ated. Whether or not the option is generated is controlled by the distutils compiler class. * add the curses and terminfo library to the libraries searched when the readline module is built. 2. uw7_ccompiler.patch This patch modifies Lib/distutils/ccompiler.py as follows: * The runtime_library_dir_option() method was change so that it returns an empty list instead of raising the NotImplemented exception. This was done so that a reasonable default will be used for those systems that do not need to specify a runtime search path for libraries. It is possible that setup.py will determine that a directory will be needed to be searched at runtime, even if a particular system or compiler do not support or need to have a runtime directory search patch defined. In this case, the compiler class should return an empty list when runtime_library_dir_option() is called. * Changed how runtime_library_dir_option() is called. Instead of calling it once for each directory in the runtime_library_dirs list, it is called once, passing it the entire list of directories to be searched at runtime. This pushes the decision of how to format the option to the system specific compiler class. Some systems (UnixWare, for example) only allow a single -R option to be specified, followed by a colon (:) separated list of directories to search. * Added support for a new compiler class, USLCcompiler. This compiler class supports Unix System Labs style C compilers. UnixWare uses this compiler class. Sun's native compiler for Solaris use to be based on the Unix System Lab's C compiler. I don't know if this is still the case. 3. uw7_unixccompiler.patch This patch modifies Lib/distutils/unixccompier.py so that is no longer defines it's own version of runtime_library_dir_option(). Most system's that used this compiler do not need to specify a runtime directory search path via an ld option. 4. uw7_msvccompiler.patch and uw7_mwerkscompiler.patch These patches update Lib/distutils/msvccompiler.py and Lib/distutils/mwerkscompiler.py so that being passed something in runtime_library_dirs does not raise an exception. They will now print a warning message if runtime_library_dirs is not empty or None. They will return an empty list if runtime_library_dir_option() is called. 5. uw7_uslccompiler.patch This patch adds the USLCCompiler class. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454041&group_id=5470 From noreply@sourceforge.net Wed Aug 22 09:21:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 Aug 2001 01:21:37 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Guido van Rossum (gvanrossum) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-22 01:21 Message: Logged In: YES user_id=6380 Sending SIGINT may be easy, but that only covers the Unix side. Also, catching it requires more work, interfering with the existing signal handling, so this becomes A Project. (So, yes, the hard part is getting Python to process signals out of the main thread.) Thanks for the new patch! This is a step in the right direction. It came too late to be reviewed for 2.2a2, but I'll try to get it into 2.2a3. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-20 21:21 Message: Logged In: YES user_id=71210 Sending SIGINT to a thread is pretty easy. Is the hard part of killing a thread with signals getting python to process signals outside of the main thread? At any rate, I'm attaching a new patch that returns the thread id from start_new_thread, without any of the kill_thread() stuff. It includes a change to libthread.tex. For platforms I don't really know I just had them return -1 on failure and 0 on success so they at least run. o Solaris, pthreads, pth - returns thread id, tested o NT - returns thread id, (should work, haven't tested after removing kill) o SGI, BeOS - returns thread id, untested o wince, OS/2, LWP, cthread, foobar - returns -1 on failure, 0 on success ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 06:01 Message: Logged In: YES user_id=6380 Thanks to Tim for jogging my memory. I think an interruption facility should be a way to send an exception to a thread, similar to KeyboardInterrupt -- the thread can then decide what to do (and since exceptions can happen anyway, the safety guarantee is not violated -- if the application doesn't release locks on exceptions, it is already unsafe). One problem is that it's probably most important to be able to stop a thread while it's blocked for I/O (a socket connect() or recv() from a non-responding host is a typical example). Unfortunately, the only way to do that on Unix is to send a real signal to the thread. On Windows, I have no idea. Note that part of this patch would still be useful: start_new_thread() should return a thread-id. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-19 20:21 Message: Logged In: YES user_id=71210 While I would very much like to have full interruption functionality, I'm not sure how easily it could be done on all platforms. At the least it would be nice to have SOME sort of thread signalling. What guarantees about safety should python make? I've considered trying to add cleanup handlers to release interpreter locks and such, but didn't feel like putting that much effort into a patch that would likely be rejected anyway. I will look into adding cleanup routines if we can establish some requirements. I think I can do it in pthreads pretty easily. Dunno how easy the rest will be. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-19 14:24 Message: Logged In: YES user_id=31435 I've never called TerminateThread() on Win32, and given the dire wngs about it in the MS docs, never will. IMO Python shouldn't be in this business unless it can guarantee to do it safely. But it can't, so -1 from me. Java did get out of this business: What Java has that Python lacks (follow the link) is a way to "interrupt" a thread, and there's nothing that was possible with thread.stop() that isn't possible by building on interruption (although the places where people really want this are places where thread.stop() never worked anyway -- Java never had a gimmick as Draconian as Win32's TerminateThread() -- Java's thread.stop() was "stop if you can, but there are many reasons you may not be able to"). I'd be +1 on a thread interruption facility for Python, which amounts to a way to raise an exception in a different thread. But like Java's facility, it couldn't always guarantee the target thread would respond. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Wed Aug 22 09:31:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 Aug 2001 01:31:39 -0700 Subject: [Patches] [ python-Patches-450981 ] Add module docstring - xmlrpc Message-ID: Patches item #450981, was opened at 2001-08-14 15:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450981&group_id=5470 >Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add module docstring - xmlrpc Initial Comment: Add module docstring - xmlrpc ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450981&group_id=5470 From noreply@sourceforge.net Wed Aug 22 09:31:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 Aug 2001 01:31:56 -0700 Subject: [Patches] [ python-Patches-450980 ] Add module docstring - sre*, re Message-ID: Patches item #450980, was opened at 2001-08-14 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450980&group_id=5470 >Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add module docstring - sre*, re Initial Comment: Add module docstring - sre*, re ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450980&group_id=5470 From noreply@sourceforge.net Wed Aug 22 09:32:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 Aug 2001 01:32:10 -0700 Subject: [Patches] [ python-Patches-450979 ] Add module docstring - imputil Message-ID: Patches item #450979, was opened at 2001-08-14 15:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450979&group_id=5470 >Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add module docstring - imputil Initial Comment: Add module docstring - imputil ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450979&group_id=5470 From noreply@sourceforge.net Wed Aug 22 22:28:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 Aug 2001 14:28:36 -0700 Subject: [Patches] [ python-Patches-421893 ] Cleanup GC API Message-ID: Patches item #421893, was opened at 2001-05-06 14:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Guido van Rossum (gvanrossum) Summary: Cleanup GC API Initial Comment: This patch adds three new APIs: PyObject_GC_New PyObject_GC_NewVar PyObject_GC_Resize PyObject_GC_Del and renames PyObject_GC_Init and PyObject_GC_Fini to: PyObject_GC_Track PyObject_GC_Ignore respectively. Objects that wish to be tracked by the collector must use these new APIs. Many more details about the GC implementation are hidden inside gcmodule.c. There seems to be no change in performance. Note that PyObject_GC_{New,NewVar} automatically adds the object to the GC lists. There is no need to call PyObject_GC_Track. PyObject_GC_Del automatically removes the object from the GC list but usually you want to call PyObject_GC_Ignore yourself (DECREFs can end up running arbitrary code). It should be more difficult to corrupt the GC linked lists now. Also, you can now call PyObject_GC_Ignore on objects that you know will not create RCs. The _weakref module does this. Previously, every object that had the GC type flag set and could be found by using tp_traverse had to be in a GC linked list. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-22 14:28 Message: Logged In: YES user_id=31435 I want to see this patch go in: it affords some nice simplifications in many places, so should make the code easier to maintain and to change. Some gripes: + Most of the new functions don't appear to be documented at all, except in that they're mentioned in passing by the docs for other new functions: PyObject_GC_New, PyObject_GC_NewVar, PyObject_GC_Resize, PyObject_GC_Del. + Unlike the old Init/Fini, the new Track/Ignore don't "sound like" matching brackets. TrackOn/TrackOff, TrackStart/TrackStop, Track/UnTrack, ... would be better for this reason. I draw the line at PyObject_GC_New vs PyObject_GC_Old, though . + Overall, and despite the pain it causes, it's probably better to let GC continue to get triggered by "deallocation deficit", rather than moving the prod into the eval loop. Guido says you two already discussed that, so I won't belabor it here. I'll note that one consequence of the current policy is that GC glitches got triggered during compilation, and mysterious as those were, that they *did* happen during compilation allowed to rule out huge pieces of the Python runtime code; it was significantly harder to pin the blame for glitches that didn't happen until runtime. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 12:59 Message: Logged In: YES user_id=35752 I've brought the patch up to date. I'm not sure if we really need this patch. The current approach works okay. I think this patch improves things since more details about the GC implementation are hidden. This would give us more freedom to change the implementation in the future. Also, I think the patch makes it easier for extension types to support GC. The patch is somewhat backwards compatible now. Types that use the old interface will still compile but will not be GCed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:32 Message: Logged In: YES user_id=6380 Neil, do we still need this? I've marked it out-of-date because I'm sure that it won't apply cleanly any more. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-16 09:25 Message: Logged In: YES user_id=6380 I think I know a way to fix the incompatibility, by switching to a different flag bit. I'll try to work this into the descr-branch code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 10:13 Message: Logged In: YES user_id=21627 I have two problems with this patch: 1. It comes with no documentation. 2. It breaks existing third-party modules which use the GC API as defined in Python 2. Consequently, I recommend rejection of the patch in its current form. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 From noreply@sourceforge.net Thu Aug 23 05:46:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 Aug 2001 21:46:36 -0700 Subject: [Patches] [ python-Patches-454041 ] Setup and distutils changes. Message-ID: Patches item #454041, was opened at 2001-08-21 18:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454041&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Setup and distutils changes. Initial Comment: The attached patches change setup.py and the distutils compiler modules to allow dynamically loaded modules that are built against shared libraries to be built with the appropriate runtime library search directories set as needed. The attached patches and a description of what they do follows: 1. uw7_setup.patch This patch modifies setup.py to: * have find_library_file() search for the directory where a given library file is lo- cated, and returns a tuple '(dirs, rt_dirs)' where 'dirs' is a possibly-empty list of additional directories and 'rt_dirs' is a possibly-empty list of directories to be searched at runtime. If the file couldn't be found at all, None is returned. * use the modified find_library_file() to set the runtime_library_dirs parameter to Extension() method so that the appropriate linker option to embed the runtime library directory search path in the dynamically load module will be gener- ated. Whether or not the option is generated is controlled by the distutils compiler class. * add the curses and terminfo library to the libraries searched when the readline module is built. 2. uw7_ccompiler.patch This patch modifies Lib/distutils/ccompiler.py as follows: * The runtime_library_dir_option() method was change so that it returns an empty list instead of raising the NotImplemented exception. This was done so that a reasonable default will be used for those systems that do not need to specify a runtime search path for libraries. It is possible that setup.py will determine that a directory will be needed to be searched at runtime, even if a particular system or compiler do not support or need to have a runtime directory search patch defined. In this case, the compiler class should return an empty list when runtime_library_dir_option() is called. * Changed how runtime_library_dir_option() is called. Instead of calling it once for each directory in the runtime_library_dirs list, it is called once, passing it the entire list of directories to be searched at runtime. This pushes the decision of how to format the option to the system specific compiler class. Some systems (UnixWare, for example) only allow a single -R option to be specified, followed by a colon (:) separated list of directories to search. * Added support for a new compiler class, USLCcompiler. This compiler class supports Unix System Labs style C compilers. UnixWare uses this compiler class. Sun's native compiler for Solaris use to be based on the Unix System Lab's C compiler. I don't know if this is still the case. 3. uw7_unixccompiler.patch This patch modifies Lib/distutils/unixccompier.py so that is no longer defines it's own version of runtime_library_dir_option(). Most system's that used this compiler do not need to specify a runtime directory search path via an ld option. 4. uw7_msvccompiler.patch and uw7_mwerkscompiler.patch These patches update Lib/distutils/msvccompiler.py and Lib/distutils/mwerkscompiler.py so that being passed something in runtime_library_dirs does not raise an exception. They will now print a warning message if runtime_library_dirs is not empty or None. They will return an empty list if runtime_library_dir_option() is called. 5. uw7_uslccompiler.patch This patch adds the USLCCompiler class. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-08-22 21:46 Message: Logged In: YES user_id=8500 A new version of the setup.py patch, uw7_setup_2.patch has been uploaded. This takes info account the recent change to setup.py in regards to the bsddb module. Please use this patch in place of uw7_setup_2.patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454041&group_id=5470 From noreply@sourceforge.net Thu Aug 23 13:59:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 Aug 2001 05:59:30 -0700 Subject: [Patches] [ python-Patches-454553 ] Content-Type header for ftp url Message-ID: Patches item #454553, was opened at 2001-08-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Content-Type header for ftp url Initial Comment: This patch changes urllib.URLOpener.open_ftp: A Content-Type header is included when the MIME type can be guessed via mimetypes.guess_type. A patch to the documentation is included. Example: >>> import urllib >>> urllib.urlopen ("ftp://ftp.python.org/pub/python/2.2/Python- 2.2a2.tgz").info().headers ['Content-Type: application/x-tar\n', 'Content-Length: 5980204\n'] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 From noreply@sourceforge.net Thu Aug 23 14:38:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 Aug 2001 06:38:29 -0700 Subject: [Patches] [ python-Patches-454553 ] Content-Type header for ftp url Message-ID: Patches item #454553, was opened at 2001-08-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: Content-Type header for ftp url Initial Comment: This patch changes urllib.URLOpener.open_ftp: A Content-Type header is included when the MIME type can be guessed via mimetypes.guess_type. A patch to the documentation is included. Example: >>> import urllib >>> urllib.urlopen ("ftp://ftp.python.org/pub/python/2.2/Python- 2.2a2.tgz").info().headers ['Content-Type: application/x-tar\n', 'Content-Length: 5980204\n'] ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 06:38 Message: Logged In: YES user_id=6380 Thanks! Applied to CVS (with minimal changes). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 From noreply@sourceforge.net Thu Aug 23 15:01:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 Aug 2001 07:01:06 -0700 Subject: [Patches] [ python-Patches-454553 ] Content-Type header for ftp url Message-ID: Patches item #454553, was opened at 2001-08-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 Category: library Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: Content-Type header for ftp url Initial Comment: This patch changes urllib.URLOpener.open_ftp: A Content-Type header is included when the MIME type can be guessed via mimetypes.guess_type. A patch to the documentation is included. Example: >>> import urllib >>> urllib.urlopen ("ftp://ftp.python.org/pub/python/2.2/Python- 2.2a2.tgz").info().headers ['Content-Type: application/x-tar\n', 'Content-Length: 5980204\n'] ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-08-23 07:01 Message: Logged In: YES user_id=89016 Equivalent changes should probably be made to urllib2.FTPHandler.ftp_open too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 06:38 Message: Logged In: YES user_id=6380 Thanks! Applied to CVS (with minimal changes). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 From noreply@sourceforge.net Thu Aug 23 15:03:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 Aug 2001 07:03:45 -0700 Subject: [Patches] [ python-Patches-420753 ] Patch for bug #420725 urllib MIME header Message-ID: Patches item #420753, was opened at 2001-05-02 09:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420753&group_id=5470 Category: library Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for bug #420725 urllib MIME header Initial Comment: Fixes the bug #420725. One open issue is what to do when the script doesn't have permission to call os.stat on the file. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-08-23 07:03 Message: Logged In: YES user_id=89016 Equivalent changes should probably be made to urllib2.FileHandler.file_open too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:45 Message: Logged In: YES user_id=6380 Closed, applied. (There's no need to open a separate patch to fix a reported bug -- please just attach the fix to the bug report.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420753&group_id=5470 From noreply@sourceforge.net Thu Aug 23 15:33:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 Aug 2001 07:33:13 -0700 Subject: [Patches] [ python-Patches-454553 ] Content-Type header for ftp url Message-ID: Patches item #454553, was opened at 2001-08-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 Category: library Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: Content-Type header for ftp url Initial Comment: This patch changes urllib.URLOpener.open_ftp: A Content-Type header is included when the MIME type can be guessed via mimetypes.guess_type. A patch to the documentation is included. Example: >>> import urllib >>> urllib.urlopen ("ftp://ftp.python.org/pub/python/2.2/Python- 2.2a2.tgz").info().headers ['Content-Type: application/x-tar\n', 'Content-Length: 5980204\n'] ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 07:33 Message: Logged In: YES user_id=6380 Feel free to contribute a patch. (Does it do content-types for local files yet?) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-23 07:01 Message: Logged In: YES user_id=89016 Equivalent changes should probably be made to urllib2.FTPHandler.ftp_open too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 06:38 Message: Logged In: YES user_id=6380 Thanks! Applied to CVS (with minimal changes). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 From noreply@sourceforge.net Thu Aug 23 20:00:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 Aug 2001 12:00:10 -0700 Subject: [Patches] [ python-Patches-441348 ] Allow jython to complete test_charmap Message-ID: Patches item #441348, was opened at 2001-07-14 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 Category: library Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Allow jython to complete test_charmap Initial Comment: The repr of unicode strings in the output is different for jython. The attached patch allow jython to complete the test_charmapcodec test. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-08-23 12:00 Message: Logged In: YES user_id=4201 Applied to test_charmapcodec.py: 1.5; ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-21 16:05 Message: Logged In: YES user_id=12800 Look okay to me, although I haven't tried the patch. If the standard test suite continues to pass, then it should be okay to check this into the trunk. Note: don't merge this into the 2.2a2 branch. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:14 Message: Logged In: YES user_id=12800 Assigned to Barry for review. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:29 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 From noreply@sourceforge.net Thu Aug 23 21:57:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 Aug 2001 13:57:34 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: distutils Group: None Status: Open >Resolution: Accepted Priority: 9 Submitted By: Paul Moore (pmoore) Assigned to: A.M. Kuchling (akuchling) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2001-08-23 13:57 Message: Logged In: YES user_id=14422 OK, I've checked in the patch. Thanks Paul, sorry for the delay. Because of the changes to wininst waiting on Thomas Heller, I'm NOT closing this patch yet. If this violates policy (patch applied means close it?), howl at me and I'll close it. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2001-08-21 07:17 Message: Logged In: YES user_id=113328 Thomas seems to be unavailable - I've had no response from him since before I submitted this patch. Can someone please apply this patch. Once this patch is in, there's a patch required to the bdist_wininst installer, which Thomas has promised. But until he reappears, this isn't going to happen. But this patch does *not* depend on Thomas' - so there is no reason to miss the 2.2 deadline because of that. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-20 22:05 Message: Logged In: YES user_id=31435 I'm not checking this in: I don't understand it, and it's been assigned to two distutils folks who declined to check it in for unrecorded reasons. Assigning to Andrew: please check it in or explain why not? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:04 Message: Logged In: YES user_id=12800 Assigning to Tim. Isn't this already in the Py2.2 tree? Can't we close this patch now? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:01 Message: Logged In: YES user_id=11375 Thomas, do you want to apply this patch or shall I do it? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Thu Aug 23 22:54:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 Aug 2001 14:54:19 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: distutils Group: None Status: Open Resolution: Accepted Priority: 9 Submitted By: Paul Moore (pmoore) >Assigned to: Greg Ward (gward) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-23 14:54 Message: Logged In: YES user_id=31435 No violation of policy, but since you're leaving a Priority 9 patch Open, I'm assigning it to you so it doesn't show up as a high-priority nag in AMK's mailbox. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-23 13:57 Message: Logged In: YES user_id=14422 OK, I've checked in the patch. Thanks Paul, sorry for the delay. Because of the changes to wininst waiting on Thomas Heller, I'm NOT closing this patch yet. If this violates policy (patch applied means close it?), howl at me and I'll close it. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2001-08-21 07:17 Message: Logged In: YES user_id=113328 Thomas seems to be unavailable - I've had no response from him since before I submitted this patch. Can someone please apply this patch. Once this patch is in, there's a patch required to the bdist_wininst installer, which Thomas has promised. But until he reappears, this isn't going to happen. But this patch does *not* depend on Thomas' - so there is no reason to miss the 2.2 deadline because of that. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-20 22:05 Message: Logged In: YES user_id=31435 I'm not checking this in: I don't understand it, and it's been assigned to two distutils folks who declined to check it in for unrecorded reasons. Assigning to Andrew: please check it in or explain why not? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:04 Message: Logged In: YES user_id=12800 Assigning to Tim. Isn't this already in the Py2.2 tree? Can't we close this patch now? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:01 Message: Logged In: YES user_id=11375 Thomas, do you want to apply this patch or shall I do it? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Thu Aug 23 23:23:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 Aug 2001 15:23:27 -0700 Subject: [Patches] [ python-Patches-454743 ] PyString_FromFormat() Message-ID: Patches item #454743, was opened at 2001-08-23 15:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454743&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Guido van Rossum (gvanrossum) Summary: PyString_FromFormat() Initial Comment: This patch adds two new C API functions PyString_FromFormat() and PyString_FromFormatV() which create a dynamically sized char buffer of the right size based on the format string and the arguments. No more hardcoded buffer lengths for sprintf() and no more repr truncation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454743&group_id=5470 From noreply@sourceforge.net Fri Aug 24 01:26:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 Aug 2001 17:26:19 -0700 Subject: [Patches] [ python-Patches-454790 ] Have getopt handle optional short args Message-ID: Patches item #454790, was opened at 2001-08-23 17:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454790&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Have getopt handle optional short args Initial Comment: The GNU getopt implementation allows optional args to short arguments - two colons mean an option takes an optional arg; if there is text in the current argv-element, it is returned in optarg, otherwise optarg is set to zero. The attached patch implements this behaviour. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454790&group_id=5470 From noreply@sourceforge.net Fri Aug 24 13:58:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 Aug 2001 05:58:24 -0700 Subject: [Patches] [ python-Patches-454553 ] Content-Type header for ftp url Message-ID: Patches item #454553, was opened at 2001-08-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 Category: library Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: Content-Type header for ftp url Initial Comment: This patch changes urllib.URLOpener.open_ftp: A Content-Type header is included when the MIME type can be guessed via mimetypes.guess_type. A patch to the documentation is included. Example: >>> import urllib >>> urllib.urlopen ("ftp://ftp.python.org/pub/python/2.2/Python- 2.2a2.tgz").info().headers ['Content-Type: application/x-tar\n', 'Content-Length: 5980204\n'] ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-08-24 05:58 Message: Logged In: YES user_id=89016 > Feel free to contribute a patch. The new patch adds the same functionality to urllib2. > (Does it do content-types for local files yet?) I don't know. Local files don't seem work: >>> import urllib2 >>> urllib2.urlopen("PLAN.txt").info ().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 316, in open type_ = req.get_type() File "/usr/local/lib/python2.2/urllib2.py", line 220, in get_type raise ValueError, "unknown url type: %s" % self.__original ValueError: unknown url type: PLAN.txt >>> urllib2.urlopen("file://PLAN.txt").info().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 318, in open '_open', req) File "/usr/local/lib/python2.2/urllib2.py", line 297, in _call_chain result = func(*args) File "/usr/local/lib/python2.2/urllib2.py", line 905, in file_open return self.open_local_file(req) File "/usr/local/lib/python2.2/urllib2.py", line 924, in open_local_file if not host or \ socket.gaierror: (-2, 'Name or service not known') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 07:33 Message: Logged In: YES user_id=6380 Feel free to contribute a patch. (Does it do content-types for local files yet?) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-23 07:01 Message: Logged In: YES user_id=89016 Equivalent changes should probably be made to urllib2.FTPHandler.ftp_open too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 06:38 Message: Logged In: YES user_id=6380 Thanks! Applied to CVS (with minimal changes). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 From noreply@sourceforge.net Fri Aug 24 14:12:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 Aug 2001 06:12:49 -0700 Subject: [Patches] [ python-Patches-454553 ] Content-Type header for ftp url Message-ID: Patches item #454553, was opened at 2001-08-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 Category: library Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: Content-Type header for ftp url Initial Comment: This patch changes urllib.URLOpener.open_ftp: A Content-Type header is included when the MIME type can be guessed via mimetypes.guess_type. A patch to the documentation is included. Example: >>> import urllib >>> urllib.urlopen ("ftp://ftp.python.org/pub/python/2.2/Python- 2.2a2.tgz").info().headers ['Content-Type: application/x-tar\n', 'Content-Length: 5980204\n'] ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 06:12 Message: Logged In: YES user_id=6380 Thanks for the second patch! It seems urllib2 accepts these forms of file URLs: "file:PLAN.txt", or "file://tmp/diff.txt". I am not sure that "file://PLAN.txt" is supposed to work -- that would suggest the hostname is "PLAN.txt". ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-24 05:58 Message: Logged In: YES user_id=89016 > Feel free to contribute a patch. The new patch adds the same functionality to urllib2. > (Does it do content-types for local files yet?) I don't know. Local files don't seem work: >>> import urllib2 >>> urllib2.urlopen("PLAN.txt").info ().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 316, in open type_ = req.get_type() File "/usr/local/lib/python2.2/urllib2.py", line 220, in get_type raise ValueError, "unknown url type: %s" % self.__original ValueError: unknown url type: PLAN.txt >>> urllib2.urlopen("file://PLAN.txt").info().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 318, in open '_open', req) File "/usr/local/lib/python2.2/urllib2.py", line 297, in _call_chain result = func(*args) File "/usr/local/lib/python2.2/urllib2.py", line 905, in file_open return self.open_local_file(req) File "/usr/local/lib/python2.2/urllib2.py", line 924, in open_local_file if not host or \ socket.gaierror: (-2, 'Name or service not known') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 07:33 Message: Logged In: YES user_id=6380 Feel free to contribute a patch. (Does it do content-types for local files yet?) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-23 07:01 Message: Logged In: YES user_id=89016 Equivalent changes should probably be made to urllib2.FTPHandler.ftp_open too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 06:38 Message: Logged In: YES user_id=6380 Thanks! Applied to CVS (with minimal changes). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 From noreply@sourceforge.net Fri Aug 24 14:17:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 Aug 2001 06:17:45 -0700 Subject: [Patches] [ python-Patches-454553 ] Content-Type header for ftp url Message-ID: Patches item #454553, was opened at 2001-08-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 Category: library Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: Content-Type header for ftp url Initial Comment: This patch changes urllib.URLOpener.open_ftp: A Content-Type header is included when the MIME type can be guessed via mimetypes.guess_type. A patch to the documentation is included. Example: >>> import urllib >>> urllib.urlopen ("ftp://ftp.python.org/pub/python/2.2/Python- 2.2a2.tgz").info().headers ['Content-Type: application/x-tar\n', 'Content-Length: 5980204\n'] ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 06:17 Message: Logged In: YES user_id=6380 I meant "file:/tmp/diff.txt". Sorry for the confusion!!! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 06:12 Message: Logged In: YES user_id=6380 Thanks for the second patch! It seems urllib2 accepts these forms of file URLs: "file:PLAN.txt", or "file://tmp/diff.txt". I am not sure that "file://PLAN.txt" is supposed to work -- that would suggest the hostname is "PLAN.txt". ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-24 05:58 Message: Logged In: YES user_id=89016 > Feel free to contribute a patch. The new patch adds the same functionality to urllib2. > (Does it do content-types for local files yet?) I don't know. Local files don't seem work: >>> import urllib2 >>> urllib2.urlopen("PLAN.txt").info ().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 316, in open type_ = req.get_type() File "/usr/local/lib/python2.2/urllib2.py", line 220, in get_type raise ValueError, "unknown url type: %s" % self.__original ValueError: unknown url type: PLAN.txt >>> urllib2.urlopen("file://PLAN.txt").info().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 318, in open '_open', req) File "/usr/local/lib/python2.2/urllib2.py", line 297, in _call_chain result = func(*args) File "/usr/local/lib/python2.2/urllib2.py", line 905, in file_open return self.open_local_file(req) File "/usr/local/lib/python2.2/urllib2.py", line 924, in open_local_file if not host or \ socket.gaierror: (-2, 'Name or service not known') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 07:33 Message: Logged In: YES user_id=6380 Feel free to contribute a patch. (Does it do content-types for local files yet?) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-23 07:01 Message: Logged In: YES user_id=89016 Equivalent changes should probably be made to urllib2.FTPHandler.ftp_open too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 06:38 Message: Logged In: YES user_id=6380 Thanks! Applied to CVS (with minimal changes). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 From noreply@sourceforge.net Fri Aug 24 17:42:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 Aug 2001 09:42:59 -0700 Subject: [Patches] [ python-Patches-454553 ] Content-Type header for ftp url Message-ID: Patches item #454553, was opened at 2001-08-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 Category: library Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: Content-Type header for ftp url Initial Comment: This patch changes urllib.URLOpener.open_ftp: A Content-Type header is included when the MIME type can be guessed via mimetypes.guess_type. A patch to the documentation is included. Example: >>> import urllib >>> urllib.urlopen ("ftp://ftp.python.org/pub/python/2.2/Python- 2.2a2.tgz").info().headers ['Content-Type: application/x-tar\n', 'Content-Length: 5980204\n'] ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-08-24 09:42 Message: Logged In: YES user_id=89016 This third patch adds the headers Content-Length and Last- Modified to local files for urllib2 too (patch #420753 did it for urllib.py). (Content-Type already works for local files) The formatting of the Last-Modified header is now done with rfc822.formatdate and rfc822.formatdate has been fixed to even work with a modified locale. (RFC1123 requires english day of week and month names, but rfc822.formatdate used time.strftime("%a %b") which returns locale aware names.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 06:17 Message: Logged In: YES user_id=6380 I meant "file:/tmp/diff.txt". Sorry for the confusion!!! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 06:12 Message: Logged In: YES user_id=6380 Thanks for the second patch! It seems urllib2 accepts these forms of file URLs: "file:PLAN.txt", or "file://tmp/diff.txt". I am not sure that "file://PLAN.txt" is supposed to work -- that would suggest the hostname is "PLAN.txt". ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-24 05:58 Message: Logged In: YES user_id=89016 > Feel free to contribute a patch. The new patch adds the same functionality to urllib2. > (Does it do content-types for local files yet?) I don't know. Local files don't seem work: >>> import urllib2 >>> urllib2.urlopen("PLAN.txt").info ().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 316, in open type_ = req.get_type() File "/usr/local/lib/python2.2/urllib2.py", line 220, in get_type raise ValueError, "unknown url type: %s" % self.__original ValueError: unknown url type: PLAN.txt >>> urllib2.urlopen("file://PLAN.txt").info().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 318, in open '_open', req) File "/usr/local/lib/python2.2/urllib2.py", line 297, in _call_chain result = func(*args) File "/usr/local/lib/python2.2/urllib2.py", line 905, in file_open return self.open_local_file(req) File "/usr/local/lib/python2.2/urllib2.py", line 924, in open_local_file if not host or \ socket.gaierror: (-2, 'Name or service not known') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 07:33 Message: Logged In: YES user_id=6380 Feel free to contribute a patch. (Does it do content-types for local files yet?) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-23 07:01 Message: Logged In: YES user_id=89016 Equivalent changes should probably be made to urllib2.FTPHandler.ftp_open too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 06:38 Message: Logged In: YES user_id=6380 Thanks! Applied to CVS (with minimal changes). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 From noreply@sourceforge.net Fri Aug 24 17:51:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 Aug 2001 09:51:15 -0700 Subject: [Patches] [ python-Patches-454553 ] Content-Type header for ftp url Message-ID: Patches item #454553, was opened at 2001-08-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 Category: library Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Jeremy Hylton (jhylton) Summary: Content-Type header for ftp url Initial Comment: This patch changes urllib.URLOpener.open_ftp: A Content-Type header is included when the MIME type can be guessed via mimetypes.guess_type. A patch to the documentation is included. Example: >>> import urllib >>> urllib.urlopen ("ftp://ftp.python.org/pub/python/2.2/Python- 2.2a2.tgz").info().headers ['Content-Type: application/x-tar\n', 'Content-Length: 5980204\n'] ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 09:51 Message: Logged In: YES user_id=6380 Jeremy, can you apply the 3rd patch? I'm running out of time -- still gotta pack for my trip... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-24 09:42 Message: Logged In: YES user_id=89016 This third patch adds the headers Content-Length and Last- Modified to local files for urllib2 too (patch #420753 did it for urllib.py). (Content-Type already works for local files) The formatting of the Last-Modified header is now done with rfc822.formatdate and rfc822.formatdate has been fixed to even work with a modified locale. (RFC1123 requires english day of week and month names, but rfc822.formatdate used time.strftime("%a %b") which returns locale aware names.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 06:17 Message: Logged In: YES user_id=6380 I meant "file:/tmp/diff.txt". Sorry for the confusion!!! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 06:12 Message: Logged In: YES user_id=6380 Thanks for the second patch! It seems urllib2 accepts these forms of file URLs: "file:PLAN.txt", or "file://tmp/diff.txt". I am not sure that "file://PLAN.txt" is supposed to work -- that would suggest the hostname is "PLAN.txt". ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-24 05:58 Message: Logged In: YES user_id=89016 > Feel free to contribute a patch. The new patch adds the same functionality to urllib2. > (Does it do content-types for local files yet?) I don't know. Local files don't seem work: >>> import urllib2 >>> urllib2.urlopen("PLAN.txt").info ().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 316, in open type_ = req.get_type() File "/usr/local/lib/python2.2/urllib2.py", line 220, in get_type raise ValueError, "unknown url type: %s" % self.__original ValueError: unknown url type: PLAN.txt >>> urllib2.urlopen("file://PLAN.txt").info().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 318, in open '_open', req) File "/usr/local/lib/python2.2/urllib2.py", line 297, in _call_chain result = func(*args) File "/usr/local/lib/python2.2/urllib2.py", line 905, in file_open return self.open_local_file(req) File "/usr/local/lib/python2.2/urllib2.py", line 924, in open_local_file if not host or \ socket.gaierror: (-2, 'Name or service not known') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 07:33 Message: Logged In: YES user_id=6380 Feel free to contribute a patch. (Does it do content-types for local files yet?) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-23 07:01 Message: Logged In: YES user_id=89016 Equivalent changes should probably be made to urllib2.FTPHandler.ftp_open too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 06:38 Message: Logged In: YES user_id=6380 Thanks! Applied to CVS (with minimal changes). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 From noreply@sourceforge.net Fri Aug 24 19:32:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 Aug 2001 11:32:18 -0700 Subject: [Patches] [ python-Patches-454743 ] PyString_FromFormat() Message-ID: Patches item #454743, was opened at 2001-08-23 15:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454743&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Guido van Rossum (gvanrossum) Summary: PyString_FromFormat() Initial Comment: This patch adds two new C API functions PyString_FromFormat() and PyString_FromFormatV() which create a dynamically sized char buffer of the right size based on the format string and the arguments. No more hardcoded buffer lengths for sprintf() and no more repr truncation. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-24 11:32 Message: Logged In: YES user_id=12800 Guido said "go for it"! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454743&group_id=5470 From noreply@sourceforge.net Fri Aug 24 21:00:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 Aug 2001 13:00:16 -0700 Subject: [Patches] [ python-Patches-455076 ] %b format support for string/unicode Message-ID: Patches item #455076, was opened at 2001-08-24 13:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455076&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Wilson (gvwilson) Assigned to: Nobody/Anonymous (nobody) Summary: %b format support for string/unicode Initial Comment: This patch adds "%b" formatting of integer and long integer values to string and unicode objects. A new built-in function 'bin()' (with behavior like 'oct()' and 'hex()') is also added. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455076&group_id=5470 From noreply@sourceforge.net Sat Aug 25 00:11:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 Aug 2001 16:11:46 -0700 Subject: [Patches] [ python-Patches-455137 ] Makes popen work with COMMAND.COM on WNT Message-ID: Patches item #455137, was opened at 2001-08-24 16:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455137&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Makes popen work with COMMAND.COM on WNT Initial Comment: This patches causes the Window's implementation of popen to always use the w9xpopen hack if the shell specified in ComSpec is COMMAND.COM. This fixes a bug where popen would not work if the user installed W2K over W9X (the install-over procedure does not change ComSpec). I also changed the CreateProcess exception to include the commandline used. I found it useful in my debugging so others might like it too. I also tried to make this patch work by checking if the shell's file OS is VOS_DOS or VOS_WINDOWS16. Unfortunately that doesn't work because COMMAND.COM doesn't have a version resource and we can't assume that it is 16-bit if it doesn't have one (bash doesn't either). So I think checking for names is the best that we can do for now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455137&group_id=5470 From noreply@sourceforge.net Sat Aug 25 02:53:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 Aug 2001 18:53:03 -0700 Subject: [Patches] [ python-Patches-455176 ] sys module feature patch - modify_argv() Message-ID: Patches item #455176, was opened at 2001-08-24 18:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455176&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: sys module feature patch - modify_argv() Initial Comment: Feature enhancment patch to sys module. (Python/sysmodule.c) modify_argv(string,[start],[amount]) Modify the absolute argv (process listing) elements of the python process. Element values are set to zero, then refilled if a replacement value is present. Note: sys.argv will not be changed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455176&group_id=5470 From noreply@sourceforge.net Sat Aug 25 12:24:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 25 Aug 2001 04:24:23 -0700 Subject: [Patches] [ python-Patches-455231 ] Python 2.2a2 -- OpenBSD a.out and ELF build fixes. Message-ID: Patches item #455231, was opened at 2001-08-25 04:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455231&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Guy (a7r) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.2a2 -- OpenBSD a.out and ELF build fixes. Initial Comment: Changes to configure.in and friends to support building on both a.out and ELF OpenBSD platforms (tested on i386 and PowerPC, respectively). Pretty straight forward; more of a cleanup than anything. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455231&group_id=5470 From noreply@sourceforge.net Sat Aug 25 16:03:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 25 Aug 2001 08:03:03 -0700 Subject: [Patches] [ python-Patches-401032 ] os.popen#.close() exit code under Windows enhancement Message-ID: Patches item #401032, was opened at 2000-07-31 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401032&group_id=5470 Category: core (C code) Group: None Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Bolen (db3l) Assigned to: Mark Hammond (mhammond) Summary: os.popen#.close() exit code under Windows enhancement Initial Comment: ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2001-08-25 08:03 Message: Logged In: YES user_id=14198 My last comment indicated I check the fix in, so cleaning up by marking "Fixed" ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2000-08-13 22:05 Message: Applied. ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2000-07-31 16:57 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401032&group_id=5470 From noreply@sourceforge.net Sat Aug 25 20:40:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 25 Aug 2001 12:40:31 -0700 Subject: [Patches] [ python-Patches-413766 ] Reimplementation of multifile.py Message-ID: Patches item #413766, was opened at 2001-04-04 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Barry Warsaw (bwarsaw) Summary: Reimplementation of multifile.py Initial Comment: This is a re-implementation of the stock multifile.py The main changes: 1. Efficiency: This version supports calling the read() method with an argument. (In many cases, I've found that reading a MultiFile line by line is just too slow --- remember multipart messages often contain large binary attachments.) This version performs reads on the underlying input stream in larger chunks as well, and uses a regular expression search to search for separator lines. 2. Buglets fixed The original version has a buglet regarding its handling of the newline which preceeds a separator line. According to RFC 2046, section 5.1.1 the newline preceeding a separator is part of the separator, not part of the preceeding content. The old version of multifile.py treats the newline as part of the content. Thus, it introduces a spurious empty line at the end of each content. Matching of the separators: RFC 2046, section 5.1.1 also states, that if the beginning of a line matches the separator, it is a separator. The old code ignores only trailing white space when looking for a separator line. This code ignores trailing anything on the separator line. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 12:40 Message: Logged In: YES user_id=45814 I just found an obscure but occasionally fatal bug. I'm attaching a new, fixed, version of multifile.py to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-11 08:30 Message: Logged In: YES user_id=45814 Oof. I wish I had found your mimelib a couple of weeks ago. :-) You'll notice I've also posted a patch to Mailman (SF#413752) which adds an option to filter MIME attachments to plain text (delete binary attachments, convert HTML to plain text, ...) To do that (without defining new interfaces) I subclassed MimeWriter --- it's a bit messy. Using mimelib probably would have/will be cleaner. The Mailman patch includes a text/{richtext,enriched} parser (same interface as HTMLParser) which you guys might be interested in. I'm about to head off for a (long) weekend of skiing, so I won't have a chance to look carefully at mimelib until next week. Do expect to hear from me then, though. -Jeff ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-04-10 22:13 Message: Logged In: YES user_id=12800 I will definitely look at this -- and soon -- but obviously not in time for the 2.1 release. Geoffrey, have you looked at mimelib (see url below)? My intent is to replace all the MIME handling stuff in the standard library with mimelib. I'm using mimelib extensively in Mailman, but I would love to get some additional outside feedback about it. E.g. how do you think your new multifile.py would fit in with mimelib, and how well do you think mimelib conforms to RFC 2046? http://barry.wooz.org/software/pyware.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:31 Message: Logged In: YES user_id=6380 Thanks. I'll assign this to Barry, who has been working on another replacement for multifile, so maybe he can review your contribution. Barry, please don't sit on this too long -- If you've no interest, please unassign it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-04 11:09 Message: Logged In: YES user_id=45814 PS. FWIW, This was developed and tested under python 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 From noreply@sourceforge.net Mon Aug 27 06:07:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 22:07:37 -0700 Subject: [Patches] [ python-Patches-455666 ] PyString_FromFormat() Message-ID: Patches item #455666, was opened at 2001-08-26 22:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455666&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 6 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyString_FromFormat() Initial Comment: Documentation for PyString_FromFormat() and PyString_FromFormatV() for the C API manual, including refcount information. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455666&group_id=5470 From noreply@sourceforge.net Mon Aug 27 06:08:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 22:08:38 -0700 Subject: [Patches] [ python-Patches-455666 ] PyString_FromFormat() Message-ID: Patches item #455666, was opened at 2001-08-26 22:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455666&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 6 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyString_FromFormat() Initial Comment: Documentation for PyString_FromFormat() and PyString_FromFormatV() for the C API manual, including refcount information. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-26 22:08 Message: Logged In: YES user_id=12800 Arg. I hate this interface. Really uploading the file this time. :( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455666&group_id=5470 From noreply@sourceforge.net Mon Aug 27 06:47:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 22:47:23 -0700 Subject: [Patches] [ python-Patches-455137 ] Makes popen work with COMMAND.COM on WNT Message-ID: Patches item #455137, was opened at 2001-08-24 16:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455137&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) >Assigned to: Tim Peters (tim_one) Summary: Makes popen work with COMMAND.COM on WNT Initial Comment: This patches causes the Window's implementation of popen to always use the w9xpopen hack if the shell specified in ComSpec is COMMAND.COM. This fixes a bug where popen would not work if the user installed W2K over W9X (the install-over procedure does not change ComSpec). I also changed the CreateProcess exception to include the commandline used. I found it useful in my debugging so others might like it too. I also tried to make this patch work by checking if the shell's file OS is VOS_DOS or VOS_WINDOWS16. Unfortunately that doesn't work because COMMAND.COM doesn't have a version resource and we can't assume that it is 16-bit if it doesn't have one (bash doesn't either). So I think checking for names is the best that we can do for now. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-26 22:47 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455137&group_id=5470 From noreply@sourceforge.net Mon Aug 27 07:31:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 23:31:58 -0700 Subject: [Patches] [ python-Patches-455675 ] PyConsole raw_input improvements Message-ID: Patches item #455675, was opened at 2001-08-26 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455675&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: PyConsole raw_input improvements Initial Comment: This patch addresses two drawbacks of the current behavior of raw_input() when running in the IDE: * The prompt string doesn't appear in the AskString dialog. * The result string isn't printed to stdout (it should, so that the session "looks like" it would when run under the Interpreter. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455675&group_id=5470 From noreply@sourceforge.net Mon Aug 27 07:39:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 23:39:13 -0700 Subject: [Patches] [ python-Patches-455137 ] Makes popen work with COMMAND.COM on WNT Message-ID: Patches item #455137, was opened at 2001-08-24 16:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455137&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Tim Peters (tim_one) Summary: Makes popen work with COMMAND.COM on WNT Initial Comment: This patches causes the Window's implementation of popen to always use the w9xpopen hack if the shell specified in ComSpec is COMMAND.COM. This fixes a bug where popen would not work if the user installed W2K over W9X (the install-over procedure does not change ComSpec). I also changed the CreateProcess exception to include the commandline used. I found it useful in my debugging so others might like it too. I also tried to make this patch work by checking if the shell's file OS is VOS_DOS or VOS_WINDOWS16. Unfortunately that doesn't work because COMMAND.COM doesn't have a version resource and we can't assume that it is 16-bit if it doesn't have one (bash doesn't either). So I think checking for names is the best that we can do for now. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-26 23:39 Message: Logged In: YES user_id=31435 Thanks! The indentation was screwy in spots, as if you used an editor set to move tab chars to multiple-of-4 columns. Repaired that, and checked in as Misc/ACKS; new revision: 1.108 Misc/NEWS; new revision: 1.214 Modules/posixmodule.c; new revision: 2.197 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-26 22:47 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455137&group_id=5470 From noreply@sourceforge.net Mon Aug 27 10:21:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 02:21:47 -0700 Subject: [Patches] [ python-Patches-455675 ] PyConsole raw_input improvements Message-ID: Patches item #455675, was opened at 2001-08-26 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455675&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: PyConsole raw_input improvements Initial Comment: This patch addresses two drawbacks of the current behavior of raw_input() when running in the IDE: * The prompt string doesn't appear in the AskString dialog. * The result string isn't printed to stdout (it should, so that the session "looks like" it would when run under the Interpreter. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-08-27 02:21 Message: Logged In: YES user_id=45365 Just in case the original poster is still tracking this patch: you forgot to attach the patch itself! (There's a nasty checkbox you have to check, just browsing to the file isn't good enough). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455675&group_id=5470 From noreply@sourceforge.net Mon Aug 27 15:09:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 07:09:50 -0700 Subject: [Patches] [ python-Patches-455769 ] small fixes for Tools/bgen Message-ID: Patches item #455769, was opened at 2001-08-27 07:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455769&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: small fixes for Tools/bgen Initial Comment: - Tests (in the 'if __name__ == '__main__': section) do not run because they try to 'import Generator' which is not defined. - Another test does not run because it uses Variable (int, 'x') instead of (int, 'x', InMode) - a small fix (replace ' inside a triple quoted string with \' to work around bugs with syntax coloring in emacs python mode - Fix a triple quoted string which actually started with 4 quotes ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455769&group_id=5470 From noreply@sourceforge.net Mon Aug 27 15:10:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 07:10:45 -0700 Subject: [Patches] [ python-Patches-455769 ] small fixes for Tools/bgen Message-ID: Patches item #455769, was opened at 2001-08-27 07:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455769&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Jack Jansen (jackjansen) Summary: small fixes for Tools/bgen Initial Comment: - Tests (in the 'if __name__ == '__main__': section) do not run because they try to 'import Generator' which is not defined. - Another test does not run because it uses Variable (int, 'x') instead of (int, 'x', InMode) - a small fix (replace ' inside a triple quoted string with \' to work around bugs with syntax coloring in emacs python mode - Fix a triple quoted string which actually started with 4 quotes ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-08-27 07:10 Message: Logged In: YES user_id=11105 Assigned to Jack ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455769&group_id=5470 From noreply@sourceforge.net Mon Aug 27 15:32:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 07:32:00 -0700 Subject: [Patches] [ python-Patches-455769 ] small fixes for Tools/bgen Message-ID: Patches item #455769, was opened at 2001-08-27 07:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455769&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Jack Jansen (jackjansen) Summary: small fixes for Tools/bgen Initial Comment: - Tests (in the 'if __name__ == '__main__': section) do not run because they try to 'import Generator' which is not defined. - Another test does not run because it uses Variable (int, 'x') instead of (int, 'x', InMode) - a small fix (replace ' inside a triple quoted string with \' to work around bugs with syntax coloring in emacs python mode - Fix a triple quoted string which actually started with 4 quotes ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-08-27 07:32 Message: Logged In: YES user_id=45365 They work fine. I checked them in, with one minor modification: I got rid of the "import FunctionGenerator as Generator" and in stead just use FunctionGenerator by its real name. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-08-27 07:10 Message: Logged In: YES user_id=11105 Assigned to Jack ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455769&group_id=5470 From noreply@sourceforge.net Mon Aug 27 20:23:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 12:23:28 -0700 Subject: [Patches] [ python-Patches-455666 ] PyString_FromFormat() Message-ID: Patches item #455666, was opened at 2001-08-26 22:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455666&group_id=5470 Category: documentation Group: None Status: Open >Resolution: Accepted Priority: 6 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyString_FromFormat() Initial Comment: Documentation for PyString_FromFormat() and PyString_FromFormatV() for the C API manual, including refcount information. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-27 12:23 Message: Logged In: YES user_id=3066 Please check this in. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-26 22:08 Message: Logged In: YES user_id=12800 Arg. I hate this interface. Really uploading the file this time. :( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455666&group_id=5470 From noreply@sourceforge.net Mon Aug 27 20:23:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 12:23:48 -0700 Subject: [Patches] [ python-Patches-455666 ] PyString_FromFormat() Message-ID: Patches item #455666, was opened at 2001-08-26 22:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455666&group_id=5470 Category: documentation Group: None Status: Open Resolution: Accepted Priority: 6 Submitted By: Barry Warsaw (bwarsaw) >Assigned to: Barry Warsaw (bwarsaw) Summary: PyString_FromFormat() Initial Comment: Documentation for PyString_FromFormat() and PyString_FromFormatV() for the C API manual, including refcount information. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-27 12:23 Message: Logged In: YES user_id=3066 Please check this in. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-26 22:08 Message: Logged In: YES user_id=12800 Arg. I hate this interface. Really uploading the file this time. :( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455666&group_id=5470 From noreply@sourceforge.net Mon Aug 27 20:30:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 12:30:31 -0700 Subject: [Patches] [ python-Patches-451538 ] L10n of pprint Message-ID: Patches item #451538, was opened at 2001-08-16 05:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451538&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Denis S. Otkidach (ods) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: L10n of pprint Initial Comment: Representation of strings with non-latin national characters is quite unreadable. Although we can use current locale to determine full set of printable character. This patch in combination with dysplay_hook allows to get native representation for 8-bit strings, including ones in dictionaries, lists and tuples. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-27 12:30 Message: Logged In: YES user_id=3066 I think this is OK; will think about it a little more tomorrow and make a decision. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451538&group_id=5470 From noreply@sourceforge.net Mon Aug 27 20:36:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 12:36:46 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-27 12:36 Message: Logged In: YES user_id=3066 \XXX{compiler_flag} should be \member{...} \PEP{236} should be \pep{236} "--" for an em dash in refa1.tex should be "---" The classdesc environments for the Compile and CommandCompiler classes in codeop should include the argument list for the constructors, or use classdesc* if the constructors should never be used. Please make these corrections and commit. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 15:21 Message: Logged In: YES user_id=31435 Just changed Resolution to Accepted, but should remain Open until the doc patch is processed too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 15:17 Message: Logged In: YES user_id=31435 Reassigned to Fred for the doc patch (and I deleted the other attachments). Checked in the rest (repair of PyEval_MergeCompilerFlags came in between): Lib/code.py; new revision: 1.17 Lib/codeop.py; new revision: 1.5 Misc/NEWS; new revision: 1.209 Python/bltinmodule.c; new revision: 2.228 This seems solid now so far as it goes, and, e.g., IDLE now "does the right thing" for __future__ statements by magic. I still need to teach doctest how to exploit it. Testing got artificially confused by a different bug (that new division doesn't propagate to 'eval'), so I'm going to fix that bug next and then get back to stressing this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 12:51 Message: Logged In: YES user_id=31435 I'm going to do this in pieces. First checked in a reworked version of __future__.py, and added verification to test___future__.py: Lib/__future__.py; new revision: 1.9 Lib/test/test___future__.py; new revision: 1.3 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 11:30 Message: Logged In: YES user_id=31435 Testing turned up bugs, and I'm fixing them. Gross example: the anonymous hex constant attached to nested_scopes in the patched __future__.py was actually the constant for the CO_GENERATOR flag, not the constant for the correct CO_NESTED flag. I've reworked the code to repair that, but also to make it harder for that to happen again; ideally, Python-level CO_xxx flags should be exported by a builtin C module, and so that Jeremy's pyassem.py can use them too (it's got its own hardcoded (re) definitions), but I'm not being that ambitious. The simplest thing that could possibly work is that a global search on, e.g., CO_NESTED, find its use and value in __future__.py too, so that's what I'm settling for. I'll check it in when it all works. That won't be this instant, but will certainly be today. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 03:59 Message: Logged In: YES user_id=6380 What's stopping this from being checked in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-16 22:34 Message: Logged In: YES user_id=31435 This is looking good! I think I know how to get doctest to use it too (to emulate the future settings of the doctest'ed module) -- which would remove an unpleasant wart in current CVS (doctest imports generators from __future__ now, despite that it doesn't use any generators; else test_generators.py would fail). Leaving assigned to me since Michael's on vacation now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-14 14:27 Message: Logged In: YES user_id=6656 I think this latest version actually compiles (ahem). As far as I'm concerned, the coding is now done. Also attach a first cut at some doc updates. Fred will definitely need to fiddle these to get them to compile (there's no latex here on the starship). I should probably do some test cases.. later. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-10 15:41 Message: Logged In: YES user_id=6656 Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly). No rest for the wicked: more docs and some tests still needed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Mon Aug 27 21:05:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 13:05:51 -0700 Subject: [Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells Message-ID: Patches item #449043, was opened at 2001-08-08 02:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 Category: library Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: supporting __future__ in simulated shells Initial Comment: This implements the short PEP I posted to python-dev last week. It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-08-27 13:05 Message: Logged In: YES user_id=6656 OK, checked in: lib/libcode.tex: 1.13 lib/libcodeop.tex: 1.4 lib/libfuncs.tex: 1.82 ref/refa1.tex: 1.6 & closed. Hope they compile! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-27 12:36 Message: Logged In: YES user_id=3066 \XXX{compiler_flag} should be \member{...} \PEP{236} should be \pep{236} "--" for an em dash in refa1.tex should be "---" The classdesc environments for the Compile and CommandCompiler classes in codeop should include the argument list for the constructors, or use classdesc* if the constructors should never be used. Please make these corrections and commit. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 15:21 Message: Logged In: YES user_id=31435 Just changed Resolution to Accepted, but should remain Open until the doc patch is processed too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 15:17 Message: Logged In: YES user_id=31435 Reassigned to Fred for the doc patch (and I deleted the other attachments). Checked in the rest (repair of PyEval_MergeCompilerFlags came in between): Lib/code.py; new revision: 1.17 Lib/codeop.py; new revision: 1.5 Misc/NEWS; new revision: 1.209 Python/bltinmodule.c; new revision: 2.228 This seems solid now so far as it goes, and, e.g., IDLE now "does the right thing" for __future__ statements by magic. I still need to teach doctest how to exploit it. Testing got artificially confused by a different bug (that new division doesn't propagate to 'eval'), so I'm going to fix that bug next and then get back to stressing this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 12:51 Message: Logged In: YES user_id=31435 I'm going to do this in pieces. First checked in a reworked version of __future__.py, and added verification to test___future__.py: Lib/__future__.py; new revision: 1.9 Lib/test/test___future__.py; new revision: 1.3 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-17 11:30 Message: Logged In: YES user_id=31435 Testing turned up bugs, and I'm fixing them. Gross example: the anonymous hex constant attached to nested_scopes in the patched __future__.py was actually the constant for the CO_GENERATOR flag, not the constant for the correct CO_NESTED flag. I've reworked the code to repair that, but also to make it harder for that to happen again; ideally, Python-level CO_xxx flags should be exported by a builtin C module, and so that Jeremy's pyassem.py can use them too (it's got its own hardcoded (re) definitions), but I'm not being that ambitious. The simplest thing that could possibly work is that a global search on, e.g., CO_NESTED, find its use and value in __future__.py too, so that's what I'm settling for. I'll check it in when it all works. That won't be this instant, but will certainly be today. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 03:59 Message: Logged In: YES user_id=6380 What's stopping this from being checked in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-16 22:34 Message: Logged In: YES user_id=31435 This is looking good! I think I know how to get doctest to use it too (to emulate the future settings of the doctest'ed module) -- which would remove an unpleasant wart in current CVS (doctest imports generators from __future__ now, despite that it doesn't use any generators; else test_generators.py would fail). Leaving assigned to me since Michael's on vacation now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-14 14:27 Message: Logged In: YES user_id=6656 I think this latest version actually compiles (ahem). As far as I'm concerned, the coding is now done. Also attach a first cut at some doc updates. Fred will definitely need to fiddle these to get them to compile (there's no latex here on the starship). I should probably do some test cases.. later. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-10 15:41 Message: Logged In: YES user_id=6656 Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly). No rest for the wicked: more docs and some tests still needed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 22:01 Message: Logged In: YES user_id=31435 Assigned to me. WIll look more closely later. Things that struck the eye at once: + _Feature.matches needs a docstring. + "<>" is deprecated; use "!=". + I think we need a way not to "or" in the caller's flags too; but you also think that, so this shouldn't be hard for us to reach agreement on . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-09 15:26 Message: Logged In: YES user_id=6656 New version. This one attaches knowledge of code flag and compile time bits to the _Feature objects in Lib/__future__.py. It also rewrites the docstrings in codeop.py; still pending: latex docs, updates to my PEP and possibly 236 (the __future__ one), sanity checking the arguments to __builtin__.compile(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 07:26 Message: Logged In: YES user_id=6380 Nice! Two questions: 1. Why the refactoring of codeop.py? 2. Shouldn't the built-in compile() do a sanity check on the flags it accepts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470 From noreply@sourceforge.net Mon Aug 27 21:19:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 13:19:01 -0700 Subject: [Patches] [ python-Patches-454553 ] Content-Type header for ftp url Message-ID: Patches item #454553, was opened at 2001-08-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 Category: library Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Jeremy Hylton (jhylton) Summary: Content-Type header for ftp url Initial Comment: This patch changes urllib.URLOpener.open_ftp: A Content-Type header is included when the MIME type can be guessed via mimetypes.guess_type. A patch to the documentation is included. Example: >>> import urllib >>> urllib.urlopen ("ftp://ftp.python.org/pub/python/2.2/Python- 2.2a2.tgz").info().headers ['Content-Type: application/x-tar\n', 'Content-Length: 5980204\n'] ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-08-27 13:19 Message: Logged In: YES user_id=31392 third patch applied (with explantion of rfc822.formatdate() change in its doc string rfc822.py: rev 1.60 urllib.py: rev 1.133 urllib2.py: rev 1.21 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 09:51 Message: Logged In: YES user_id=6380 Jeremy, can you apply the 3rd patch? I'm running out of time -- still gotta pack for my trip... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-24 09:42 Message: Logged In: YES user_id=89016 This third patch adds the headers Content-Length and Last- Modified to local files for urllib2 too (patch #420753 did it for urllib.py). (Content-Type already works for local files) The formatting of the Last-Modified header is now done with rfc822.formatdate and rfc822.formatdate has been fixed to even work with a modified locale. (RFC1123 requires english day of week and month names, but rfc822.formatdate used time.strftime("%a %b") which returns locale aware names.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 06:17 Message: Logged In: YES user_id=6380 I meant "file:/tmp/diff.txt". Sorry for the confusion!!! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-24 06:12 Message: Logged In: YES user_id=6380 Thanks for the second patch! It seems urllib2 accepts these forms of file URLs: "file:PLAN.txt", or "file://tmp/diff.txt". I am not sure that "file://PLAN.txt" is supposed to work -- that would suggest the hostname is "PLAN.txt". ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-24 05:58 Message: Logged In: YES user_id=89016 > Feel free to contribute a patch. The new patch adds the same functionality to urllib2. > (Does it do content-types for local files yet?) I don't know. Local files don't seem work: >>> import urllib2 >>> urllib2.urlopen("PLAN.txt").info ().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 316, in open type_ = req.get_type() File "/usr/local/lib/python2.2/urllib2.py", line 220, in get_type raise ValueError, "unknown url type: %s" % self.__original ValueError: unknown url type: PLAN.txt >>> urllib2.urlopen("file://PLAN.txt").info().headers Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib2.py", line 134, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.2/urllib2.py", line 318, in open '_open', req) File "/usr/local/lib/python2.2/urllib2.py", line 297, in _call_chain result = func(*args) File "/usr/local/lib/python2.2/urllib2.py", line 905, in file_open return self.open_local_file(req) File "/usr/local/lib/python2.2/urllib2.py", line 924, in open_local_file if not host or \ socket.gaierror: (-2, 'Name or service not known') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 07:33 Message: Logged In: YES user_id=6380 Feel free to contribute a patch. (Does it do content-types for local files yet?) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-08-23 07:01 Message: Logged In: YES user_id=89016 Equivalent changes should probably be made to urllib2.FTPHandler.ftp_open too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-23 06:38 Message: Logged In: YES user_id=6380 Thanks! Applied to CVS (with minimal changes). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454553&group_id=5470 From noreply@sourceforge.net Mon Aug 27 21:33:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 13:33:30 -0700 Subject: [Patches] [ python-Patches-431422 ] "print" not emitting POP_TOP Message-ID: Patches item #431422, was opened at 2001-06-08 08:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=431422&group_id=5470 Category: Parser/Compiler Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Shane Hathaway (hathawsh) Assigned to: Jeremy Hylton (jhylton) >Summary: "print" not emitting POP_TOP Initial Comment: The Python-based compiler module (in Tools) has a bug in the visitPrint() method of pycodegen.CodeGenerator. It does not emit a trailing POP_TOP instruction, which AFAICT it should emit only when outputting to a stream and there is a trailing comma (indicating no newline). I've attached the patch applied to Zope's RestrictedPython module; if there is anything incorrect about it please tell me right away. Otherwise please apply the patch to Tools/compiler/pycodgen.py. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:41 Message: Logged In: YES user_id=3066 Assigned to Jeremy since the compiler package is his. ---------------------------------------------------------------------- Comment By: Shane Hathaway (hathawsh) Date: 2001-06-22 11:41 Message: Logged In: YES user_id=16701 Oops, it turns out the patch is incorrect! POP_TOP should only be added to the *last* print node. Here are the revised visitPrint() and visitPrintnl() methods. This is what is being used in Zope now. def visitPrint(self, node, newline=0): self.set_lineno(node) if node.dest: self.visit(node.dest) for child in node.nodes: if node.dest: self.emit('DUP_TOP') self.visit(child) if node.dest: self.emit('ROT_TWO') self.emit('PRINT_ITEM_TO') else: self.emit('PRINT_ITEM') if node.dest and not newline: self.emit('POP_TOP') def visitPrintnl(self, node): self.visitPrint(node, 1) if node.dest: self.emit('PRINT_NEWLINE_TO') else: self.emit('PRINT_NEWLINE') ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=431422&group_id=5470 From noreply@sourceforge.net Mon Aug 27 21:34:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 13:34:05 -0700 Subject: [Patches] [ python-Patches-402780 ] SET_LINENO for augassign Message-ID: Patches item #402780, was opened at 2000-12-11 08:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402780&group_id=5470 Category: demos and tools Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Jeremy Hylton (jhylton) Summary: SET_LINENO for augassign Initial Comment: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:52 Message: Logged In: YES user_id=6380 Jeremy, there's no reason not to apply this, is there? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 00:59 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2000-12-11 08:05 Message: Line numbers are currently not set for augmented assignment statements for code compiled by Tools/compiler. Here is a one line fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402780&group_id=5470 From noreply@sourceforge.net Mon Aug 27 22:58:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 14:58:37 -0700 Subject: [Patches] [ python-Patches-402780 ] SET_LINENO for augassign Message-ID: Patches item #402780, was opened at 2000-12-11 08:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402780&group_id=5470 Category: demos and tools Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Jeremy Hylton (jhylton) Summary: SET_LINENO for augassign Initial Comment: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 08:52 Message: Logged In: YES user_id=6380 Jeremy, there's no reason not to apply this, is there? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 00:59 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2000-12-11 08:05 Message: Line numbers are currently not set for augmented assignment statements for code compiled by Tools/compiler. Here is a one line fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402780&group_id=5470 From noreply@sourceforge.net Mon Aug 27 22:58:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 14:58:37 -0700 Subject: [Patches] [ python-Patches-431422 ] "print" not emitting POP_TOP Message-ID: Patches item #431422, was opened at 2001-06-08 08:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=431422&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Shane Hathaway (hathawsh) Assigned to: Jeremy Hylton (jhylton) >Summary: "print" not emitting POP_TOP Initial Comment: The Python-based compiler module (in Tools) has a bug in the visitPrint() method of pycodegen.CodeGenerator. It does not emit a trailing POP_TOP instruction, which AFAICT it should emit only when outputting to a stream and there is a trailing comma (indicating no newline). I've attached the patch applied to Zope's RestrictedPython module; if there is anything incorrect about it please tell me right away. Otherwise please apply the patch to Tools/compiler/pycodgen.py. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:41 Message: Logged In: YES user_id=3066 Assigned to Jeremy since the compiler package is his. ---------------------------------------------------------------------- Comment By: Shane Hathaway (hathawsh) Date: 2001-06-22 11:41 Message: Logged In: YES user_id=16701 Oops, it turns out the patch is incorrect! POP_TOP should only be added to the *last* print node. Here are the revised visitPrint() and visitPrintnl() methods. This is what is being used in Zope now. def visitPrint(self, node, newline=0): self.set_lineno(node) if node.dest: self.visit(node.dest) for child in node.nodes: if node.dest: self.emit('DUP_TOP') self.visit(child) if node.dest: self.emit('ROT_TWO') self.emit('PRINT_ITEM_TO') else: self.emit('PRINT_ITEM') if node.dest and not newline: self.emit('POP_TOP') def visitPrintnl(self, node): self.visitPrint(node, 1) if node.dest: self.emit('PRINT_NEWLINE_TO') else: self.emit('PRINT_NEWLINE') ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=431422&group_id=5470 From noreply@sourceforge.net Tue Aug 28 01:31:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 17:31:39 -0700 Subject: [Patches] [ python-Patches-455966 ] Allow leading 0 in float/imag literals Message-ID: Patches item #455966, was opened at 2001-08-27 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455966&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: Allow leading 0 in float/imag literals Initial Comment: Many years ago I was baffled that "0e0" as a literal gave an error (it doesn't as a string argument to float), and I never got used to it. While fixing a bug earlier today, I noticed this comment in tokenizer.c: /* XXX This is broken! E.g., 09.9 should be accepted as float! */ 09.9 is accepted after the patch, but along with stuff that isn't so clear, like 0777j same as 777j. OTOH, even at that extreme, complex("0777j") returns 777j without this patch too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455966&group_id=5470 From noreply@sourceforge.net Tue Aug 28 03:31:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 19:31:39 -0700 Subject: [Patches] [ python-Patches-455666 ] PyString_FromFormat() Message-ID: Patches item #455666, was opened at 2001-08-26 22:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455666&group_id=5470 Category: documentation Group: None >Status: Closed Resolution: Accepted Priority: 6 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Barry Warsaw (bwarsaw) Summary: PyString_FromFormat() Initial Comment: Documentation for PyString_FromFormat() and PyString_FromFormatV() for the C API manual, including refcount information. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-27 19:31 Message: Logged In: YES user_id=12800 Applied. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-27 12:23 Message: Logged In: YES user_id=3066 Please check this in. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-26 22:08 Message: Logged In: YES user_id=12800 Arg. I hate this interface. Really uploading the file this time. :( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455666&group_id=5470 From noreply@sourceforge.net Wed Aug 29 09:39:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 Aug 2001 01:39:14 -0700 Subject: [Patches] [ python-Patches-435381 ] Distutils patches for OS/2+EMX support Message-ID: Patches item #435381, was opened at 2001-06-22 01:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: A.M. Kuchling (akuchling) Summary: Distutils patches for OS/2+EMX support Initial Comment: The attached patch file is against the code released with Python 2.1. The changes are included in the binary installation package of the OS/2+EMX port of Python 2.1 I released on June 17, 2001. With these changes, I have successfully built and installed the Numeric 20.0.0 extention, and created a bdist_dumb distribution package of it. The installed extention tests successfully using the supplied test routines. Particular items of note:- - OS/2 limits DLLs to 8.3 filenames :-( :-( - ld is not used to link, instead gcc is used with the -Zomf option which invokes the LINK386 linker native to OS/2 - I haven't made any attempt to merge cloned code back into the parent code where it would make sense, which I think is in a few places. Feedback appreciated. ---------------------------------------------------------------------- Comment By: Rene Liebscher (rliebscher) Date: 2001-08-29 01:39 Message: Logged In: YES user_id=28463 Would it be possible to subclass cygwinccomplier (as mingwcompiler does?) Or maybe create a better class structure like this GCCCompiler / \ / \ CygwinCCompiler EMXCCompiler / / MinGWCCompiler GCCCompiler would never be used directly by anyone, it only collects all common code. The other class would only configure the GCCCompiler class in their __init__ methods. (And maybe override some [small] methods if really necessary.) ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2001-08-12 04:01 Message: Logged In: YES user_id=250749 The only real change in this updated patch is the compiler optimisation switches in emxccompiler.py. No attempted merging of changes. Suggestions/advice in this regard sought. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:38 Message: Logged In: YES user_id=3066 The third item in the list of issues at the end of the initial comment indicates that the patch isn't ready for inclusion. Assigning to Greg Ward for review. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470 From noreply@sourceforge.net Wed Aug 29 18:47:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 Aug 2001 10:47:58 -0700 Subject: [Patches] [ python-Patches-421893 ] Cleanup GC API Message-ID: Patches item #421893, was opened at 2001-05-06 14:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Tim Peters (tim_one) Summary: Cleanup GC API Initial Comment: This patch adds three new APIs: PyObject_GC_New PyObject_GC_NewVar PyObject_GC_Resize PyObject_GC_Del and renames PyObject_GC_Init and PyObject_GC_Fini to: PyObject_GC_Track PyObject_GC_Ignore respectively. Objects that wish to be tracked by the collector must use these new APIs. Many more details about the GC implementation are hidden inside gcmodule.c. There seems to be no change in performance. Note that PyObject_GC_{New,NewVar} automatically adds the object to the GC lists. There is no need to call PyObject_GC_Track. PyObject_GC_Del automatically removes the object from the GC list but usually you want to call PyObject_GC_Ignore yourself (DECREFs can end up running arbitrary code). It should be more difficult to corrupt the GC linked lists now. Also, you can now call PyObject_GC_Ignore on objects that you know will not create RCs. The _weakref module does this. Previously, every object that had the GC type flag set and could be found by using tp_traverse had to be in a GC linked list. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-08-29 10:47 Message: Logged In: YES user_id=35752 Changes in this version: * Rename PyObject_GC_Ignore to PyObject_GC_UnTrack. * Documention new functions * Revert collection from inside ceval change. * Add TRACK/UNTRACK macros (should not be used by extensions otherwise modules compiled with a different WITH_CYCLE_GC setting will break). Are the TRACK/UNTRACK macros a good idea? I think they give a measurable speed increase. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-22 14:28 Message: Logged In: YES user_id=31435 I want to see this patch go in: it affords some nice simplifications in many places, so should make the code easier to maintain and to change. Some gripes: + Most of the new functions don't appear to be documented at all, except in that they're mentioned in passing by the docs for other new functions: PyObject_GC_New, PyObject_GC_NewVar, PyObject_GC_Resize, PyObject_GC_Del. + Unlike the old Init/Fini, the new Track/Ignore don't "sound like" matching brackets. TrackOn/TrackOff, TrackStart/TrackStop, Track/UnTrack, ... would be better for this reason. I draw the line at PyObject_GC_New vs PyObject_GC_Old, though . + Overall, and despite the pain it causes, it's probably better to let GC continue to get triggered by "deallocation deficit", rather than moving the prod into the eval loop. Guido says you two already discussed that, so I won't belabor it here. I'll note that one consequence of the current policy is that GC glitches got triggered during compilation, and mysterious as those were, that they *did* happen during compilation allowed to rule out huge pieces of the Python runtime code; it was significantly harder to pin the blame for glitches that didn't happen until runtime. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 12:59 Message: Logged In: YES user_id=35752 I've brought the patch up to date. I'm not sure if we really need this patch. The current approach works okay. I think this patch improves things since more details about the GC implementation are hidden. This would give us more freedom to change the implementation in the future. Also, I think the patch makes it easier for extension types to support GC. The patch is somewhat backwards compatible now. Types that use the old interface will still compile but will not be GCed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:32 Message: Logged In: YES user_id=6380 Neil, do we still need this? I've marked it out-of-date because I'm sure that it won't apply cleanly any more. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-16 09:25 Message: Logged In: YES user_id=6380 I think I know a way to fix the incompatibility, by switching to a different flag bit. I'll try to work this into the descr-branch code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 10:13 Message: Logged In: YES user_id=21627 I have two problems with this patch: 1. It comes with no documentation. 2. It breaks existing third-party modules which use the GC API as defined in Python 2. Consequently, I recommend rejection of the patch in its current form. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 From noreply@sourceforge.net Wed Aug 29 23:21:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 Aug 2001 15:21:56 -0700 Subject: [Patches] [ python-Patches-421893 ] Cleanup GC API Message-ID: Patches item #421893, was opened at 2001-05-06 14:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 Category: core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Cleanup GC API Initial Comment: This patch adds three new APIs: PyObject_GC_New PyObject_GC_NewVar PyObject_GC_Resize PyObject_GC_Del and renames PyObject_GC_Init and PyObject_GC_Fini to: PyObject_GC_Track PyObject_GC_Ignore respectively. Objects that wish to be tracked by the collector must use these new APIs. Many more details about the GC implementation are hidden inside gcmodule.c. There seems to be no change in performance. Note that PyObject_GC_{New,NewVar} automatically adds the object to the GC lists. There is no need to call PyObject_GC_Track. PyObject_GC_Del automatically removes the object from the GC list but usually you want to call PyObject_GC_Ignore yourself (DECREFs can end up running arbitrary code). It should be more difficult to corrupt the GC linked lists now. Also, you can now call PyObject_GC_Ignore on objects that you know will not create RCs. The _weakref module does this. Previously, every object that had the GC type flag set and could be found by using tp_traverse had to be in a GC linked list. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-29 15:21 Message: Logged In: YES user_id=31435 Accepted, and back to Neil for checkin. I don't think you need to go thru Guido again, as you and I both talked with him about the issues, and you've addressed them. Feel free to reassign to Fred if you want better doc review, though. I don't know what to make of someone "thinking" a speed increase is measurable: you either measured one, or you didn't . My intuition is that the macros are a good idea, although if they're not to be used by extension modules then their names should begin with an underscore (to make clear that they're not part of the public API). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-29 10:47 Message: Logged In: YES user_id=35752 Changes in this version: * Rename PyObject_GC_Ignore to PyObject_GC_UnTrack. * Documention new functions * Revert collection from inside ceval change. * Add TRACK/UNTRACK macros (should not be used by extensions otherwise modules compiled with a different WITH_CYCLE_GC setting will break). Are the TRACK/UNTRACK macros a good idea? I think they give a measurable speed increase. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-22 14:28 Message: Logged In: YES user_id=31435 I want to see this patch go in: it affords some nice simplifications in many places, so should make the code easier to maintain and to change. Some gripes: + Most of the new functions don't appear to be documented at all, except in that they're mentioned in passing by the docs for other new functions: PyObject_GC_New, PyObject_GC_NewVar, PyObject_GC_Resize, PyObject_GC_Del. + Unlike the old Init/Fini, the new Track/Ignore don't "sound like" matching brackets. TrackOn/TrackOff, TrackStart/TrackStop, Track/UnTrack, ... would be better for this reason. I draw the line at PyObject_GC_New vs PyObject_GC_Old, though . + Overall, and despite the pain it causes, it's probably better to let GC continue to get triggered by "deallocation deficit", rather than moving the prod into the eval loop. Guido says you two already discussed that, so I won't belabor it here. I'll note that one consequence of the current policy is that GC glitches got triggered during compilation, and mysterious as those were, that they *did* happen during compilation allowed to rule out huge pieces of the Python runtime code; it was significantly harder to pin the blame for glitches that didn't happen until runtime. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 12:59 Message: Logged In: YES user_id=35752 I've brought the patch up to date. I'm not sure if we really need this patch. The current approach works okay. I think this patch improves things since more details about the GC implementation are hidden. This would give us more freedom to change the implementation in the future. Also, I think the patch makes it easier for extension types to support GC. The patch is somewhat backwards compatible now. Types that use the old interface will still compile but will not be GCed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:32 Message: Logged In: YES user_id=6380 Neil, do we still need this? I've marked it out-of-date because I'm sure that it won't apply cleanly any more. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-16 09:25 Message: Logged In: YES user_id=6380 I think I know a way to fix the incompatibility, by switching to a different flag bit. I'll try to work this into the descr-branch code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 10:13 Message: Logged In: YES user_id=21627 I have two problems with this patch: 1. It comes with no documentation. 2. It breaks existing third-party modules which use the GC API as defined in Python 2. Consequently, I recommend rejection of the patch in its current form. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 From noreply@sourceforge.net Thu Aug 30 01:22:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 Aug 2001 17:22:39 -0700 Subject: [Patches] [ python-Patches-421893 ] Cleanup GC API Message-ID: Patches item #421893, was opened at 2001-05-06 14:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Cleanup GC API Initial Comment: This patch adds three new APIs: PyObject_GC_New PyObject_GC_NewVar PyObject_GC_Resize PyObject_GC_Del and renames PyObject_GC_Init and PyObject_GC_Fini to: PyObject_GC_Track PyObject_GC_Ignore respectively. Objects that wish to be tracked by the collector must use these new APIs. Many more details about the GC implementation are hidden inside gcmodule.c. There seems to be no change in performance. Note that PyObject_GC_{New,NewVar} automatically adds the object to the GC lists. There is no need to call PyObject_GC_Track. PyObject_GC_Del automatically removes the object from the GC list but usually you want to call PyObject_GC_Ignore yourself (DECREFs can end up running arbitrary code). It should be more difficult to corrupt the GC linked lists now. Also, you can now call PyObject_GC_Ignore on objects that you know will not create RCs. The _weakref module does this. Previously, every object that had the GC type flag set and could be found by using tp_traverse had to be in a GC linked list. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-08-29 17:22 Message: Logged In: YES user_id=35752 Everything checked in except the doc changes. Fred, can you take a look and check them in if they are okay? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-29 15:21 Message: Logged In: YES user_id=31435 Accepted, and back to Neil for checkin. I don't think you need to go thru Guido again, as you and I both talked with him about the issues, and you've addressed them. Feel free to reassign to Fred if you want better doc review, though. I don't know what to make of someone "thinking" a speed increase is measurable: you either measured one, or you didn't . My intuition is that the macros are a good idea, although if they're not to be used by extension modules then their names should begin with an underscore (to make clear that they're not part of the public API). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-29 10:47 Message: Logged In: YES user_id=35752 Changes in this version: * Rename PyObject_GC_Ignore to PyObject_GC_UnTrack. * Documention new functions * Revert collection from inside ceval change. * Add TRACK/UNTRACK macros (should not be used by extensions otherwise modules compiled with a different WITH_CYCLE_GC setting will break). Are the TRACK/UNTRACK macros a good idea? I think they give a measurable speed increase. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-22 14:28 Message: Logged In: YES user_id=31435 I want to see this patch go in: it affords some nice simplifications in many places, so should make the code easier to maintain and to change. Some gripes: + Most of the new functions don't appear to be documented at all, except in that they're mentioned in passing by the docs for other new functions: PyObject_GC_New, PyObject_GC_NewVar, PyObject_GC_Resize, PyObject_GC_Del. + Unlike the old Init/Fini, the new Track/Ignore don't "sound like" matching brackets. TrackOn/TrackOff, TrackStart/TrackStop, Track/UnTrack, ... would be better for this reason. I draw the line at PyObject_GC_New vs PyObject_GC_Old, though . + Overall, and despite the pain it causes, it's probably better to let GC continue to get triggered by "deallocation deficit", rather than moving the prod into the eval loop. Guido says you two already discussed that, so I won't belabor it here. I'll note that one consequence of the current policy is that GC glitches got triggered during compilation, and mysterious as those were, that they *did* happen during compilation allowed to rule out huge pieces of the Python runtime code; it was significantly harder to pin the blame for glitches that didn't happen until runtime. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 12:59 Message: Logged In: YES user_id=35752 I've brought the patch up to date. I'm not sure if we really need this patch. The current approach works okay. I think this patch improves things since more details about the GC implementation are hidden. This would give us more freedom to change the implementation in the future. Also, I think the patch makes it easier for extension types to support GC. The patch is somewhat backwards compatible now. Types that use the old interface will still compile but will not be GCed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:32 Message: Logged In: YES user_id=6380 Neil, do we still need this? I've marked it out-of-date because I'm sure that it won't apply cleanly any more. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-16 09:25 Message: Logged In: YES user_id=6380 I think I know a way to fix the incompatibility, by switching to a different flag bit. I'll try to work this into the descr-branch code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 10:13 Message: Logged In: YES user_id=21627 I have two problems with this patch: 1. It comes with no documentation. 2. It breaks existing third-party modules which use the GC API as defined in Python 2. Consequently, I recommend rejection of the patch in its current form. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 From noreply@sourceforge.net Thu Aug 30 03:09:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 Aug 2001 19:09:42 -0700 Subject: [Patches] [ python-Patches-456736 ] Remember __future__ imports in IDE Message-ID: Patches item #456736, was opened at 2001-08-29 19:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456736&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: Remember __future__ imports in IDE Initial Comment: Changes the MacPython IDE's interactive mode to use a codeop.Compile object instead of the builtin compile. Maintains the compiler's flags between statements, so that "from __future__ import" applies to further statements (just like in the interpretter). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456736&group_id=5470 From noreply@sourceforge.net Thu Aug 30 04:04:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 Aug 2001 20:04:05 -0700 Subject: [Patches] [ python-Patches-421893 ] Cleanup GC API Message-ID: Patches item #421893, was opened at 2001-05-06 14:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted >Priority: 6 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Cleanup GC API Initial Comment: This patch adds three new APIs: PyObject_GC_New PyObject_GC_NewVar PyObject_GC_Resize PyObject_GC_Del and renames PyObject_GC_Init and PyObject_GC_Fini to: PyObject_GC_Track PyObject_GC_Ignore respectively. Objects that wish to be tracked by the collector must use these new APIs. Many more details about the GC implementation are hidden inside gcmodule.c. There seems to be no change in performance. Note that PyObject_GC_{New,NewVar} automatically adds the object to the GC lists. There is no need to call PyObject_GC_Track. PyObject_GC_Del automatically removes the object from the GC list but usually you want to call PyObject_GC_Ignore yourself (DECREFs can end up running arbitrary code). It should be more difficult to corrupt the GC linked lists now. Also, you can now call PyObject_GC_Ignore on objects that you know will not create RCs. The _weakref module does this. Previously, every object that had the GC type flag set and could be found by using tp_traverse had to be in a GC linked list. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-29 20:04 Message: Logged In: YES user_id=3066 The contents of the \cfunction macro should always include the trailing "()" after the name of the function; there are at least two cases where it is missing. Otherwise, this looks good; make that change and check it in, then close the patch. Thanks! ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-29 17:22 Message: Logged In: YES user_id=35752 Everything checked in except the doc changes. Fred, can you take a look and check them in if they are okay? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-29 15:21 Message: Logged In: YES user_id=31435 Accepted, and back to Neil for checkin. I don't think you need to go thru Guido again, as you and I both talked with him about the issues, and you've addressed them. Feel free to reassign to Fred if you want better doc review, though. I don't know what to make of someone "thinking" a speed increase is measurable: you either measured one, or you didn't . My intuition is that the macros are a good idea, although if they're not to be used by extension modules then their names should begin with an underscore (to make clear that they're not part of the public API). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-29 10:47 Message: Logged In: YES user_id=35752 Changes in this version: * Rename PyObject_GC_Ignore to PyObject_GC_UnTrack. * Documention new functions * Revert collection from inside ceval change. * Add TRACK/UNTRACK macros (should not be used by extensions otherwise modules compiled with a different WITH_CYCLE_GC setting will break). Are the TRACK/UNTRACK macros a good idea? I think they give a measurable speed increase. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-22 14:28 Message: Logged In: YES user_id=31435 I want to see this patch go in: it affords some nice simplifications in many places, so should make the code easier to maintain and to change. Some gripes: + Most of the new functions don't appear to be documented at all, except in that they're mentioned in passing by the docs for other new functions: PyObject_GC_New, PyObject_GC_NewVar, PyObject_GC_Resize, PyObject_GC_Del. + Unlike the old Init/Fini, the new Track/Ignore don't "sound like" matching brackets. TrackOn/TrackOff, TrackStart/TrackStop, Track/UnTrack, ... would be better for this reason. I draw the line at PyObject_GC_New vs PyObject_GC_Old, though . + Overall, and despite the pain it causes, it's probably better to let GC continue to get triggered by "deallocation deficit", rather than moving the prod into the eval loop. Guido says you two already discussed that, so I won't belabor it here. I'll note that one consequence of the current policy is that GC glitches got triggered during compilation, and mysterious as those were, that they *did* happen during compilation allowed to rule out huge pieces of the Python runtime code; it was significantly harder to pin the blame for glitches that didn't happen until runtime. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 12:59 Message: Logged In: YES user_id=35752 I've brought the patch up to date. I'm not sure if we really need this patch. The current approach works okay. I think this patch improves things since more details about the GC implementation are hidden. This would give us more freedom to change the implementation in the future. Also, I think the patch makes it easier for extension types to support GC. The patch is somewhat backwards compatible now. Types that use the old interface will still compile but will not be GCed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:32 Message: Logged In: YES user_id=6380 Neil, do we still need this? I've marked it out-of-date because I'm sure that it won't apply cleanly any more. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-16 09:25 Message: Logged In: YES user_id=6380 I think I know a way to fix the incompatibility, by switching to a different flag bit. I'll try to work this into the descr-branch code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 10:13 Message: Logged In: YES user_id=21627 I have two problems with this patch: 1. It comes with no documentation. 2. It breaks existing third-party modules which use the GC API as defined in Python 2. Consequently, I recommend rejection of the patch in its current form. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 From noreply@sourceforge.net Thu Aug 30 04:21:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 Aug 2001 20:21:58 -0700 Subject: [Patches] [ python-Patches-430706 ] Persistent connections in BaseHTTPServer Message-ID: Patches item #430706, was opened at 2001-06-06 08:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) Assigned to: Nobody/Anonymous (nobody) Summary: Persistent connections in BaseHTTPServer Initial Comment: This patch provides HTTP/1.1 persistent connection support in BaseHTTPServer.py. It is not enabled by default (for backwards compatibility) because Content-Length headers must be supplied for persistent connections to work correctly. ---------------------------------------------------------------------- >Comment By: Chris Lawrence (lordsutch) Date: 2001-08-29 20:21 Message: Logged In: YES user_id=6757 I have updated the patch against current CVS and have added documentation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-08 13:43 Message: Logged In: YES user_id=21627 I haven't studied the patch in detail, yet, but I have a few comments on the style: - there is no need to quote all authors of the RFC. Also, the reference to long-ago expired HTTP draft should go; just replace it with a single reference to the RFC number (giving an URL for the RFC might be convenient) - Where is the documentation? A patch to Doc/lib/libbasehttp.tex would be appreciated. If you don't speak TeX, don't worry: Just write plain text, we'll do the mark-up. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 From alice@homegiant.com.tw Thu Aug 30 08:16:02 2001 From: alice@homegiant.com.tw (Alice Lin (Home Giant)) Date: 30 Aug 2001 15:16:02 +0800 Subject: [Patches] Furniture Hardware Message-ID: Business Opportunity for Cabinet & Furniture Hardware

To: Purchasing Manager / Importing Dept. Manager

*** In case you do not have any need for Furniture Hardware, or if you are not involved in a related business and/or look for a purchasing agent; please disregard this e-mail.  

To remove your email address from our database, please click the link below:
mail to: alice@homegiant.d2g.com?subject=REMOVE 
Thank you and sorry for any inconvenience ! *** 

¡@

Hello,

We are pleased to have this opportunity to briefly introduce ourselves.

Home Giant was established in 1987, specialized in manufacturing of  Furniture Hardware. 
We produce:

   Hinges
   Pulls
   Knobs
   Metal Brackets
   Brackets
   Adorning Brass
   Casters
   Home hardware

If you do not see it listed here, or for more detailed product information, please feel free to visit our web site at http://www.homegiant.com.tw or contact us directly.   

We will be pleased to furnish any information you require.  We will work with you to meet your needs (OEM/ODM projects welcome). 

Meanwhile, if you are looking for the purchasing agent, Home Giant will be happy to serve you. To provide our customers the most competitive prices and best services are our missions.

You will be satisfied with the high quality of our products and service. Give us a chance to prove that Home Giant will be your best choice of Furniture Hardware and/or purchasing agent.

Contact Home Giant to make the highest profit and obtain the best service & support.  

Looking forward to hearing from you very soon.

Sincerely yours,

Alice Lin
Home Giant Enterprise Co., Ltd.
http://www.homegiant.com.tw   

P.S. If you are not in purchasing/importing,  please forward our email to your Purchasing Manager/Importing Dept. Manager or anyone who may be interested in our products and/or service.  Thank you very much!

From noreply@sourceforge.net Thu Aug 30 15:44:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 Aug 2001 07:44:40 -0700 Subject: [Patches] [ python-Patches-456736 ] Remember __future__ imports in IDE Message-ID: Patches item #456736, was opened at 2001-08-29 19:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456736&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: Remember __future__ imports in IDE Initial Comment: Changes the MacPython IDE's interactive mode to use a codeop.Compile object instead of the builtin compile. Maintains the compiler's flags between statements, so that "from __future__ import" applies to further statements (just like in the interpretter). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-08-30 07:44 Message: Logged In: YES user_id=6656 There ain't no patch here! You have to check the "Check to Upload & Attach File:" box (this is infuriating, yes). Maybe this should be a canned response... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456736&group_id=5470 From noreply@sourceforge.net Thu Aug 30 16:24:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 Aug 2001 08:24:40 -0700 Subject: [Patches] [ python-Patches-421893 ] Cleanup GC API Message-ID: Patches item #421893, was opened at 2001-05-06 14:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 Category: core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 6 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Cleanup GC API Initial Comment: This patch adds three new APIs: PyObject_GC_New PyObject_GC_NewVar PyObject_GC_Resize PyObject_GC_Del and renames PyObject_GC_Init and PyObject_GC_Fini to: PyObject_GC_Track PyObject_GC_Ignore respectively. Objects that wish to be tracked by the collector must use these new APIs. Many more details about the GC implementation are hidden inside gcmodule.c. There seems to be no change in performance. Note that PyObject_GC_{New,NewVar} automatically adds the object to the GC lists. There is no need to call PyObject_GC_Track. PyObject_GC_Del automatically removes the object from the GC list but usually you want to call PyObject_GC_Ignore yourself (DECREFs can end up running arbitrary code). It should be more difficult to corrupt the GC linked lists now. Also, you can now call PyObject_GC_Ignore on objects that you know will not create RCs. The _weakref module does this. Previously, every object that had the GC type flag set and could be found by using tp_traverse had to be in a GC linked list. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-29 20:04 Message: Logged In: YES user_id=3066 The contents of the \cfunction macro should always include the trailing "()" after the name of the function; there are at least two cases where it is missing. Otherwise, this looks good; make that change and check it in, then close the patch. Thanks! ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-29 17:22 Message: Logged In: YES user_id=35752 Everything checked in except the doc changes. Fred, can you take a look and check them in if they are okay? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-29 15:21 Message: Logged In: YES user_id=31435 Accepted, and back to Neil for checkin. I don't think you need to go thru Guido again, as you and I both talked with him about the issues, and you've addressed them. Feel free to reassign to Fred if you want better doc review, though. I don't know what to make of someone "thinking" a speed increase is measurable: you either measured one, or you didn't . My intuition is that the macros are a good idea, although if they're not to be used by extension modules then their names should begin with an underscore (to make clear that they're not part of the public API). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-29 10:47 Message: Logged In: YES user_id=35752 Changes in this version: * Rename PyObject_GC_Ignore to PyObject_GC_UnTrack. * Documention new functions * Revert collection from inside ceval change. * Add TRACK/UNTRACK macros (should not be used by extensions otherwise modules compiled with a different WITH_CYCLE_GC setting will break). Are the TRACK/UNTRACK macros a good idea? I think they give a measurable speed increase. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-22 14:28 Message: Logged In: YES user_id=31435 I want to see this patch go in: it affords some nice simplifications in many places, so should make the code easier to maintain and to change. Some gripes: + Most of the new functions don't appear to be documented at all, except in that they're mentioned in passing by the docs for other new functions: PyObject_GC_New, PyObject_GC_NewVar, PyObject_GC_Resize, PyObject_GC_Del. + Unlike the old Init/Fini, the new Track/Ignore don't "sound like" matching brackets. TrackOn/TrackOff, TrackStart/TrackStop, Track/UnTrack, ... would be better for this reason. I draw the line at PyObject_GC_New vs PyObject_GC_Old, though . + Overall, and despite the pain it causes, it's probably better to let GC continue to get triggered by "deallocation deficit", rather than moving the prod into the eval loop. Guido says you two already discussed that, so I won't belabor it here. I'll note that one consequence of the current policy is that GC glitches got triggered during compilation, and mysterious as those were, that they *did* happen during compilation allowed to rule out huge pieces of the Python runtime code; it was significantly harder to pin the blame for glitches that didn't happen until runtime. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-08-19 12:59 Message: Logged In: YES user_id=35752 I've brought the patch up to date. I'm not sure if we really need this patch. The current approach works okay. I think this patch improves things since more details about the GC implementation are hidden. This would give us more freedom to change the implementation in the future. Also, I think the patch makes it easier for extension types to support GC. The patch is somewhat backwards compatible now. Types that use the old interface will still compile but will not be GCed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:32 Message: Logged In: YES user_id=6380 Neil, do we still need this? I've marked it out-of-date because I'm sure that it won't apply cleanly any more. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-06-16 09:25 Message: Logged In: YES user_id=6380 I think I know a way to fix the incompatibility, by switching to a different flag bit. I'll try to work this into the descr-branch code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 10:13 Message: Logged In: YES user_id=21627 I have two problems with this patch: 1. It comes with no documentation. 2. It breaks existing third-party modules which use the GC API as defined in Python 2. Consequently, I recommend rejection of the patch in its current form. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470 From noreply@sourceforge.net Thu Aug 30 16:56:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 Aug 2001 08:56:45 -0700 Subject: [Patches] [ python-Patches-456736 ] Remember __future__ imports in IDE Message-ID: Patches item #456736, was opened at 2001-08-29 19:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456736&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: Remember __future__ imports in IDE Initial Comment: Changes the MacPython IDE's interactive mode to use a codeop.Compile object instead of the builtin compile. Maintains the compiler's flags between statements, so that "from __future__ import" applies to further statements (just like in the interpretter). ---------------------------------------------------------------------- Comment By: Mark Day (markday) Date: 2001-08-30 08:56 Message: Logged In: YES user_id=312024 I don't see a way to attach the patch to the existing report. In the meantime, I'll mail it directly to Jack Jansen. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-30 07:44 Message: Logged In: YES user_id=6656 There ain't no patch here! You have to check the "Check to Upload & Attach File:" box (this is infuriating, yes). Maybe this should be a canned response... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456736&group_id=5470 From noreply@sourceforge.net Thu Aug 30 20:03:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 Aug 2001 12:03:11 -0700 Subject: [Patches] [ python-Patches-456949 ] clear() method for lists Message-ID: Patches item #456949, was opened at 2001-08-30 12:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456949&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tomas Styblo (tripiecz) Assigned to: Nobody/Anonymous (nobody) Summary: clear() method for lists Initial Comment: Hello. A patch which adds the clear() method to lists is appended to this message. It's for the current CVS of listobject.c. Motivation: - Dictionaries have this method. For sake of consistence, lists should have it too. - Python 2.2 attempts to somewhat unify interface to dictionaries and interface to lists: iterators and compatibility of the 'in' operator with dictionaries are good examples. - 'L.clear()' is far more readable then 'del L[:]' - Lists in Java have it too. :-) - It was easy to implement, there already exists tp_clear for lists. Any objections against the patch ? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456949&group_id=5470 From noreply@sourceforge.net Thu Aug 30 20:13:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 Aug 2001 12:13:24 -0700 Subject: [Patches] [ python-Patches-456949 ] clear() method for lists Message-ID: Patches item #456949, was opened at 2001-08-30 12:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456949&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tomas Styblo (tripiecz) Assigned to: Nobody/Anonymous (nobody) Summary: clear() method for lists Initial Comment: Hello. A patch which adds the clear() method to lists is appended to this message. It's for the current CVS of listobject.c. Motivation: - Dictionaries have this method. For sake of consistence, lists should have it too. - Python 2.2 attempts to somewhat unify interface to dictionaries and interface to lists: iterators and compatibility of the 'in' operator with dictionaries are good examples. - 'L.clear()' is far more readable then 'del L[:]' - Lists in Java have it too. :-) - It was easy to implement, there already exists tp_clear for lists. Any objections against the patch ? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-30 12:13 Message: Logged In: YES user_id=6380 The consistency argument is bogus -- the APIs for lists and dicts are almost entirely distinct. The tp_clear slot is for internal use by the garbage collector. Rejected. If you want to help, please search through PEP 42 for projects. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456949&group_id=5470 From noreply@sourceforge.net Thu Aug 30 20:13:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 Aug 2001 12:13:40 -0700 Subject: [Patches] [ python-Patches-456949 ] clear() method for lists Message-ID: Patches item #456949, was opened at 2001-08-30 12:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456949&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Tomas Styblo (tripiecz) >Assigned to: Guido van Rossum (gvanrossum) Summary: clear() method for lists Initial Comment: Hello. A patch which adds the clear() method to lists is appended to this message. It's for the current CVS of listobject.c. Motivation: - Dictionaries have this method. For sake of consistence, lists should have it too. - Python 2.2 attempts to somewhat unify interface to dictionaries and interface to lists: iterators and compatibility of the 'in' operator with dictionaries are good examples. - 'L.clear()' is far more readable then 'del L[:]' - Lists in Java have it too. :-) - It was easy to implement, there already exists tp_clear for lists. Any objections against the patch ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-30 12:13 Message: Logged In: YES user_id=6380 The consistency argument is bogus -- the APIs for lists and dicts are almost entirely distinct. The tp_clear slot is for internal use by the garbage collector. Rejected. If you want to help, please search through PEP 42 for projects. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456949&group_id=5470 From noreply@sourceforge.net Thu Aug 30 20:17:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 Aug 2001 12:17:21 -0700 Subject: [Patches] [ python-Patches-455966 ] Allow leading 0 in float/imag literals Message-ID: Patches item #455966, was opened at 2001-08-27 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455966&group_id=5470 Category: Parser/Compiler Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: Allow leading 0 in float/imag literals Initial Comment: Many years ago I was baffled that "0e0" as a literal gave an error (it doesn't as a string argument to float), and I never got used to it. While fixing a bug earlier today, I noticed this comment in tokenizer.c: /* XXX This is broken! E.g., 09.9 should be accepted as float! */ 09.9 is accepted after the patch, but along with stuff that isn't so clear, like 0777j same as 777j. OTOH, even at that extreme, complex("0777j") returns 777j without this patch too. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-30 12:17 Message: Logged In: YES user_id=6380 Sounds like a good idea. Is this also a Jython issue? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455966&group_id=5470 From noreply@sourceforge.net Thu Aug 30 21:53:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 Aug 2001 13:53:38 -0700 Subject: [Patches] [ python-Patches-455966 ] Allow leading 0 in float/imag literals Message-ID: Patches item #455966, was opened at 2001-08-27 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455966&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: Allow leading 0 in float/imag literals Initial Comment: Many years ago I was baffled that "0e0" as a literal gave an error (it doesn't as a string argument to float), and I never got used to it. While fixing a bug earlier today, I noticed this comment in tokenizer.c: /* XXX This is broken! E.g., 09.9 should be accepted as float! */ 09.9 is accepted after the patch, but along with stuff that isn't so clear, like 0777j same as 777j. OTOH, even at that extreme, complex("0777j") returns 777j without this patch too. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-08-30 13:53 Message: Logged In: YES user_id=31435 I brought the issue up on Jython-Dev but haven't heard back yet. Checked in, with more test cases than in the patch: Doc/ref/ref2.tex; new revision: 1.31 Lib/tokenize.py; new revision: 1.28 Lib/test/test_compile.py; new revision: 1.8 Misc/NEWS; new revision: 1.219 Parser/tokenizer.c; new revision: 2.53 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-30 12:17 Message: Logged In: YES user_id=6380 Sounds like a good idea. Is this also a Jython issue? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455966&group_id=5470 From alice@homegiant.com.tw Fri Aug 31 09:13:57 2001 From: alice@homegiant.com.tw (Alice Lin (Home Giant)) Date: 31 Aug 2001 16:13:57 +0800 Subject: [Patches] Furniture Hardware Message-ID: Business Opportunity for Cabinet & Furniture Hardware

To: Purchasing Manager / Importing Dept. Manager

*** In case you do not have any need for Furniture Hardware, or if you are not involved in a related business and/or look for a purchasing agent; please disregard this e-mail.  

To remove your email address from our database, please click the link below:
mail to: alice@homegiant.d2g.com?subject=REMOVE 
Thank you and sorry for any inconvenience ! *** 

¡@

Hello,

We are pleased to have this opportunity to briefly introduce ourselves.

Home Giant was established in 1987, specialized in manufacturing of  Furniture Hardware. 
We produce:

   Hinges
   Pulls
   Knobs
   Metal Brackets
   Brackets
   Adorning Brass
   Casters
   Home hardware

If you do not see it listed here, or for more detailed product information, please feel free to visit our web site at http://www.homegiant.com.tw or contact us directly.   

We will be pleased to furnish any information you require.  We will work with you to meet your needs (OEM/ODM projects welcome). 

Meanwhile, if you are looking for the purchasing agent, Home Giant will be happy to serve you. To provide our customers the most competitive prices and best services are our missions.

You will be satisfied with the high quality of our products and service. Give us a chance to prove that Home Giant will be your best choice of Furniture Hardware and/or purchasing agent.

Contact Home Giant to make the highest profit and obtain the best service & support.  

Looking forward to hearing from you very soon.

Sincerely yours,

Alice Lin
Home Giant Enterprise Co., Ltd.
http://www.homegiant.com.tw   

P.S. If you are not in purchasing/importing,  please forward our email to your Purchasing Manager/Importing Dept. Manager or anyone who may be interested in our products and/or service.  Thank you very much!