From noreply@sourceforge.net Sat Dec 1 01:26:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 17:26:12 -0800 Subject: [Patches] [ python-Patches-487735 ] WeakList Message-ID: Patches item #487735, was opened at 2001-11-30 17:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487735&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: WeakList Initial Comment: To be added to weakref. WeakList are list whose entries are referenced weakly and are deleted when the original object is gc. Its iterator contains also a weaklist,that implies that: for item in weaklist_items: dosomething(item) object that are gc are deleted from weaklist_items. There exist other path with the test case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487735&group_id=5470 From noreply@sourceforge.net Sat Dec 1 01:29:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 17:29:09 -0800 Subject: [Patches] [ python-Patches-487736 ] test_weaklist Message-ID: Patches item #487736, was opened at 2001-11-30 17:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487736&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: test_weaklist Initial Comment: test_case from weaklist, to be added to test_weakref ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487736&group_id=5470 From noreply@sourceforge.net Sat Dec 1 01:36:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 17:36:07 -0800 Subject: [Patches] [ python-Patches-487738 ] weaklist Message-ID: Patches item #487738, was opened at 2001-11-30 17:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andres Tuells (atuells) Assigned to: Nobody/Anonymous (nobody) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 From noreply@sourceforge.net Sat Dec 1 01:37:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 17:37:33 -0800 Subject: [Patches] [ python-Patches-487739 ] test_weaklist Message-ID: Patches item #487739, was opened at 2001-11-30 17:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487739&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andres Tuells (atuells) Assigned to: Nobody/Anonymous (nobody) Summary: test_weaklist Initial Comment: Test case for weaklist. Look previous patch: weaklist ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487739&group_id=5470 From noreply@sourceforge.net Sat Dec 1 07:29:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 23:29:32 -0800 Subject: [Patches] [ python-Patches-487784 ] Fixes a bug in popen3/4 handling on UNIX Message-ID: Patches item #487784, was opened at 2001-11-30 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes a bug in popen3/4 handling on UNIX Initial Comment: Fixes a bug in popen2.popen3/4 bug where popen3/4 was treating unicode objects like sequence types, not as strings. This patch is pretty conservative, it shouldn't break anything. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 From noreply@sourceforge.net Sat Dec 1 07:36:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 23:36:51 -0800 Subject: [Patches] [ python-Patches-487784 ] Fixes a bug in popen3/4 handling on UNIX Message-ID: Patches item #487784, was opened at 2001-11-30 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes a bug in popen3/4 handling on UNIX Initial Comment: Fixes a bug in popen2.popen3/4 bug where popen3/4 was treating unicode objects like sequence types, not as strings. This patch is pretty conservative, it shouldn't break anything. ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-11-30 23:36 Message: Logged In: YES user_id=108973 I guess I should note that this patch does not change the results of test_popen2.py and that it satisfies my own test suite: import popen2 testBuffer = 'This is a test\n' (child_stdout, child_stdin, child_strerr) = popen2.popen3('cat') child_stdin.write(testBuffer) child_stdin.close() assert child_stdout.read() == testBuffer (child_stdout, child_stdin, child_strerr) = popen2.popen3(u'cat') child_stdin.write(testBuffer) child_stdin.close() assert child_stdout.read() == testBuffer # Fails without this patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 From noreply@sourceforge.net Sat Dec 1 18:01:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 10:01:53 -0800 Subject: [Patches] [ python-Patches-487784 ] Fixes a bug in popen3/4 handling on UNIX Message-ID: Patches item #487784, was opened at 2001-11-30 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes a bug in popen3/4 handling on UNIX Initial Comment: Fixes a bug in popen2.popen3/4 bug where popen3/4 was treating unicode objects like sequence types, not as strings. This patch is pretty conservative, it shouldn't break anything. ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-12-01 10:01 Message: Logged In: YES user_id=108973 Second patch uses types.StringTypes instead of doing a hardcoded check for string and unicode objects. BTW, it would be nice to add a function like this to types (I would submit a patch but I can't think of a good name): def isStringThing(thing): for stringType in types.StringTypes: if isinstance(thing, stringType): return 1 return 0 ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-11-30 23:36 Message: Logged In: YES user_id=108973 I guess I should note that this patch does not change the results of test_popen2.py and that it satisfies my own test suite: import popen2 testBuffer = 'This is a test\n' (child_stdout, child_stdin, child_strerr) = popen2.popen3('cat') child_stdin.write(testBuffer) child_stdin.close() assert child_stdout.read() == testBuffer (child_stdout, child_stdin, child_strerr) = popen2.popen3(u'cat') child_stdin.write(testBuffer) child_stdin.close() assert child_stdout.read() == testBuffer # Fails without this patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 From noreply@sourceforge.net Sat Dec 1 20:42:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 12:42:40 -0800 Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c Message-ID: Patches item #487906, was opened at 2001-12-01 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: update inline docs in stringobject.c Initial Comment: --- Objects/stringobject.c 2001/11/28 20:27:42 2.141 +++ Objects/stringobject.c 2001/12/01 20:40:09 @@ -19,19 +19,26 @@ #endif /* - Newsizedstringobject() and newstringobject() try in certain cases + PyString_FromStringAndSize() and PyString_FromString() try in certain cases to share string objects. When the size of the string is zero, these routines always return a pointer to the same string object; when the size is one, they return a pointer to an already existing object if the contents of the string is known. For - newstringobject() this is always the case, for - newsizedstringobject() this is the case when the first argument in + PyString_FromString() this is always the case, for + PyString_FromStringAndSize() this is the case when the first argument in not NULL. - A common practice to allocate a string and then fill it in or - change it must be done carefully. It is only allowed to change the - contents of the string if the obect was gotten from - newsizedstringobject() with a NULL first argument, because in the + A common practice of allocating a string and then filling it in or + changing it must be done carefully. It is only allowed to change the + contents of the string if the object was gotten from + PyString_FromStringAndSize() with a NULL first argument, because in the future these routines may try to do even more sharing of objects. + + The parameter `size' denotes number of characters in the string, not number + of bytes requires to store it, and does not count the null terminating + character. + + On the other hand, the member `op->ob_size' denotes the number of bytes + used for storing the string, including the null terminating character. */ PyObject * PyString_FromStringAndSize(const char *str, int size) @@ -58,7 +65,7 @@ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 From noreply@sourceforge.net Sat Dec 1 20:44:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 12:44:02 -0800 Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c Message-ID: Patches item #487906, was opened at 2001-12-01 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: update inline docs in stringobject.c Initial Comment: --- Objects/stringobject.c 2001/11/28 20:27:42 2.141 +++ Objects/stringobject.c 2001/12/01 20:40:09 @@ -19,19 +19,26 @@ #endif /* - Newsizedstringobject() and newstringobject() try in certain cases + PyString_FromStringAndSize() and PyString_FromString() try in certain cases to share string objects. When the size of the string is zero, these routines always return a pointer to the same string object; when the size is one, they return a pointer to an already existing object if the contents of the string is known. For - newstringobject() this is always the case, for - newsizedstringobject() this is the case when the first argument in + PyString_FromString() this is always the case, for + PyString_FromStringAndSize() this is the case when the first argument in not NULL. - A common practice to allocate a string and then fill it in or - change it must be done carefully. It is only allowed to change the - contents of the string if the obect was gotten from - newsizedstringobject() with a NULL first argument, because in the + A common practice of allocating a string and then filling it in or + changing it must be done carefully. It is only allowed to change the + contents of the string if the object was gotten from + PyString_FromStringAndSize() with a NULL first argument, because in the future these routines may try to do even more sharing of objects. + + The parameter `size' denotes number of characters in the string, not number + of bytes requires to store it, and does not count the null terminating + character. + + On the other hand, the member `op->ob_size' denotes the number of bytes + used for storing the string, including the null terminating character. */ PyObject * PyString_FromStringAndSize(const char *str, int size) @@ -58,7 +65,7 @@ ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2001-12-01 12:44 Message: Logged In: YES user_id=52562 Okay I guess that's all mangled. DAMN, I hate trying to use a web browser for anything other than browsing. Anyway, I've attached the same patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 From noreply@sourceforge.net Sun Dec 2 00:44:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 16:44:08 -0800 Subject: [Patches] [ python-Patches-487784 ] Fixes a bug in popen3/4 handling on UNIX Message-ID: Patches item #487784, was opened at 2001-11-30 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes a bug in popen3/4 handling on UNIX Initial Comment: Fixes a bug in popen2.popen3/4 bug where popen3/4 was treating unicode objects like sequence types, not as strings. This patch is pretty conservative, it shouldn't break anything. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 16:44 Message: Logged In: YES user_id=21627 I think the isinstance test is more than needed; doing if type(cmd) in types.StringTypes: should be sufficient. If some other means for testing for "string-ness" becomes available, all occurrences of StringTypes can be inspected easily. That certainly won't happen for 2.2. How do you produce the attachments? file(1) says Macintosh MacBinary data, type " ", creator " " It would be better if they were plain text. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-12-01 10:01 Message: Logged In: YES user_id=108973 Second patch uses types.StringTypes instead of doing a hardcoded check for string and unicode objects. BTW, it would be nice to add a function like this to types (I would submit a patch but I can't think of a good name): def isStringThing(thing): for stringType in types.StringTypes: if isinstance(thing, stringType): return 1 return 0 ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-11-30 23:36 Message: Logged In: YES user_id=108973 I guess I should note that this patch does not change the results of test_popen2.py and that it satisfies my own test suite: import popen2 testBuffer = 'This is a test\n' (child_stdout, child_stdin, child_strerr) = popen2.popen3('cat') child_stdin.write(testBuffer) child_stdin.close() assert child_stdout.read() == testBuffer (child_stdout, child_stdin, child_strerr) = popen2.popen3(u'cat') child_stdin.write(testBuffer) child_stdin.close() assert child_stdout.read() == testBuffer # Fails without this patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 From noreply@sourceforge.net Sun Dec 2 00:45:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 16:45:26 -0800 Subject: [Patches] [ python-Patches-487735 ] WeakList Message-ID: Patches item #487735, was opened at 2001-11-30 17:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487735&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: WeakList Initial Comment: To be added to weakref. WeakList are list whose entries are referenced weakly and are deleted when the original object is gc. Its iterator contains also a weaklist,that implies that: for item in weaklist_items: dosomething(item) object that are gc are deleted from weaklist_items. There exist other path with the test case. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 16:45 Message: Logged In: YES user_id=21627 Duplicate of 487738. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487735&group_id=5470 From noreply@sourceforge.net Sun Dec 2 00:46:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 16:46:05 -0800 Subject: [Patches] [ python-Patches-487736 ] test_weaklist Message-ID: Patches item #487736, was opened at 2001-11-30 17:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487736&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: test_weaklist Initial Comment: test_case from weaklist, to be added to test_weakref ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 16:46 Message: Logged In: YES user_id=21627 Duplicate of 487739. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487736&group_id=5470 From noreply@sourceforge.net Sun Dec 2 01:07:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 17:07:17 -0800 Subject: [Patches] [ python-Patches-487738 ] weaklist Message-ID: Patches item #487738, was opened at 2001-11-30 17:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andres Tuells (atuells) Assigned to: Nobody/Anonymous (nobody) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 17:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 From noreply@sourceforge.net Sun Dec 2 01:08:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 17:08:02 -0800 Subject: [Patches] [ python-Patches-487455 ] make types.StringTypes a tuple Message-ID: Patches item #487455, was opened at 2001-11-30 02:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487455&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) >Assigned to: Martin v. Löwis (loewis) Summary: make types.StringTypes a tuple Initial Comment: The small patch below makes types.StringTypes a tuple, so that you can use "isinstance(var, StringTypes)". As StringTypes was introduced in the 2.2 development cycle there should not be any compatibility concerns. Markus --- Lib/types.py Tue Oct 30 06:19:53 2001 +++ Lib/types.py.new Fri Nov 30 11:47:42 2001 @@ -26,9 +26,9 @@ StringType = str try: UnicodeType = unicode - StringTypes = [StringType, UnicodeType] + StringTypes = (StringType, UnicodeType) except NameError: - StringTypes = [StringType] + StringTypes = (StringType,) BufferType = type(buffer('')) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487455&group_id=5470 From noreply@sourceforge.net Sun Dec 2 03:42:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 19:42:35 -0800 Subject: [Patches] [ python-Patches-487784 ] Fixes a bug in popen3/4 handling on UNIX Message-ID: Patches item #487784, was opened at 2001-11-30 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes a bug in popen3/4 handling on UNIX Initial Comment: Fixes a bug in popen2.popen3/4 bug where popen3/4 was treating unicode objects like sequence types, not as strings. This patch is pretty conservative, it shouldn't break anything. ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-12-01 19:42 Message: Logged In: YES user_id=108973 1. I was thinking ahead with the isinstance thing because string types might be subclassable in the future. But if you think that a similar bug won't resurface post 2.2, do it the way that you suggested :-) 2. Sorry. I used a Mac to test my changes and submit my patch, since that is the only UNIX system that I have convenient access to. I've reattached the file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 16:44 Message: Logged In: YES user_id=21627 I think the isinstance test is more than needed; doing if type(cmd) in types.StringTypes: should be sufficient. If some other means for testing for "string-ness" becomes available, all occurrences of StringTypes can be inspected easily. That certainly won't happen for 2.2. How do you produce the attachments? file(1) says Macintosh MacBinary data, type " ", creator " " It would be better if they were plain text. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-12-01 10:01 Message: Logged In: YES user_id=108973 Second patch uses types.StringTypes instead of doing a hardcoded check for string and unicode objects. BTW, it would be nice to add a function like this to types (I would submit a patch but I can't think of a good name): def isStringThing(thing): for stringType in types.StringTypes: if isinstance(thing, stringType): return 1 return 0 ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-11-30 23:36 Message: Logged In: YES user_id=108973 I guess I should note that this patch does not change the results of test_popen2.py and that it satisfies my own test suite: import popen2 testBuffer = 'This is a test\n' (child_stdout, child_stdin, child_strerr) = popen2.popen3('cat') child_stdin.write(testBuffer) child_stdin.close() assert child_stdout.read() == testBuffer (child_stdout, child_stdin, child_strerr) = popen2.popen3(u'cat') child_stdin.write(testBuffer) child_stdin.close() assert child_stdout.read() == testBuffer # Fails without this patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 From noreply@sourceforge.net Sun Dec 2 10:48:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 02:48:20 -0800 Subject: [Patches] [ python-Patches-487275 ] windows-1251 charset alias Message-ID: Patches item #487275, was opened at 2001-11-29 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487275&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Zabaluev (mzabaluev) >Assigned to: Martin v. Löwis (loewis) Summary: windows-1251 charset alias Initial Comment: Added the 'windows_1251' alias for the 'cp1251' charset. The alias is used extensively on the Internet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487275&group_id=5470 From noreply@sourceforge.net Sun Dec 2 11:03:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 03:03:03 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:03 Message: Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Sun Dec 2 11:06:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 03:06:01 -0800 Subject: [Patches] [ python-Patches-485959 ] Final set of patches to Demo/tix Message-ID: Patches item #485959, was opened at 2001-11-27 03:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Martin v. Löwis (loewis) Summary: Final set of patches to Demo/tix Initial Comment: Final set of patches to Demo/tix - this should be it for a while. Tix.py: Fixed tix_configure and fixed some of the doc strings. tixwidgets.py: fixed loop, added some more docstrings, and made some progress on the global image1 problem. Look for the code around 'if 0:' - it may point towards a bug in Tkinter. Image class. Also if I can understand this proble, maybe I can solve the long outstanding bug described in Demo/tix/BUG.txt. samples/ Fixed SHList1 and 2 not quiting when run from samples/ and fixed a bug in all of the demos that was leaving zombie pythonw processes under Windows in 2.1.0 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 From noreply@sourceforge.net Sun Dec 2 11:03:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 03:03:57 -0800 Subject: [Patches] [ python-Patches-486743 ] remove bad INCREF, propagate exception Message-ID: Patches item #486743, was opened at 2001-11-28 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) >Assigned to: Martin v. Löwis (loewis) Summary: remove bad INCREF, propagate exception Initial Comment: This is my very first foray into the Python interpreter, so please be patient. It looks like to me that this INCREF is wrong since the PyList_Append() will steal the reference. Also I tested it. Current CVS does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1562 >>> len(gc.get_objects()) 1565 >>> len(gc.get_objects()) 1568 >>> len(gc.get_objects()) 1571 >>> len(gc.get_objects()) 1574 and with my patch it does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 In addition I added checks for error return from PyList_Append(), and propagated the exception condition up the callstack. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:33 Message: Logged In: YES user_id=52562 Whoops. It is against dist/src/Modules/gcmodule.c ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-11-28 16:30 Message: Logged In: YES user_id=413 which file is the patch against? ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:12 Message: Logged In: YES user_id=52562 Oh, and here is a new version of the patch, which also tests for failure from PyList_New(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 From noreply@sourceforge.net Sun Dec 2 11:09:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 03:09:08 -0800 Subject: [Patches] [ python-Patches-481718 ] Time module doc string changes. Message-ID: Patches item #481718, was opened at 2001-11-14 07:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481718&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) >Assigned to: Martin v. Löwis (loewis) Summary: Time module doc string changes. Initial Comment: Made the doc-strings for time.localtime() and time.gmtime() list the elements of the tuple they return. This is what the os.stat() doc-string does, and it's supremely useful when combined with "pydoc". Also added a newline after the first line of a couple of doc-strings, so that they all have the same format (summary line, blank line, details). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2001-11-26 01:47 Message: Logged In: YES user_id=81797 The file has been attached. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:48 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481718&group_id=5470 From noreply@sourceforge.net Sun Dec 2 11:13:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 03:13:52 -0800 Subject: [Patches] [ python-Patches-481225 ] rfc822.Addresslist fails on long addrs Message-ID: Patches item #481225, was opened at 2001-11-13 01:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481225&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822.Addresslist fails on long addrs Initial Comment: AddrlistClass.getaddrlist used a recursion method, that's why it failed on very long addresses. This patch narrows the function so that it doesn't use recursion. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:13 Message: Logged In: YES user_id=21627 This problem has been fixed in rfc822.py 1.65 (which shipped with 2.2b2). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481225&group_id=5470 From noreply@sourceforge.net Sun Dec 2 12:08:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 04:08:38 -0800 Subject: [Patches] [ python-Patches-487455 ] make types.StringTypes a tuple Message-ID: Patches item #487455, was opened at 2001-11-30 02:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487455&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: Martin v. Löwis (loewis) Summary: make types.StringTypes a tuple Initial Comment: The small patch below makes types.StringTypes a tuple, so that you can use "isinstance(var, StringTypes)". As StringTypes was introduced in the 2.2 development cycle there should not be any compatibility concerns. Markus --- Lib/types.py Tue Oct 30 06:19:53 2001 +++ Lib/types.py.new Fri Nov 30 11:47:42 2001 @@ -26,9 +26,9 @@ StringType = str try: UnicodeType = unicode - StringTypes = [StringType, UnicodeType] + StringTypes = (StringType, UnicodeType) except NameError: - StringTypes = [StringType] + StringTypes = (StringType,) BufferType = type(buffer('')) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 04:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as types.py 1.25 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487455&group_id=5470 From noreply@sourceforge.net Sun Dec 2 12:22:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 04:22:43 -0800 Subject: [Patches] [ python-Patches-486743 ] remove bad INCREF, propagate exception Message-ID: Patches item #486743, was opened at 2001-11-28 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Martin v. Löwis (loewis) Summary: remove bad INCREF, propagate exception Initial Comment: This is my very first foray into the Python interpreter, so please be patient. It looks like to me that this INCREF is wrong since the PyList_Append() will steal the reference. Also I tested it. Current CVS does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1562 >>> len(gc.get_objects()) 1565 >>> len(gc.get_objects()) 1568 >>> len(gc.get_objects()) 1571 >>> len(gc.get_objects()) 1574 and with my patch it does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 In addition I added checks for error return from PyList_Append(), and propagated the exception condition up the callstack. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 04:22 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as gcmodule.c 2.32 (with slight modifications: return 0 in case of success). ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:33 Message: Logged In: YES user_id=52562 Whoops. It is against dist/src/Modules/gcmodule.c ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-11-28 16:30 Message: Logged In: YES user_id=413 which file is the patch against? ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:12 Message: Logged In: YES user_id=52562 Oh, and here is a new version of the patch, which also tests for failure from PyList_New(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 From noreply@sourceforge.net Sun Dec 2 12:26:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 04:26:22 -0800 Subject: [Patches] [ python-Patches-487275 ] windows-1251 charset alias Message-ID: Patches item #487275, was opened at 2001-11-29 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487275&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Martin v. Löwis (loewis) Summary: windows-1251 charset alias Initial Comment: Added the 'windows_1251' alias for the 'cp1251' charset. The alias is used extensively on the Internet. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 04:26 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as aliases.py 1.11, NEWS 1.322. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487275&group_id=5470 From noreply@sourceforge.net Sun Dec 2 12:28:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 04:28:09 -0800 Subject: [Patches] [ python-Patches-481718 ] Time module doc string changes. Message-ID: Patches item #481718, was opened at 2001-11-14 07:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481718&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Martin v. Löwis (loewis) Summary: Time module doc string changes. Initial Comment: Made the doc-strings for time.localtime() and time.gmtime() list the elements of the tuple they return. This is what the os.stat() doc-string does, and it's supremely useful when combined with "pydoc". Also added a newline after the first line of a couple of doc-strings, so that they all have the same format (summary line, blank line, details). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 04:28 Message: Logged In: YES user_id=21627 Thanks, applied as timemodule.c 2.117. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2001-11-26 01:47 Message: Logged In: YES user_id=81797 The file has been attached. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:48 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481718&group_id=5470 From noreply@sourceforge.net Sun Dec 2 12:35:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 04:35:26 -0800 Subject: [Patches] [ python-Patches-485959 ] Final set of patches to Demo/tix Message-ID: Patches item #485959, was opened at 2001-11-27 03:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Martin v. Löwis (loewis) Summary: Final set of patches to Demo/tix Initial Comment: Final set of patches to Demo/tix - this should be it for a while. Tix.py: Fixed tix_configure and fixed some of the doc strings. tixwidgets.py: fixed loop, added some more docstrings, and made some progress on the global image1 problem. Look for the code around 'if 0:' - it may point towards a bug in Tkinter. Image class. Also if I can understand this proble, maybe I can solve the long outstanding bug described in Demo/tix/BUG.txt. samples/ Fixed SHList1 and 2 not quiting when run from samples/ and fixed a bug in all of the demos that was leaving zombie pythonw processes under Windows in 2.1.0 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 04:35 Message: Logged In: YES user_id=21627 These patches don't apply cleanly; I get patch rejects in Control.py.rej SHList1.py.rej SHList2.py.rej Please obtain the current version through CVS, and produce a 'cvs diff -u', instead of individual diff files. We only need the diffs; the original files aren't needed (so you don't need to produce a tar file, either). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 From noreply@sourceforge.net Sun Dec 2 13:34:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 05:34:19 -0800 Subject: [Patches] [ python-Patches-487784 ] Fixes a bug in popen3/4 handling on UNIX Message-ID: Patches item #487784, was opened at 2001-11-30 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes a bug in popen3/4 handling on UNIX Initial Comment: Fixes a bug in popen2.popen3/4 bug where popen3/4 was treating unicode objects like sequence types, not as strings. This patch is pretty conservative, it shouldn't break anything. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 05:34 Message: Logged In: YES user_id=21627 Thanks again for the patch. I just noticed that you can pass types.StringTypes to isinstance these days, so committed it as if isinstance(cmd, types.StringTypes): in popen2.py 1.20. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-12-01 19:42 Message: Logged In: YES user_id=108973 1. I was thinking ahead with the isinstance thing because string types might be subclassable in the future. But if you think that a similar bug won't resurface post 2.2, do it the way that you suggested :-) 2. Sorry. I used a Mac to test my changes and submit my patch, since that is the only UNIX system that I have convenient access to. I've reattached the file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 16:44 Message: Logged In: YES user_id=21627 I think the isinstance test is more than needed; doing if type(cmd) in types.StringTypes: should be sufficient. If some other means for testing for "string-ness" becomes available, all occurrences of StringTypes can be inspected easily. That certainly won't happen for 2.2. How do you produce the attachments? file(1) says Macintosh MacBinary data, type " ", creator " " It would be better if they were plain text. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-12-01 10:01 Message: Logged In: YES user_id=108973 Second patch uses types.StringTypes instead of doing a hardcoded check for string and unicode objects. BTW, it would be nice to add a function like this to types (I would submit a patch but I can't think of a good name): def isStringThing(thing): for stringType in types.StringTypes: if isinstance(thing, stringType): return 1 return 0 ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-11-30 23:36 Message: Logged In: YES user_id=108973 I guess I should note that this patch does not change the results of test_popen2.py and that it satisfies my own test suite: import popen2 testBuffer = 'This is a test\n' (child_stdout, child_stdin, child_strerr) = popen2.popen3('cat') child_stdin.write(testBuffer) child_stdin.close() assert child_stdout.read() == testBuffer (child_stdout, child_stdin, child_strerr) = popen2.popen3(u'cat') child_stdin.write(testBuffer) child_stdin.close() assert child_stdout.read() == testBuffer # Fails without this patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487784&group_id=5470 From noreply@sourceforge.net Sun Dec 2 13:57:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 05:57:44 -0800 Subject: [Patches] [ python-Patches-488073 ] AtheOS port of Python 2.2b2 Message-ID: Patches item #488073, was opened at 2001-12-02 05:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Octavian Cerna (tavyc) Assigned to: Nobody/Anonymous (nobody) Summary: AtheOS port of Python 2.2b2 Initial Comment: Hi, While I was playing with AtheOS in the last few days, I saw that it comes with Python 1.5.2. Being a Python enthusiast, I tried to see if a recent version of Python would work. It did not even compile, so I decided to port it, knowing that AtheOS is almost POSIX-compatible. The result is a full-blown Python port with only a (relative) small amount of changes, that builds OOTB. And here it is, with all the details: About the patch: - The diff is against CVS 2001-11-26 - 20 files changed, 1962 insertions, 23 deletions - It does not include changes to autoconf-generated files - The patch includes a few very small fixes not directly related to the AtheOS port, but which were necessary to ensure the port works OK: - setup.py - look for the _curses_panel.c file in $srcdir/Modules, not in $PWD/Modules (otherwise VPATH builds will not build _curses_panel.so) - Makefile.pre.in - only ranlib *.a files (how will this affect other ports?) - Tools/freeze/bkfile.py - not all platforms have the file.truncate method - Tools/scripts/h2py.py - environment- paths code was made more portable Environment: - AtheOS 0.3.6 - gcc 2.95.2 - binutils 2.10 - glibc 2.1.2 Features: - Dynamic loading of modules - Native thread support Issues: Although AtheOS is not a BeOS clone, it is in many ways similar to BeOS, and some issues from BeOS also apply on AtheOS. - dlopen is not properly implemented, so I had to add support for native dynamic loading. - The POSIX threads emulation is almost inexistent, so I added support for native AtheOS threads. - AtheOS doesn't support importing symbols in a shared library from the main executable (the `-export-dynamic' linker flag), so the Python core must be built as a shared library, like on BeOS. - mmap is not implemented in AtheOS, the mmap module was disabled - statvfs is not implemented, os.statvfs and os.fstatvfs disabled - crypt on AtheOS crashes with SEGV if salt is not "$1$" (glibc bug?), disabled - poll - it seems that poll never returns POLLNVAL for an invalid fd (hangs), disabled - Don't mix threading with fork() -- see test_popen2 below. All tests pass, except: - test_nis hangs on my system, probably because NIS is not set up - test_popen2 hangs when imported from regrtest.py, otherwise working (like on BeOS). I suspect that the import semaphore is locked when popen2 forks and AtheOS doesn't like that. - test_mhlib fails, I don't know exactly why, but I suspect a filesystem issue (It corrupted some of my files several times, and I don't want to run it again ;) - test_locale skipped, locale en_US not supported (maybe something's wrong with my environment?) - test_largefile skipped (unless you tell it to eat 2GB disk space) because apparently afs doesn't support sparse files. Notes: - If you build Python, make sure you have shared versions of your libraries and you have links in /system/libs for them, otherwise the kernel won't load modules. AtheOS doesn't have a shared version for each library, I had serious problems with ncurses and the _curses_panel module. Binary packages: - I have prepared binary packages of Python-2.2b2 and Numeric-20.2.1 for testing, I will post them on kamidake.org later. Future: - I'm going to try Zope these days, I think it should work with a minimum amount of changes, almost OOTB ;) (Maybe I should have included this text in the README file?) Please excuse my bad English, I am not a native speaker :) Python is an excellent language/environment, keep going with the good work! -------- Best Regards, Octavian Cerna (Tavy) yLabs ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 From noreply@sourceforge.net Sun Dec 2 15:34:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 07:34:46 -0800 Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c Message-ID: Patches item #487906, was opened at 2001-12-01 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: update inline docs in stringobject.c Initial Comment: --- Objects/stringobject.c 2001/11/28 20:27:42 2.141 +++ Objects/stringobject.c 2001/12/01 20:40:09 @@ -19,19 +19,26 @@ #endif /* - Newsizedstringobject() and newstringobject() try in certain cases + PyString_FromStringAndSize() and PyString_FromString() try in certain cases to share string objects. When the size of the string is zero, these routines always return a pointer to the same string object; when the size is one, they return a pointer to an already existing object if the contents of the string is known. For - newstringobject() this is always the case, for - newsizedstringobject() this is the case when the first argument in + PyString_FromString() this is always the case, for + PyString_FromStringAndSize() this is the case when the first argument in not NULL. - A common practice to allocate a string and then fill it in or - change it must be done carefully. It is only allowed to change the - contents of the string if the obect was gotten from - newsizedstringobject() with a NULL first argument, because in the + A common practice of allocating a string and then filling it in or + changing it must be done carefully. It is only allowed to change the + contents of the string if the object was gotten from + PyString_FromStringAndSize() with a NULL first argument, because in the future these routines may try to do even more sharing of objects. + + The parameter `size' denotes number of characters in the string, not number + of bytes requires to store it, and does not count the null terminating + character. + + On the other hand, the member `op->ob_size' denotes the number of bytes + used for storing the string, including the null terminating character. */ PyObject * PyString_FromStringAndSize(const char *str, int size) @@ -58,7 +65,7 @@ ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 07:34 Message: Logged In: YES user_id=21627 There is currently nothing attached. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-01 12:44 Message: Logged In: YES user_id=52562 Okay I guess that's all mangled. DAMN, I hate trying to use a web browser for anything other than browsing. Anyway, I've attached the same patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 From noreply@sourceforge.net Sun Dec 2 15:42:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 07:42:56 -0800 Subject: [Patches] [ python-Patches-488073 ] AtheOS port of Python 2.2b2 Message-ID: Patches item #488073, was opened at 2001-12-02 05:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Octavian Cerna (tavyc) Assigned to: Nobody/Anonymous (nobody) Summary: AtheOS port of Python 2.2b2 Initial Comment: Hi, While I was playing with AtheOS in the last few days, I saw that it comes with Python 1.5.2. Being a Python enthusiast, I tried to see if a recent version of Python would work. It did not even compile, so I decided to port it, knowing that AtheOS is almost POSIX-compatible. The result is a full-blown Python port with only a (relative) small amount of changes, that builds OOTB. And here it is, with all the details: About the patch: - The diff is against CVS 2001-11-26 - 20 files changed, 1962 insertions, 23 deletions - It does not include changes to autoconf-generated files - The patch includes a few very small fixes not directly related to the AtheOS port, but which were necessary to ensure the port works OK: - setup.py - look for the _curses_panel.c file in $srcdir/Modules, not in $PWD/Modules (otherwise VPATH builds will not build _curses_panel.so) - Makefile.pre.in - only ranlib *.a files (how will this affect other ports?) - Tools/freeze/bkfile.py - not all platforms have the file.truncate method - Tools/scripts/h2py.py - environment- paths code was made more portable Environment: - AtheOS 0.3.6 - gcc 2.95.2 - binutils 2.10 - glibc 2.1.2 Features: - Dynamic loading of modules - Native thread support Issues: Although AtheOS is not a BeOS clone, it is in many ways similar to BeOS, and some issues from BeOS also apply on AtheOS. - dlopen is not properly implemented, so I had to add support for native dynamic loading. - The POSIX threads emulation is almost inexistent, so I added support for native AtheOS threads. - AtheOS doesn't support importing symbols in a shared library from the main executable (the `-export-dynamic' linker flag), so the Python core must be built as a shared library, like on BeOS. - mmap is not implemented in AtheOS, the mmap module was disabled - statvfs is not implemented, os.statvfs and os.fstatvfs disabled - crypt on AtheOS crashes with SEGV if salt is not "$1$" (glibc bug?), disabled - poll - it seems that poll never returns POLLNVAL for an invalid fd (hangs), disabled - Don't mix threading with fork() -- see test_popen2 below. All tests pass, except: - test_nis hangs on my system, probably because NIS is not set up - test_popen2 hangs when imported from regrtest.py, otherwise working (like on BeOS). I suspect that the import semaphore is locked when popen2 forks and AtheOS doesn't like that. - test_mhlib fails, I don't know exactly why, but I suspect a filesystem issue (It corrupted some of my files several times, and I don't want to run it again ;) - test_locale skipped, locale en_US not supported (maybe something's wrong with my environment?) - test_largefile skipped (unless you tell it to eat 2GB disk space) because apparently afs doesn't support sparse files. Notes: - If you build Python, make sure you have shared versions of your libraries and you have links in /system/libs for them, otherwise the kernel won't load modules. AtheOS doesn't have a shared version for each library, I had serious problems with ncurses and the _curses_panel module. Binary packages: - I have prepared binary packages of Python-2.2b2 and Numeric-20.2.1 for testing, I will post them on kamidake.org later. Future: - I'm going to try Zope these days, I think it should work with a minimum amount of changes, almost OOTB ;) (Maybe I should have included this text in the README file?) Please excuse my bad English, I am not a native speaker :) Python is an excellent language/environment, keep going with the good work! -------- Best Regards, Octavian Cerna (Tavy) yLabs ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 07:42 Message: Logged In: YES user_id=21627 I'd advise not to add this port so shortly before 2.2, in particular since these changes need careful review. As an example: Why does it add HAVE_GETADDRINFO to acconfig.h? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 From noreply@sourceforge.net Sun Dec 2 16:47:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 08:47:16 -0800 Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c Message-ID: Patches item #487906, was opened at 2001-12-01 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: update inline docs in stringobject.c Initial Comment: --- Objects/stringobject.c 2001/11/28 20:27:42 2.141 +++ Objects/stringobject.c 2001/12/01 20:40:09 @@ -19,19 +19,26 @@ #endif /* - Newsizedstringobject() and newstringobject() try in certain cases + PyString_FromStringAndSize() and PyString_FromString() try in certain cases to share string objects. When the size of the string is zero, these routines always return a pointer to the same string object; when the size is one, they return a pointer to an already existing object if the contents of the string is known. For - newstringobject() this is always the case, for - newsizedstringobject() this is the case when the first argument in + PyString_FromString() this is always the case, for + PyString_FromStringAndSize() this is the case when the first argument in not NULL. - A common practice to allocate a string and then fill it in or - change it must be done carefully. It is only allowed to change the - contents of the string if the obect was gotten from - newsizedstringobject() with a NULL first argument, because in the + A common practice of allocating a string and then filling it in or + changing it must be done carefully. It is only allowed to change the + contents of the string if the object was gotten from + PyString_FromStringAndSize() with a NULL first argument, because in the future these routines may try to do even more sharing of objects. + + The parameter `size' denotes number of characters in the string, not number + of bytes requires to store it, and does not count the null terminating + character. + + On the other hand, the member `op->ob_size' denotes the number of bytes + used for storing the string, including the null terminating character. */ PyObject * PyString_FromStringAndSize(const char *str, int size) @@ -58,7 +65,7 @@ ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2001-12-02 08:47 Message: Logged In: YES user_id=52562 Heh heh heh. I can't wait for the day that we can remotely collaborate with something other than a web browser as the user interface. Okay, sorry, here is a newer version of the patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 07:34 Message: Logged In: YES user_id=21627 There is currently nothing attached. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-01 12:44 Message: Logged In: YES user_id=52562 Okay I guess that's all mangled. DAMN, I hate trying to use a web browser for anything other than browsing. Anyway, I've attached the same patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 From noreply@sourceforge.net Sun Dec 2 18:10:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 10:10:03 -0800 Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c Message-ID: Patches item #487906, was opened at 2001-12-01 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: update inline docs in stringobject.c Initial Comment: --- Objects/stringobject.c 2001/11/28 20:27:42 2.141 +++ Objects/stringobject.c 2001/12/01 20:40:09 @@ -19,19 +19,26 @@ #endif /* - Newsizedstringobject() and newstringobject() try in certain cases + PyString_FromStringAndSize() and PyString_FromString() try in certain cases to share string objects. When the size of the string is zero, these routines always return a pointer to the same string object; when the size is one, they return a pointer to an already existing object if the contents of the string is known. For - newstringobject() this is always the case, for - newsizedstringobject() this is the case when the first argument in + PyString_FromString() this is always the case, for + PyString_FromStringAndSize() this is the case when the first argument in not NULL. - A common practice to allocate a string and then fill it in or - change it must be done carefully. It is only allowed to change the - contents of the string if the obect was gotten from - newsizedstringobject() with a NULL first argument, because in the + A common practice of allocating a string and then filling it in or + changing it must be done carefully. It is only allowed to change the + contents of the string if the object was gotten from + PyString_FromStringAndSize() with a NULL first argument, because in the future these routines may try to do even more sharing of objects. + + The parameter `size' denotes number of characters in the string, not number + of bytes requires to store it, and does not count the null terminating + character. + + On the other hand, the member `op->ob_size' denotes the number of bytes + used for storing the string, including the null terminating character. */ PyObject * PyString_FromStringAndSize(const char *str, int size) @@ -58,7 +65,7 @@ ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 10:10 Message: Logged In: YES user_id=21627 It's not just upload that is difficult; download has its speed bumps as well. Mozilla insists to call all files downloaded from SF "download.php", no matter what filename SF has recorded... Thanks for the patch; it is in stringobject.c 2.142. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-02 08:47 Message: Logged In: YES user_id=52562 Heh heh heh. I can't wait for the day that we can remotely collaborate with something other than a web browser as the user interface. Okay, sorry, here is a newer version of the patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 07:34 Message: Logged In: YES user_id=21627 There is currently nothing attached. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-01 12:44 Message: Logged In: YES user_id=52562 Okay I guess that's all mangled. DAMN, I hate trying to use a web browser for anything other than browsing. Anyway, I've attached the same patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 From noreply@sourceforge.net Sun Dec 2 18:10:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 10:10:33 -0800 Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c Message-ID: Patches item #487906, was opened at 2001-12-01 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: update inline docs in stringobject.c Initial Comment: --- Objects/stringobject.c 2001/11/28 20:27:42 2.141 +++ Objects/stringobject.c 2001/12/01 20:40:09 @@ -19,19 +19,26 @@ #endif /* - Newsizedstringobject() and newstringobject() try in certain cases + PyString_FromStringAndSize() and PyString_FromString() try in certain cases to share string objects. When the size of the string is zero, these routines always return a pointer to the same string object; when the size is one, they return a pointer to an already existing object if the contents of the string is known. For - newstringobject() this is always the case, for - newsizedstringobject() this is the case when the first argument in + PyString_FromString() this is always the case, for + PyString_FromStringAndSize() this is the case when the first argument in not NULL. - A common practice to allocate a string and then fill it in or - change it must be done carefully. It is only allowed to change the - contents of the string if the obect was gotten from - newsizedstringobject() with a NULL first argument, because in the + A common practice of allocating a string and then filling it in or + changing it must be done carefully. It is only allowed to change the + contents of the string if the object was gotten from + PyString_FromStringAndSize() with a NULL first argument, because in the future these routines may try to do even more sharing of objects. + + The parameter `size' denotes number of characters in the string, not number + of bytes requires to store it, and does not count the null terminating + character. + + On the other hand, the member `op->ob_size' denotes the number of bytes + used for storing the string, including the null terminating character. */ PyObject * PyString_FromStringAndSize(const char *str, int size) @@ -58,7 +65,7 @@ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 10:10 Message: Logged In: YES user_id=21627 It's not just upload that is difficult; download has its speed bumps as well. Mozilla insists to call all files downloaded from SF "download.php", no matter what filename SF has recorded... Thanks for the patch; it is in stringobject.c 2.142. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-02 08:47 Message: Logged In: YES user_id=52562 Heh heh heh. I can't wait for the day that we can remotely collaborate with something other than a web browser as the user interface. Okay, sorry, here is a newer version of the patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 07:34 Message: Logged In: YES user_id=21627 There is currently nothing attached. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-01 12:44 Message: Logged In: YES user_id=52562 Okay I guess that's all mangled. DAMN, I hate trying to use a web browser for anything other than browsing. Anyway, I've attached the same patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 From noreply@sourceforge.net Sun Dec 2 18:12:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 10:12:28 -0800 Subject: [Patches] [ python-Patches-486743 ] remove bad INCREF, propagate exception Message-ID: Patches item #486743, was opened at 2001-11-28 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Martin v. Löwis (loewis) Summary: remove bad INCREF, propagate exception Initial Comment: This is my very first foray into the Python interpreter, so please be patient. It looks like to me that this INCREF is wrong since the PyList_Append() will steal the reference. Also I tested it. Current CVS does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1562 >>> len(gc.get_objects()) 1565 >>> len(gc.get_objects()) 1568 >>> len(gc.get_objects()) 1571 >>> len(gc.get_objects()) 1574 and with my patch it does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 In addition I added checks for error return from PyList_Append(), and propagated the exception condition up the callstack. ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2001-12-02 10:12 Message: Logged In: YES user_id=52562 Whoo-hoo! My patch was accepted! :-) Here's the remaining diffs between my sandbox and the current CVS. Not sure if there is something wrong with this or if you just didn't see it: (The same thing is also attached, since I guess my web browser will mangle it.) @@ -724,6 +758,9 @@ if (!PyArg_ParseTuple(args, ":get_objects")) /* check no args */ return NULL; result = PyList_New(0); + if (result == NULL) { + return NULL; + } if (append_objects(result, &_PyGC_generation0) || append_objects(result, &generation1) || append_objects(result, &generation2)) { ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 04:22 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as gcmodule.c 2.32 (with slight modifications: return 0 in case of success). ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:33 Message: Logged In: YES user_id=52562 Whoops. It is against dist/src/Modules/gcmodule.c ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-11-28 16:30 Message: Logged In: YES user_id=413 which file is the patch against? ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:12 Message: Logged In: YES user_id=52562 Oh, and here is a new version of the patch, which also tests for failure from PyList_New(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 From noreply@sourceforge.net Sun Dec 2 18:33:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 10:33:53 -0800 Subject: [Patches] [ python-Patches-486743 ] remove bad INCREF, propagate exception Message-ID: Patches item #486743, was opened at 2001-11-28 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Martin v. Löwis (loewis) Summary: remove bad INCREF, propagate exception Initial Comment: This is my very first foray into the Python interpreter, so please be patient. It looks like to me that this INCREF is wrong since the PyList_Append() will steal the reference. Also I tested it. Current CVS does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1562 >>> len(gc.get_objects()) 1565 >>> len(gc.get_objects()) 1568 >>> len(gc.get_objects()) 1571 >>> len(gc.get_objects()) 1574 and with my patch it does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 In addition I added checks for error return from PyList_Append(), and propagated the exception condition up the callstack. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 10:33 Message: Logged In: YES user_id=21627 That fragment wasn't in your last patch; I have committed it as gcmodule.c 2.33 (thanks!). For some reason, your diffs are un-tabbified; you'd best produce diffs using 'cvs diff' - that will also put the file name into the patch. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-02 10:12 Message: Logged In: YES user_id=52562 Whoo-hoo! My patch was accepted! :-) Here's the remaining diffs between my sandbox and the current CVS. Not sure if there is something wrong with this or if you just didn't see it: (The same thing is also attached, since I guess my web browser will mangle it.) @@ -724,6 +758,9 @@ if (!PyArg_ParseTuple(args, ":get_objects")) /* check no args */ return NULL; result = PyList_New(0); + if (result == NULL) { + return NULL; + } if (append_objects(result, &_PyGC_generation0) || append_objects(result, &generation1) || append_objects(result, &generation2)) { ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 04:22 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as gcmodule.c 2.32 (with slight modifications: return 0 in case of success). ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:33 Message: Logged In: YES user_id=52562 Whoops. It is against dist/src/Modules/gcmodule.c ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-11-28 16:30 Message: Logged In: YES user_id=413 which file is the patch against? ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:12 Message: Logged In: YES user_id=52562 Oh, and here is a new version of the patch, which also tests for failure from PyList_New(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 From noreply@sourceforge.net Sun Dec 2 18:40:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 10:40:23 -0800 Subject: [Patches] [ python-Patches-488073 ] AtheOS port of Python 2.2b2 Message-ID: Patches item #488073, was opened at 2001-12-02 05:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Octavian Cerna (tavyc) Assigned to: Nobody/Anonymous (nobody) Summary: AtheOS port of Python 2.2b2 Initial Comment: Hi, While I was playing with AtheOS in the last few days, I saw that it comes with Python 1.5.2. Being a Python enthusiast, I tried to see if a recent version of Python would work. It did not even compile, so I decided to port it, knowing that AtheOS is almost POSIX-compatible. The result is a full-blown Python port with only a (relative) small amount of changes, that builds OOTB. And here it is, with all the details: About the patch: - The diff is against CVS 2001-11-26 - 20 files changed, 1962 insertions, 23 deletions - It does not include changes to autoconf-generated files - The patch includes a few very small fixes not directly related to the AtheOS port, but which were necessary to ensure the port works OK: - setup.py - look for the _curses_panel.c file in $srcdir/Modules, not in $PWD/Modules (otherwise VPATH builds will not build _curses_panel.so) - Makefile.pre.in - only ranlib *.a files (how will this affect other ports?) - Tools/freeze/bkfile.py - not all platforms have the file.truncate method - Tools/scripts/h2py.py - environment- paths code was made more portable Environment: - AtheOS 0.3.6 - gcc 2.95.2 - binutils 2.10 - glibc 2.1.2 Features: - Dynamic loading of modules - Native thread support Issues: Although AtheOS is not a BeOS clone, it is in many ways similar to BeOS, and some issues from BeOS also apply on AtheOS. - dlopen is not properly implemented, so I had to add support for native dynamic loading. - The POSIX threads emulation is almost inexistent, so I added support for native AtheOS threads. - AtheOS doesn't support importing symbols in a shared library from the main executable (the `-export-dynamic' linker flag), so the Python core must be built as a shared library, like on BeOS. - mmap is not implemented in AtheOS, the mmap module was disabled - statvfs is not implemented, os.statvfs and os.fstatvfs disabled - crypt on AtheOS crashes with SEGV if salt is not "$1$" (glibc bug?), disabled - poll - it seems that poll never returns POLLNVAL for an invalid fd (hangs), disabled - Don't mix threading with fork() -- see test_popen2 below. All tests pass, except: - test_nis hangs on my system, probably because NIS is not set up - test_popen2 hangs when imported from regrtest.py, otherwise working (like on BeOS). I suspect that the import semaphore is locked when popen2 forks and AtheOS doesn't like that. - test_mhlib fails, I don't know exactly why, but I suspect a filesystem issue (It corrupted some of my files several times, and I don't want to run it again ;) - test_locale skipped, locale en_US not supported (maybe something's wrong with my environment?) - test_largefile skipped (unless you tell it to eat 2GB disk space) because apparently afs doesn't support sparse files. Notes: - If you build Python, make sure you have shared versions of your libraries and you have links in /system/libs for them, otherwise the kernel won't load modules. AtheOS doesn't have a shared version for each library, I had serious problems with ncurses and the _curses_panel module. Binary packages: - I have prepared binary packages of Python-2.2b2 and Numeric-20.2.1 for testing, I will post them on kamidake.org later. Future: - I'm going to try Zope these days, I think it should work with a minimum amount of changes, almost OOTB ;) (Maybe I should have included this text in the README file?) Please excuse my bad English, I am not a native speaker :) Python is an excellent language/environment, keep going with the good work! -------- Best Regards, Octavian Cerna (Tavy) yLabs ---------------------------------------------------------------------- >Comment By: Octavian Cerna (tavyc) Date: 2001-12-02 10:40 Message: Logged In: YES user_id=382173 I know that Python is now in a "feature freeze" or something similar, but this patch could go in Python 2.3. I added the HAVE_GETADDRINFO to acconfig.h because it was simply missing and autoheader complained, (outdated CVS snapshot). I should have removed it from the patch. I posted it here just to make it available to anyone who wants to try it out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 07:42 Message: Logged In: YES user_id=21627 I'd advise not to add this port so shortly before 2.2, in particular since these changes need careful review. As an example: Why does it add HAVE_GETADDRINFO to acconfig.h? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 From noreply@sourceforge.net Sun Dec 2 18:50:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 10:50:02 -0800 Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c Message-ID: Patches item #487906, was opened at 2001-12-01 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: update inline docs in stringobject.c Initial Comment: --- Objects/stringobject.c 2001/11/28 20:27:42 2.141 +++ Objects/stringobject.c 2001/12/01 20:40:09 @@ -19,19 +19,26 @@ #endif /* - Newsizedstringobject() and newstringobject() try in certain cases + PyString_FromStringAndSize() and PyString_FromString() try in certain cases to share string objects. When the size of the string is zero, these routines always return a pointer to the same string object; when the size is one, they return a pointer to an already existing object if the contents of the string is known. For - newstringobject() this is always the case, for - newsizedstringobject() this is the case when the first argument in + PyString_FromString() this is always the case, for + PyString_FromStringAndSize() this is the case when the first argument in not NULL. - A common practice to allocate a string and then fill it in or - change it must be done carefully. It is only allowed to change the - contents of the string if the obect was gotten from - newsizedstringobject() with a NULL first argument, because in the + A common practice of allocating a string and then filling it in or + changing it must be done carefully. It is only allowed to change the + contents of the string if the object was gotten from + PyString_FromStringAndSize() with a NULL first argument, because in the future these routines may try to do even more sharing of objects. + + The parameter `size' denotes number of characters in the string, not number + of bytes requires to store it, and does not count the null terminating + character. + + On the other hand, the member `op->ob_size' denotes the number of bytes + used for storing the string, including the null terminating character. */ PyObject * PyString_FromStringAndSize(const char *str, int size) @@ -58,7 +65,7 @@ ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2001-12-02 10:50 Message: Logged In: YES user_id=52562 Here's one more addition to the in-line docs. I was trying to optimize `PyString_FromStringAndSize()' and I broke it because I didn't realize this fact, so I added this fact to the docs. :-) (pasted and attached) --- Objects/stringobject.c 2001/12/02 18:09:41 2.142 +++ Objects/stringobject.c 2001/12/02 18:47:48 @@ -33,6 +33,10 @@ a NULL first argument, because in the future these routines may try to do even more sharing of objects. + The string in the `str' parameter does not have to be null-character + terminated. (Therefore it is safe to construct a substring by using + `PyString_FromStringAndSize(origstring, substrlen)'.) + The parameter `size' denotes number of characters to allocate, not counting the null terminating character. If the `str' argument is not NULL, then it must point to a null-terminated string of length `size'. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 10:10 Message: Logged In: YES user_id=21627 It's not just upload that is difficult; download has its speed bumps as well. Mozilla insists to call all files downloaded from SF "download.php", no matter what filename SF has recorded... Thanks for the patch; it is in stringobject.c 2.142. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-02 08:47 Message: Logged In: YES user_id=52562 Heh heh heh. I can't wait for the day that we can remotely collaborate with something other than a web browser as the user interface. Okay, sorry, here is a newer version of the patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 07:34 Message: Logged In: YES user_id=21627 There is currently nothing attached. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-01 12:44 Message: Logged In: YES user_id=52562 Okay I guess that's all mangled. DAMN, I hate trying to use a web browser for anything other than browsing. Anyway, I've attached the same patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 From noreply@sourceforge.net Mon Dec 3 00:03:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 16:03:05 -0800 Subject: [Patches] [ python-Patches-481080 ] Read Me file Patch for Python 2.1.2 Message-ID: Patches item #481080, was opened at 2001-11-12 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Read Me file Patch for Python 2.1.2 Initial Comment: The following paragraph replaces the existing Mac OS X v10.1 paragraph. It assumes that patches 481060 and 481075 are taken. - Dan Mac OS X 10.1: Run configure with ./configure -- with-suffix=.x --with-dyld". This generates executable file: 'python.x' (it cannot be named 'python' on an HFS or HFS+ disk as the file name clashes with directory 'Python'). The makefile is set up to correctly handle two- level namespaces for Mac OS X v10.1 and 10.0.x systems. However, running the prebinding tool on Mac OS X 10.0.x again will cause the tool to break as it cannot handle two level namespaces. The default Mac OS X has a default stacksize of 512K which causes the regular expression tests (RE and SRE) to SEGV. To temporarily increase the stacksize, type 'limit stacksize 2M' in the terminal window before running 'make test'. The test_largefile test will work on HFS+ and UFS filesystem, providing you have enough space and time. After sudo 'make installation', do the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 16:03 Message: Logged In: YES user_id=45365 This sounds pretty reasonable to me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-28 23:25 Message: Logged In: YES user_id=3066 Assigned to the Mac OS expert for evaluation and integration. Jack, note that this is for the release21-maint branch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 From noreply@sourceforge.net Mon Dec 3 00:13:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 16:13:08 -0800 Subject: [Patches] [ python-Patches-482424 ] Add system() lookalike for MPW tools Message-ID: Patches item #482424, was opened at 2001-11-16 02:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=482424&group_id=5470 Category: Macintosh Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Add system() lookalike for MPW tools Initial Comment: Daniel Brotsky contributed this routine that can start MPW tools, somewhat similar to os.system() on unix. Add it to the contrib stuff. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 16:13 Message: Logged In: YES user_id=45365 Added to :Mac:Contrib as mpwsystem.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=482424&group_id=5470 From noreply@sourceforge.net Mon Dec 3 03:57:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 19:57:47 -0800 Subject: [Patches] [ python-Patches-486375 ] Use charset in email.Utils.encode Message-ID: Patches item #486375, was opened at 2001-11-27 22:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486375&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Mikhail Zabaluev (mzabaluev) >Assigned to: Barry Warsaw (bwarsaw) Summary: Use charset in email.Utils.encode Initial Comment: Here's a patch that makes email.Utils.encode actually _use_ its charset parameter. Note: a string is encoded into the specified character set using the 'replace' mode in order to provide high tolerance for missing characters, typical for email applications. The patch also slightly optimizes the code around (cough cough). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486375&group_id=5470 From noreply@sourceforge.net Mon Dec 3 03:58:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 19:58:33 -0800 Subject: [Patches] [ python-Patches-487634 ] Fix for NDEBUG problem and extensions Message-ID: Patches item #487634, was opened at 2001-11-30 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487634&group_id=5470 Category: Build Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Robin Dunn (robind) >Assigned to: Tim Peters (tim_one) Summary: Fix for NDEBUG problem and extensions Initial Comment: Python.h defines NDEBUG if not Py_DEBUG. This causes problems if 3rd party code has #ifdef NDEBUG's and is linked with other code that includes Python.h. See http://mail.python.org/pipermail/python-dev/2001-November/018669.html for more info. This patch simply undef's NDEBUG in Python.h after it includes assert.h if it was not defined before. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487634&group_id=5470 From noreply@sourceforge.net Mon Dec 3 03:59:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 19:59:27 -0800 Subject: [Patches] [ python-Patches-487739 ] test_weaklist Message-ID: Patches item #487739, was opened at 2001-11-30 17:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487739&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Andres Tuells (atuells) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: test_weaklist Initial Comment: Test case for weaklist. Look previous patch: weaklist ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487739&group_id=5470 From noreply@sourceforge.net Mon Dec 3 04:00:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 20:00:06 -0800 Subject: [Patches] [ python-Patches-487738 ] weaklist Message-ID: Patches item #487738, was opened at 2001-11-30 17:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Andres Tuells (atuells) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 17:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 From noreply@sourceforge.net Mon Dec 3 04:00:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 20:00:39 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Hye-Shik Chang (perky) >Assigned to: Jeremy Hylton (jhylton) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:03 Message: Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Mon Dec 3 04:01:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 20:01:10 -0800 Subject: [Patches] [ python-Patches-486079 ] poplib contains unuseable code Message-ID: Patches item #486079, was opened at 2001-11-27 09:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: poplib contains unuseable code Initial Comment: poplib contains a number of debugging statements, quite useful for debugging, which are turned on via the set_debuglevel function. However, all of the debug statements have been commented out, making it impossible to debug properly. Included is a patch which uncomments the commented code, but does *not* change default behavior. However, if someone issues the set_debuglevel(int N) function, then debugging works, just like the documentation and logic says it should. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:10 Message: Logged In: YES user_id=31435 Recategorized this as a patch. Note that it won't be considered for 2.2 (too late). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 From noreply@sourceforge.net Mon Dec 3 04:01:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 20:01:49 -0800 Subject: [Patches] [ python-Patches-480716 ] Support for super subclasses Message-ID: Patches item #480716, was opened at 2001-11-11 14:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480716&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Greg Chapman (glchapman) >Assigned to: Guido van Rossum (gvanrossum) Summary: Support for super subclasses Initial Comment: In Python 2.2b1, super is subclassable, however its __get__ (tp_descr_get) method always returns a new instance of super (not of its actual (sub)class). I think if super is to be subclassable, __get__ should return a new instance of the subclass. (I've been experimenting with using super instances to get and set the value of inherited attributes (properties). For this I needed a super subclass with a __setattr__ method. I also wanted to use the autosuper trick (from test_descr.py); that's where I discovered this behavior of __get__). *** typeobject.c.orig Sun Nov 11 13:34:35 2001 --- typeobject.c Sun Nov 11 13:53:02 2001 *************** *** 3887,3900 **** Py_INCREF(self); return self; } ! new = (superobject *)PySuper_Type.tp_new (&PySuper_Type, NULL, NULL); ! if (new == NULL) ! return NULL; ! Py_INCREF(su->type); ! Py_INCREF(obj); ! new->type = su->type; ! new->obj = obj; ! return (PyObject *)new; } static int --- 3887,3905 ---- Py_INCREF(self); return self; } ! if (su->ob_type != &PySuper_Type) ! /* if su is a subclass, call its type */ ! return PyObject_CallFunction((PyObject *)su->ob_type, "OO", su->type, obj); ! else { ! new = (superobject *) PySuper_Type.tp_new(&PySuper_Type, NULL, NULL); ! if (new == NULL) ! return NULL; ! Py_INCREF(su->type); ! Py_INCREF(obj); ! new->type = su->type; ! new->obj = obj; ! return (PyObject *)new; ! } } static int ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-11-11 14:12 Message: Logged In: YES user_id=86307 I see that pasting in the patch lost all the formatting; I've reattached it as a file. Also, I generated it using v. 2.117 of typeobject.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480716&group_id=5470 From noreply@sourceforge.net Mon Dec 3 08:15:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 00:15:49 -0800 Subject: [Patches] [ python-Patches-488073 ] AtheOS port of Python 2.2b2 Message-ID: Patches item #488073, was opened at 2001-12-02 05:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None >Priority: 4 Submitted By: Octavian Cerna (tavyc) Assigned to: Nobody/Anonymous (nobody) Summary: AtheOS port of Python 2.2b2 Initial Comment: Hi, While I was playing with AtheOS in the last few days, I saw that it comes with Python 1.5.2. Being a Python enthusiast, I tried to see if a recent version of Python would work. It did not even compile, so I decided to port it, knowing that AtheOS is almost POSIX-compatible. The result is a full-blown Python port with only a (relative) small amount of changes, that builds OOTB. And here it is, with all the details: About the patch: - The diff is against CVS 2001-11-26 - 20 files changed, 1962 insertions, 23 deletions - It does not include changes to autoconf-generated files - The patch includes a few very small fixes not directly related to the AtheOS port, but which were necessary to ensure the port works OK: - setup.py - look for the _curses_panel.c file in $srcdir/Modules, not in $PWD/Modules (otherwise VPATH builds will not build _curses_panel.so) - Makefile.pre.in - only ranlib *.a files (how will this affect other ports?) - Tools/freeze/bkfile.py - not all platforms have the file.truncate method - Tools/scripts/h2py.py - environment- paths code was made more portable Environment: - AtheOS 0.3.6 - gcc 2.95.2 - binutils 2.10 - glibc 2.1.2 Features: - Dynamic loading of modules - Native thread support Issues: Although AtheOS is not a BeOS clone, it is in many ways similar to BeOS, and some issues from BeOS also apply on AtheOS. - dlopen is not properly implemented, so I had to add support for native dynamic loading. - The POSIX threads emulation is almost inexistent, so I added support for native AtheOS threads. - AtheOS doesn't support importing symbols in a shared library from the main executable (the `-export-dynamic' linker flag), so the Python core must be built as a shared library, like on BeOS. - mmap is not implemented in AtheOS, the mmap module was disabled - statvfs is not implemented, os.statvfs and os.fstatvfs disabled - crypt on AtheOS crashes with SEGV if salt is not "$1$" (glibc bug?), disabled - poll - it seems that poll never returns POLLNVAL for an invalid fd (hangs), disabled - Don't mix threading with fork() -- see test_popen2 below. All tests pass, except: - test_nis hangs on my system, probably because NIS is not set up - test_popen2 hangs when imported from regrtest.py, otherwise working (like on BeOS). I suspect that the import semaphore is locked when popen2 forks and AtheOS doesn't like that. - test_mhlib fails, I don't know exactly why, but I suspect a filesystem issue (It corrupted some of my files several times, and I don't want to run it again ;) - test_locale skipped, locale en_US not supported (maybe something's wrong with my environment?) - test_largefile skipped (unless you tell it to eat 2GB disk space) because apparently afs doesn't support sparse files. Notes: - If you build Python, make sure you have shared versions of your libraries and you have links in /system/libs for them, otherwise the kernel won't load modules. AtheOS doesn't have a shared version for each library, I had serious problems with ncurses and the _curses_panel module. Binary packages: - I have prepared binary packages of Python-2.2b2 and Numeric-20.2.1 for testing, I will post them on kamidake.org later. Future: - I'm going to try Zope these days, I think it should work with a minimum amount of changes, almost OOTB ;) (Maybe I should have included this text in the README file?) Please excuse my bad English, I am not a native speaker :) Python is an excellent language/environment, keep going with the good work! -------- Best Regards, Octavian Cerna (Tavy) yLabs ---------------------------------------------------------------------- Comment By: Octavian Cerna (tavyc) Date: 2001-12-02 10:40 Message: Logged In: YES user_id=382173 I know that Python is now in a "feature freeze" or something similar, but this patch could go in Python 2.3. I added the HAVE_GETADDRINFO to acconfig.h because it was simply missing and autoheader complained, (outdated CVS snapshot). I should have removed it from the patch. I posted it here just to make it available to anyone who wants to try it out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 07:42 Message: Logged In: YES user_id=21627 I'd advise not to add this port so shortly before 2.2, in particular since these changes need careful review. As an example: Why does it add HAVE_GETADDRINFO to acconfig.h? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 From noreply@sourceforge.net Mon Dec 3 08:25:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 00:25:21 -0800 Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c Message-ID: Patches item #487906, was opened at 2001-12-01 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: update inline docs in stringobject.c Initial Comment: --- Objects/stringobject.c 2001/11/28 20:27:42 2.141 +++ Objects/stringobject.c 2001/12/01 20:40:09 @@ -19,19 +19,26 @@ #endif /* - Newsizedstringobject() and newstringobject() try in certain cases + PyString_FromStringAndSize() and PyString_FromString() try in certain cases to share string objects. When the size of the string is zero, these routines always return a pointer to the same string object; when the size is one, they return a pointer to an already existing object if the contents of the string is known. For - newstringobject() this is always the case, for - newsizedstringobject() this is the case when the first argument in + PyString_FromString() this is always the case, for + PyString_FromStringAndSize() this is the case when the first argument in not NULL. - A common practice to allocate a string and then fill it in or - change it must be done carefully. It is only allowed to change the - contents of the string if the obect was gotten from - newsizedstringobject() with a NULL first argument, because in the + A common practice of allocating a string and then filling it in or + changing it must be done carefully. It is only allowed to change the + contents of the string if the object was gotten from + PyString_FromStringAndSize() with a NULL first argument, because in the future these routines may try to do even more sharing of objects. + + The parameter `size' denotes number of characters in the string, not number + of bytes requires to store it, and does not count the null terminating + character. + + On the other hand, the member `op->ob_size' denotes the number of bytes + used for storing the string, including the null terminating character. */ PyObject * PyString_FromStringAndSize(const char *str, int size) @@ -58,7 +65,7 @@ ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 00:25 Message: Logged In: YES user_id=21627 Even though this comment is right, it now reads as a contradiction, since two sentences later, it says If the `str' argument is not NULL, then it must point to a null-terminated string of length `size'. I've reformulated this somewhat, and commmitted your text. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-02 10:50 Message: Logged In: YES user_id=52562 Here's one more addition to the in-line docs. I was trying to optimize `PyString_FromStringAndSize()' and I broke it because I didn't realize this fact, so I added this fact to the docs. :-) (pasted and attached) --- Objects/stringobject.c 2001/12/02 18:09:41 2.142 +++ Objects/stringobject.c 2001/12/02 18:47:48 @@ -33,6 +33,10 @@ a NULL first argument, because in the future these routines may try to do even more sharing of objects. + The string in the `str' parameter does not have to be null-character + terminated. (Therefore it is safe to construct a substring by using + `PyString_FromStringAndSize(origstring, substrlen)'.) + The parameter `size' denotes number of characters to allocate, not counting the null terminating character. If the `str' argument is not NULL, then it must point to a null-terminated string of length `size'. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 10:10 Message: Logged In: YES user_id=21627 It's not just upload that is difficult; download has its speed bumps as well. Mozilla insists to call all files downloaded from SF "download.php", no matter what filename SF has recorded... Thanks for the patch; it is in stringobject.c 2.142. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-02 08:47 Message: Logged In: YES user_id=52562 Heh heh heh. I can't wait for the day that we can remotely collaborate with something other than a web browser as the user interface. Okay, sorry, here is a newer version of the patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 07:34 Message: Logged In: YES user_id=21627 There is currently nothing attached. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-12-01 12:44 Message: Logged In: YES user_id=52562 Okay I guess that's all mangled. DAMN, I hate trying to use a web browser for anything other than browsing. Anyway, I've attached the same patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470 From noreply@sourceforge.net Mon Dec 3 15:41:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 07:41:51 -0800 Subject: [Patches] [ python-Patches-480716 ] Support for super subclasses Message-ID: Patches item #480716, was opened at 2001-11-11 14:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480716&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Greg Chapman (glchapman) Assigned to: Guido van Rossum (gvanrossum) Summary: Support for super subclasses Initial Comment: In Python 2.2b1, super is subclassable, however its __get__ (tp_descr_get) method always returns a new instance of super (not of its actual (sub)class). I think if super is to be subclassable, __get__ should return a new instance of the subclass. (I've been experimenting with using super instances to get and set the value of inherited attributes (properties). For this I needed a super subclass with a __setattr__ method. I also wanted to use the autosuper trick (from test_descr.py); that's where I discovered this behavior of __get__). *** typeobject.c.orig Sun Nov 11 13:34:35 2001 --- typeobject.c Sun Nov 11 13:53:02 2001 *************** *** 3887,3900 **** Py_INCREF(self); return self; } ! new = (superobject *)PySuper_Type.tp_new (&PySuper_Type, NULL, NULL); ! if (new == NULL) ! return NULL; ! Py_INCREF(su->type); ! Py_INCREF(obj); ! new->type = su->type; ! new->obj = obj; ! return (PyObject *)new; } static int --- 3887,3905 ---- Py_INCREF(self); return self; } ! if (su->ob_type != &PySuper_Type) ! /* if su is a subclass, call its type */ ! return PyObject_CallFunction((PyObject *)su->ob_type, "OO", su->type, obj); ! else { ! new = (superobject *) PySuper_Type.tp_new(&PySuper_Type, NULL, NULL); ! if (new == NULL) ! return NULL; ! Py_INCREF(su->type); ! Py_INCREF(obj); ! new->type = su->type; ! new->obj = obj; ! return (PyObject *)new; ! } } static int ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 07:41 Message: Logged In: YES user_id=6380 Checked in, with some changes; see typeobject.c 2.120. (Note that this implies a restriction on the signature of __init__ for subclasses; I think that's fine in this case, but not necessarily in general, and one can argue about that.) ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-11-11 14:12 Message: Logged In: YES user_id=86307 I see that pasting in the patch lost all the formatting; I've reattached it as a file. Also, I generated it using v. 2.117 of typeobject.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480716&group_id=5470 From noreply@sourceforge.net Mon Dec 3 15:57:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 07:57:06 -0800 Subject: [Patches] [ python-Patches-488452 ] Webbrowser should use IC on Mac OS X Message-ID: Patches item #488452, was opened at 2001-12-03 07:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488452&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Webbrowser should use IC on Mac OS X Initial Comment: the webbrowser module should use Internet Config as the default way of finding the users' preferred web browser on Mac OS X. In MacPython it does, but the code needs to be added for Unix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488452&group_id=5470 From noreply@sourceforge.net Mon Dec 3 19:26:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 11:26:41 -0800 Subject: [Patches] [ python-Patches-486375 ] Use charset in email.Utils.encode Message-ID: Patches item #486375, was opened at 2001-11-27 22:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486375&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 7 Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Barry Warsaw (bwarsaw) Summary: Use charset in email.Utils.encode Initial Comment: Here's a patch that makes email.Utils.encode actually _use_ its charset parameter. Note: a string is encoded into the specified character set using the 'replace' mode in order to provide high tolerance for missing characters, typical for email applications. The patch also slightly optimizes the code around (cough cough). ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-03 11:26 Message: Logged In: YES user_id=12800 Sorry, but this isn't correct. email.Utils.encode() states that the argument "s" must already be encoded in the given character set. The charset argument is required because Python can't guess what charset s is encoded in. I'm rejecting this patch, although I'll install the optimizations from it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486375&group_id=5470 From noreply@sourceforge.net Tue Dec 4 04:14:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 20:14:16 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 7 Submitted By: Hye-Shik Chang (perky) Assigned to: Jeremy Hylton (jhylton) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2001-12-03 20:14 Message: Logged In: YES user_id=55188 On the ENOTCONN error: the error will be raised only if 'sock' was bound outside. (even if self.accepting get set) but using out-bound socket is unavoidable for some server models. and I and some co-workers are using it. How about this way instead of previous patch? if not self.accepting: self.addr = sock.getpeername() On passing maps: some part of asyncore supports using own socket map. (__init__, add_channel, del_channel), but when __init__ registers socket into map which passed by argument, asyncore can't del_channel from own map and it will raises KeyError because asyncore.socket_map doesn't have such fileno. And, current version of asynchat doesn't support to use another maps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:03 Message: Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Tue Dec 4 06:44:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 22:44:27 -0800 Subject: [Patches] [ python-Patches-488749 ] MacOS 8.1 support in IDE, W Message-ID: Patches item #488749, was opened at 2001-12-03 22:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) Assigned to: Jack Jansen (jackjansen) Summary: MacOS 8.1 support in IDE, W Initial Comment: These patches allow the IDE and W framework to continue working under MacOS 8.1. All calls to (Get|Set)ControlViewSize are allowed to silently fail with a NotImplementedError - they're only relevant with proportional scrollbars, which appeared in 8.5. 8.1 doesn't support (Get|Set)Control32Bit(Value|Minimum| Maximum), so always use or fall back to the original 16- bit versions when possible. (The 16-bit calls are listed as fully supported under Carbon, so this shouldn't introduce any compatibility problems.) The only time a control is likely to need a full 32-bit parameter is a scrollbar for a very tall document: errors will occur when trying to edit a file taller than 32K pixels (2500+ lines of 9-point text) under 8.1, but this bug doesn't prevent the file from being saved. Made 32-bit control parameters work better on the system versions that do support them: large values can be passed to the ControlWidget constructor, in which case NewControl is called with zeros, and the actual value then set via a 32-bit call. Changed Wtext's scrollbar routines to explicitly disable scrollbars when their max is <= their min (which is automatically done in later systems, I don't think there will be any problem with this being done twice). Fixed up Appearance support for Wlists, they now fully use Appearance frames & focusing. Tried to do the same for Wtext, but ran into some problems - there are lots of places that assume that an EditText's border is exactly one pixel thick and located just inside the widget bounds (for example, the line number field in PyEditor windows). I left my commented- out changes in the code for the benefit of anyone who tries to fix this later, but for now the frame of EditText boxes is still a Qd.FrameRect. I have NOT tested these patches with anything except 8.1. Running the Panes or Two Lists widget demo, and tabbing/resizing/deactivating/activating the window, will exercise most of the changes I've made. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 From noreply@sourceforge.net Tue Dec 4 11:28:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 03:28:16 -0800 Subject: [Patches] [ python-Patches-488749 ] MacOS 8.1 support in IDE, W Message-ID: Patches item #488749, was opened at 2001-12-03 22:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) >Assigned to: Just van Rossum (jvr) Summary: MacOS 8.1 support in IDE, W Initial Comment: These patches allow the IDE and W framework to continue working under MacOS 8.1. All calls to (Get|Set)ControlViewSize are allowed to silently fail with a NotImplementedError - they're only relevant with proportional scrollbars, which appeared in 8.5. 8.1 doesn't support (Get|Set)Control32Bit(Value|Minimum| Maximum), so always use or fall back to the original 16- bit versions when possible. (The 16-bit calls are listed as fully supported under Carbon, so this shouldn't introduce any compatibility problems.) The only time a control is likely to need a full 32-bit parameter is a scrollbar for a very tall document: errors will occur when trying to edit a file taller than 32K pixels (2500+ lines of 9-point text) under 8.1, but this bug doesn't prevent the file from being saved. Made 32-bit control parameters work better on the system versions that do support them: large values can be passed to the ControlWidget constructor, in which case NewControl is called with zeros, and the actual value then set via a 32-bit call. Changed Wtext's scrollbar routines to explicitly disable scrollbars when their max is <= their min (which is automatically done in later systems, I don't think there will be any problem with this being done twice). Fixed up Appearance support for Wlists, they now fully use Appearance frames & focusing. Tried to do the same for Wtext, but ran into some problems - there are lots of places that assume that an EditText's border is exactly one pixel thick and located just inside the widget bounds (for example, the line number field in PyEditor windows). I left my commented- out changes in the code for the benefit of anyone who tries to fix this later, but for now the frame of EditText boxes is still a Qd.FrameRect. I have NOT tested these patches with anything except 8.1. Running the Panes or Two Lists widget demo, and tabbing/resizing/deactivating/activating the window, will exercise most of the changes I've made. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 03:28 Message: Logged In: YES user_id=45365 Just, I had a quick look at this patch (only a look, not tried it) and to me it looks fine. Jason did this patch on my request, so that 2.2 will run on MacOS 8.1 (it'll be the last MacPython to run on that system). Could you have a look at these and apply them, or assign them back to me if you don't have the time? You definitely should have a look at the frame stuff, which is over my head. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 From noreply@sourceforge.net Tue Dec 4 11:59:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 03:59:32 -0800 Subject: [Patches] [ python-Patches-488749 ] MacOS 8.1 support in IDE, W Message-ID: Patches item #488749, was opened at 2001-12-03 22:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) Assigned to: Just van Rossum (jvr) Summary: MacOS 8.1 support in IDE, W Initial Comment: These patches allow the IDE and W framework to continue working under MacOS 8.1. All calls to (Get|Set)ControlViewSize are allowed to silently fail with a NotImplementedError - they're only relevant with proportional scrollbars, which appeared in 8.5. 8.1 doesn't support (Get|Set)Control32Bit(Value|Minimum| Maximum), so always use or fall back to the original 16- bit versions when possible. (The 16-bit calls are listed as fully supported under Carbon, so this shouldn't introduce any compatibility problems.) The only time a control is likely to need a full 32-bit parameter is a scrollbar for a very tall document: errors will occur when trying to edit a file taller than 32K pixels (2500+ lines of 9-point text) under 8.1, but this bug doesn't prevent the file from being saved. Made 32-bit control parameters work better on the system versions that do support them: large values can be passed to the ControlWidget constructor, in which case NewControl is called with zeros, and the actual value then set via a 32-bit call. Changed Wtext's scrollbar routines to explicitly disable scrollbars when their max is <= their min (which is automatically done in later systems, I don't think there will be any problem with this being done twice). Fixed up Appearance support for Wlists, they now fully use Appearance frames & focusing. Tried to do the same for Wtext, but ran into some problems - there are lots of places that assume that an EditText's border is exactly one pixel thick and located just inside the widget bounds (for example, the line number field in PyEditor windows). I left my commented- out changes in the code for the benefit of anyone who tries to fix this later, but for now the frame of EditText boxes is still a Qd.FrameRect. I have NOT tested these patches with anything except 8.1. Running the Panes or Two Lists widget demo, and tabbing/resizing/deactivating/activating the window, will exercise most of the changes I've made. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2001-12-04 03:59 Message: Logged In: YES user_id=92689 Thanks for this patch: looks good to me. Jack: is it easy for you to check it in? For me it's not. Alternatively: Jason: could you send me the modified files? Thanks. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 03:28 Message: Logged In: YES user_id=45365 Just, I had a quick look at this patch (only a look, not tried it) and to me it looks fine. Jason did this patch on my request, so that 2.2 will run on MacOS 8.1 (it'll be the last MacPython to run on that system). Could you have a look at these and apply them, or assign them back to me if you don't have the time? You definitely should have a look at the frame stuff, which is over my head. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 From noreply@sourceforge.net Tue Dec 4 12:01:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 04:01:57 -0800 Subject: [Patches] [ python-Patches-488749 ] MacOS 8.1 support in IDE, W Message-ID: Patches item #488749, was opened at 2001-12-03 22:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) >Assigned to: Jack Jansen (jackjansen) Summary: MacOS 8.1 support in IDE, W Initial Comment: These patches allow the IDE and W framework to continue working under MacOS 8.1. All calls to (Get|Set)ControlViewSize are allowed to silently fail with a NotImplementedError - they're only relevant with proportional scrollbars, which appeared in 8.5. 8.1 doesn't support (Get|Set)Control32Bit(Value|Minimum| Maximum), so always use or fall back to the original 16- bit versions when possible. (The 16-bit calls are listed as fully supported under Carbon, so this shouldn't introduce any compatibility problems.) The only time a control is likely to need a full 32-bit parameter is a scrollbar for a very tall document: errors will occur when trying to edit a file taller than 32K pixels (2500+ lines of 9-point text) under 8.1, but this bug doesn't prevent the file from being saved. Made 32-bit control parameters work better on the system versions that do support them: large values can be passed to the ControlWidget constructor, in which case NewControl is called with zeros, and the actual value then set via a 32-bit call. Changed Wtext's scrollbar routines to explicitly disable scrollbars when their max is <= their min (which is automatically done in later systems, I don't think there will be any problem with this being done twice). Fixed up Appearance support for Wlists, they now fully use Appearance frames & focusing. Tried to do the same for Wtext, but ran into some problems - there are lots of places that assume that an EditText's border is exactly one pixel thick and located just inside the widget bounds (for example, the line number field in PyEditor windows). I left my commented- out changes in the code for the benefit of anyone who tries to fix this later, but for now the frame of EditText boxes is still a Qd.FrameRect. I have NOT tested these patches with anything except 8.1. Running the Panes or Two Lists widget demo, and tabbing/resizing/deactivating/activating the window, will exercise most of the changes I've made. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 04:01 Message: Logged In: YES user_id=45365 I'll check it in and assign it back to you (Just) for testing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2001-12-04 03:59 Message: Logged In: YES user_id=92689 Thanks for this patch: looks good to me. Jack: is it easy for you to check it in? For me it's not. Alternatively: Jason: could you send me the modified files? Thanks. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 03:28 Message: Logged In: YES user_id=45365 Just, I had a quick look at this patch (only a look, not tried it) and to me it looks fine. Jason did this patch on my request, so that 2.2 will run on MacOS 8.1 (it'll be the last MacPython to run on that system). Could you have a look at these and apply them, or assign them back to me if you don't have the time? You definitely should have a look at the frame stuff, which is over my head. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 From noreply@sourceforge.net Tue Dec 4 12:33:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 04:33:53 -0800 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: Closed 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 Dec 4 13:31:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 05:31:57 -0800 Subject: [Patches] [ python-Patches-488749 ] MacOS 8.1 support in IDE, W Message-ID: Patches item #488749, was opened at 2001-12-03 22:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) >Assigned to: Just van Rossum (jvr) Summary: MacOS 8.1 support in IDE, W Initial Comment: These patches allow the IDE and W framework to continue working under MacOS 8.1. All calls to (Get|Set)ControlViewSize are allowed to silently fail with a NotImplementedError - they're only relevant with proportional scrollbars, which appeared in 8.5. 8.1 doesn't support (Get|Set)Control32Bit(Value|Minimum| Maximum), so always use or fall back to the original 16- bit versions when possible. (The 16-bit calls are listed as fully supported under Carbon, so this shouldn't introduce any compatibility problems.) The only time a control is likely to need a full 32-bit parameter is a scrollbar for a very tall document: errors will occur when trying to edit a file taller than 32K pixels (2500+ lines of 9-point text) under 8.1, but this bug doesn't prevent the file from being saved. Made 32-bit control parameters work better on the system versions that do support them: large values can be passed to the ControlWidget constructor, in which case NewControl is called with zeros, and the actual value then set via a 32-bit call. Changed Wtext's scrollbar routines to explicitly disable scrollbars when their max is <= their min (which is automatically done in later systems, I don't think there will be any problem with this being done twice). Fixed up Appearance support for Wlists, they now fully use Appearance frames & focusing. Tried to do the same for Wtext, but ran into some problems - there are lots of places that assume that an EditText's border is exactly one pixel thick and located just inside the widget bounds (for example, the line number field in PyEditor windows). I left my commented- out changes in the code for the benefit of anyone who tries to fix this later, but for now the frame of EditText boxes is still a Qd.FrameRect. I have NOT tested these patches with anything except 8.1. Running the Panes or Two Lists widget demo, and tabbing/resizing/deactivating/activating the window, will exercise most of the changes I've made. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 05:31 Message: Logged In: YES user_id=45365 Checked in, and done minimal testing (IDE still runs:-), I'll leave real testing and possibly integration of the Wtext mods to you. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 04:01 Message: Logged In: YES user_id=45365 I'll check it in and assign it back to you (Just) for testing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2001-12-04 03:59 Message: Logged In: YES user_id=92689 Thanks for this patch: looks good to me. Jack: is it easy for you to check it in? For me it's not. Alternatively: Jason: could you send me the modified files? Thanks. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 03:28 Message: Logged In: YES user_id=45365 Just, I had a quick look at this patch (only a look, not tried it) and to me it looks fine. Jason did this patch on my request, so that 2.2 will run on MacOS 8.1 (it'll be the last MacPython to run on that system). Could you have a look at these and apply them, or assign them back to me if you don't have the time? You definitely should have a look at the frame stuff, which is over my head. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:19:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:19:44 -0800 Subject: [Patches] [ python-Patches-477750 ] Use METH_ constants in Modules Message-ID: Patches item #477750, was opened at 2001-11-03 02:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Jeremy Hylton (jhylton) Summary: Use METH_ constants in Modules Initial Comment: This patch addes METH_OLDARGS and METH_VARARGS into every method table (except for curses, for which a separate patch is upcoming). ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:19 Message: Logged In: YES user_id=31392 We should probably wait until after 2.2 to make all these changes. I expect they're harmless, but it's a lot of code to change at the last minute. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470 From noreply@sourceforge.net Tue Dec 4 17:43:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 09:43:37 -0800 Subject: [Patches] [ python-Patches-485789 ] webbrowser.py: os.pathsep instead of : Message-ID: Patches item #485789, was opened at 2001-11-26 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485789&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) >Assigned to: Guido van Rossum (gvanrossum) Summary: webbrowser.py: os.pathsep instead of : Initial Comment: Line 317 (in CVS rev. 1.23) should be _tryorder = os.environ["BROWSER"].split(os.pathsep) instead of _tryorder = os.environ["BROWSER"].split(":") ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 09:43 Message: Logged In: YES user_id=6380 Thanks -- applied in CVS 1.26. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485789&group_id=5470 From noreply@sourceforge.net Tue Dec 4 17:45:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 09:45:10 -0800 Subject: [Patches] [ python-Patches-483085 ] Include windows default temp dir Message-ID: Patches item #483085, was opened at 2001-11-18 07:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483085&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Emile van Sebille (evansebille) >Assigned to: Tim Peters (tim_one) Summary: Include windows default temp dir Initial Comment: Include os.getenv('TEMP') in attempdirs so that temp files by default are created per the environment setting. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 09:45 Message: Logged In: YES user_id=6380 Tim, does this look reasonable to you? It does to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483085&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:08:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:08:50 -0800 Subject: [Patches] [ python-Patches-479898 ] Multibyte string on string::string_print Message-ID: Patches item #479898, was opened at 2001-11-08 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Multibyte string on string::string_print Initial Comment: Many multibyte language users are difficult to see native characters on list or dictionary and etc. This patch allows printing multibyte on UNIX98- compatible machines; mbtowc() is ISO/IEC 9899:1990 standard C-API function. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:08 Message: Logged In: YES user_id=6380 I don't understand the point of using mbtowc() here. The code extracts a wide character, but then it uses isprint() on it, and as far as I know, isprint() is not defined on wide characters, only on 'unsigned char' (and on -1). Isn't what the author wants simply to is isprint(c) instead of (c < ' ' || c >= 0x7f)??? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 13:21 Message: Logged In: YES user_id=21627 Even though I think this patch is correct in principle, I see a few problems with it: 1. Since it doesn't fix a bug, it probably cannot go into 2.2. 2. There is no autoconf test for mbtowc. You should test this in configure, and then conditionalize your code on HAVE_MBTOWC. 3. There is too much code duplication. Try to find a solution which special-cases the escape codes (\something) only once. For example, you may implement a trivial mbtowc redefinition if mbtowc is not available, and then use mbtowc always. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:12:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:12:59 -0800 Subject: [Patches] [ python-Patches-480562 ] replace __slots__ with addmembers Message-ID: Patches item #480562, was opened at 2001-11-11 01:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480562&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michael McLay (mclay) >Assigned to: Guido van Rossum (gvanrossum) Summary: replace __slots__ with addmembers Initial Comment: This patch replaces the __slots__ syntax in the following example: >>> class B(object): """class B's docstring """ __slots__ = ['a','b','c','d'] The new syntax includes support for docstrings, default values, and optional typechecking (using isinstance). >>> class B(object): """class B's docstring """ a = addmember(types=int, default=56, doc="a docstring") b = addmember(types=int, doc="b's docstring") c = addmember(types=(int,float), default=5.0, doc="c docstring") d = addmember(types=(str,float), default="ham", doc="d docstring") >>> b = B() >>> b.a 56 >>> b.d 'ham' >>> b.b Traceback (most recent call last): File "", line 1, in ? b.b TypeError: The value of B.b is of type 'type'. This is not one of the defined types The addmembers.txt file in the attachment describes the patch in more detail. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:12 Message: Logged In: YES user_id=6380 I appreciate the work that went into this, but I'm rejecting it anyway. I want to come up with a better syntax for creating slots (and lots of other new 2.2 features) later, but I don't want to hurry into this for 2.2, and I'm positive that by the time I'll be ready, this patch will be too outdated to apply. ---------------------------------------------------------------------- Comment By: Michael McLay (mclay) Date: 2001-11-11 02:21 Message: Logged In: YES user_id=28214 Opps, forgot to check the box for the attachment. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480562&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:14:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:14:29 -0800 Subject: [Patches] [ python-Patches-477330 ] add __slot_docs__ and __slot_types__ Message-ID: Patches item #477330, was opened at 2001-11-01 15:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477330&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michael McLay (mclay) >Assigned to: Guido van Rossum (gvanrossum) Summary: add __slot_docs__ and __slot_types__ Initial Comment: The slot members defined using__slots__ cannot be assigned doc strings in the current implementation. This patch adds the ability to attach doc strings to a slot member by assigning a dictionary to the __slot_docs__ class variable. >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } >>> B.a.__doc__ 'the a docstring' >>> The __slot_types__ class variable adds an optional type constraint for the slot. If a dictionary with a type or list of types is associated with a member name then the isinstance() method will be called on that member when the get and set methods for the member are called. >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } def __getattribute__(self,name): print "help please", name return object.__getattribute__(self, name) >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } >>> b = B() >>> b.a Traceback (most recent call last): File "", line 1, in ? b.a TypeError: The value of B.a is of type . This is not one of the defined slot_types >>> b.a = 4 >>> b.a 4 >>> b.a = 34.3 Traceback (most recent call last): File "", line 1, in ? b.a = 34.3 TypeError: The type of is not one of the defined slot_types for B.a >>> b.b >>> b.b = 3 >>> b.b = 34.2 >>> b.b 34.200000000000003 >>> b.a = "fish" >>> b.a 'fish' >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:14 Message: Logged In: YES user_id=6380 Rejecting, for the same reason why I rejected the addmember patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-02 21:14 Message: Logged In: YES user_id=31435 In Guido's absence (he's on leave the rest of November), I'm Postponing this. Feature cutoff for 2.2 has already occurred, and we've got all we can do (esp. in Guido's absence!) to finish what's already there. I don't even have time to mention that a patch without doc and test case changes is dead on arrival, let alone time to think about it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 16:13 Message: Logged In: YES user_id=21627 -1. I think there should be proper syntax for slots, which should include support for doc strings. The "optional static typing" part should be coordinated with PEP 245. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477330&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:22:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:22:13 -0800 Subject: [Patches] [ python-Patches-479796 ] Patch for Bug #411612 Message-ID: Patches item #479796, was opened at 2001-11-08 14:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479796&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Bryan Fordham (bfordham) >Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for Bug #411612 Initial Comment: Bug #411612 is the problem that the QUERY_STRING is not checked if the form action=="POST". This is a little patch to add the query string if it's there. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:22 Message: Logged In: YES user_id=6380 Rejecting. The patch is indeed broken as pointed out in the comment by loewis. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-11 06:33 Message: Logged In: YES user_id=21627 Isn't that the same patch as in #411612? Doesn't then the same comment apply: #Quick check: That "fix" does not work. It duplicates #the QUERY_STRING if you use the GET method. Additional #checks are necessary to ensure correct operation. Also, don't use plain diffs; please use context (-c) or unified (-u) diffs instead. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479796&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:32:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:32:51 -0800 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: Closed >Resolution: Rejected Priority: 5 Submitted By: Greg Wilson (gvwilson) >Assigned to: Guido van Rossum (gvanrossum) 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. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:32 Message: Logged In: YES user_id=6380 I *could* reject this for incompleteness, because it doesn't support binary literals. But instead I'll reject it for overcompleteness. The occasional (IMO rare) desire to see the binary representation of a number shouldn't require this the standard library to schlepp along this much code (and if I were to redesign Python today, oct() would be dropped too, and hex() would have less standard support). It's a fun exercise to write your own bin() function; here's mine: | def bin(x): | if x == 0: | return '0' | if x < 0: | s = '-' | x = -x | else: | s = '' | L = [] | while x: | L.append('01'[x&1]) | x /= 2 | L.append(s) | L.reverse() | return ''.join(L) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455076&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:33:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:33:26 -0800 Subject: [Patches] [ python-Patches-473586 ] SimpleXMLRPCServer - fixes and CGI Message-ID: Patches item #473586, was opened at 2001-10-22 00:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) >Assigned to: Fredrik Lundh (effbot) Summary: SimpleXMLRPCServer - fixes and CGI Initial Comment: Changes: o treats xmlrpclib.Fault's correctly (no longer absorbes them as generic exceptions) o changed failed marshal to generate a useful Fault instead of an internal server error o adds a new class to make writing XML-RPC functions embedded in other servers, using CGI, easier (tested with APACHE) o to support the above, added a new dispatch helper class SimpleXMLRPCDispatcher ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-23 11:02 Message: Logged In: YES user_id=108973 - a few extra comments - moved a xmlrpclib.loads() inside an exception handler so an XML-RPC fault is generated for malformed requests ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 11:59 Message: Logged In: YES user_id=108973 The advantage of the entire patch being accepted before 2.2 is that there is an API change and, once 2.2 is release, we will probably have to make a bit of an attempt to maintain backwards compatibility. If this patch is too high-risk for 2.2 then I can certainly design a bug-fix patch for 2.2 and submit a new patch for 2.3 (that is API compatible with 2.2). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-22 11:43 Message: Logged In: YES user_id=21627 Brian, please note that Python 2.2b1 has been released, so no new features are acceptable until 2.2. So unless Fredrik Lundh wants to accept your entire patch, I think it has little chance to get integrated for the next few months. If you want pieces of it accepted, I'd recommend to split it into bug fixes and new features; bug fixes are still acceptable. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 11:27 Message: Logged In: YES user_id=108973 I just can't stop mucking with it. This time there are only documentation changes. I should also have pointed out that this patch changes the mechanism for overriding the dispatch mechanism: you used to subclass the request handler, now you subclass the server. I believe that this change is correct because the server actually has the required state information to do the dispatching. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 00:35 Message: Logged In: YES user_id=108973 Changed a name to fit other naming conventions ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:37:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:37:09 -0800 Subject: [Patches] [ python-Patches-475009 ] build_scripts.post_interp is None Message-ID: Patches item #475009, was opened at 2001-10-25 12:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=475009&group_id=5470 >Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: A.M. Kuchling (akuchling) Summary: build_scripts.post_interp is None Initial Comment: in the first line regex, we assign group(1) to post_interp, which is None. So you get #!/usr/bin/pythonX.YNone as output, which is wrong. Heres da patch: --- build_scripts.py.orig Thu Oct 25 21:03:27 2001 +++ build_scripts.py Thu Oct 25 21:03:41 2001 @@ -80,7 +80,7 @@ match = first_line_re.match(first_line) if match: adjust = 1 - post_interp = match.group(1) + post_interp = match.group(1) or "" if adjust: self.announce("copying and adjusting %s -> %s" % ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2001-10-25 12:28 Message: Logged In: YES user_id=9205 This occurs only with versioned interpreters,e.g. #!/usr/bin/python2 -O Proper fix is to adjust the first_line_re. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=475009&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:39:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:39:37 -0800 Subject: [Patches] [ python-Patches-474532 ] avoid resizes in _PyString_Resize() Message-ID: Patches item #474532, was opened at 2001-10-24 09:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474532&group_id=5470 >Category: Core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) >Assigned to: Guido van Rossum (gvanrossum) Summary: avoid resizes in _PyString_Resize() Initial Comment: The patch below (against CVS 2001-10-24) avoids unnecessary calls to PyObject_REALLOC in _PyString_Resize if the size of the string does not change. When running the regression test with this patch on my Linux machine it shows that 53339 out of 323003 resizes can be avoided - this is more than 15%. Additionally I've added sanity checks in _PyStringResize to test for virgin values of ob_shash and ob_sinterned. Better safe than sorry. Markus --- Markus.F.X.J. Oberhumer --- author of PySol ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:39 Message: Logged In: YES user_id=6380 Rejected at MvL's recommendation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:43 Message: Logged In: YES user_id=21627 I recommend to reject this patch. If pymalloc is ever enabled by default, it will definitely find out that this is a noop fairly quickly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-24 15:15 Message: Logged In: YES user_id=31435 Hmm. I'm asking about speed, and you're counting how many calls are made. Not the same thing. I expect a production- quality realloc is doing its own "it's the same size -- I'm done" early-out test, in which case adding a new test to Python every time costs more every time, but the only payback is saving the dirt-cheap realloc calls. It would be much more interesting (to me) to determine why useless calls to _PyString_Resize() are getting made so often in PySol, and optimize those away instead. ---------------------------------------------------------------------- Comment By: Markus F.X.J. Oberhumer (mfx) Date: 2001-10-24 14:54 Message: Logged In: YES user_id=12151 Well, the motivation is that I came across this is that I'm playing around with some malloc implementation where a realloc() is relatively expensive. For some other statistics, starting up and playing PySol for about one minute gives 7400 out of 15800 resizes with the same size, so in this case the gain is almost 50%... And the acutal speed cost is just one "if". The two other checks were only added because they are obviously missing (or maybe _PyString_Resize should reset ob_shash and ob_interned). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-24 12:05 Message: Logged In: YES user_id=31435 Markus, why do you care how ofen realloc is called? More importantly, why should we ? This would be more interesting if you had evidence of a measurable, significant speedup. The test suite runs a lot of peculiar code, and I've got no reason to believe that the 15% difference you saw running that is typical, or even enough to make up for the new costs of the additional failure tests you added here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474532&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:43:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:43:57 -0800 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: Closed >Resolution: Rejected Priority: 3 Submitted By: Luke Kenneth Casson Leighton (lkcl) >Assigned to: Guido van Rossum (gvanrossum) 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-12-04 11:43 Message: Logged In: YES user_id=6380 Rejected -- it's not worth having this linger around forever if nobody has the time to work on it. ---------------------------------------------------------------------- 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 Tue Dec 4 19:44:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:44:45 -0800 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: Guido van Rossum (gvanrossum) 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-12-04 11:44 Message: Logged In: YES user_id=6380 Gregor, care to respond? Or should I just reject this? ---------------------------------------------------------------------- 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 Tue Dec 4 19:51:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:51:21 -0800 Subject: [Patches] [ python-Patches-473586 ] SimpleXMLRPCServer - fixes and CGI Message-ID: Patches item #473586, was opened at 2001-10-22 00:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Fredrik Lundh (effbot) Summary: SimpleXMLRPCServer - fixes and CGI Initial Comment: Changes: o treats xmlrpclib.Fault's correctly (no longer absorbes them as generic exceptions) o changed failed marshal to generate a useful Fault instead of an internal server error o adds a new class to make writing XML-RPC functions embedded in other servers, using CGI, easier (tested with APACHE) o to support the above, added a new dispatch helper class SimpleXMLRPCDispatcher ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-12-04 11:51 Message: Logged In: YES user_id=108973 Please do not accept this patch past 2.2 release; there are so non-backwards compatible changes that need to be though through. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-23 11:02 Message: Logged In: YES user_id=108973 - a few extra comments - moved a xmlrpclib.loads() inside an exception handler so an XML-RPC fault is generated for malformed requests ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 11:59 Message: Logged In: YES user_id=108973 The advantage of the entire patch being accepted before 2.2 is that there is an API change and, once 2.2 is release, we will probably have to make a bit of an attempt to maintain backwards compatibility. If this patch is too high-risk for 2.2 then I can certainly design a bug-fix patch for 2.2 and submit a new patch for 2.3 (that is API compatible with 2.2). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-22 11:43 Message: Logged In: YES user_id=21627 Brian, please note that Python 2.2b1 has been released, so no new features are acceptable until 2.2. So unless Fredrik Lundh wants to accept your entire patch, I think it has little chance to get integrated for the next few months. If you want pieces of it accepted, I'd recommend to split it into bug fixes and new features; bug fixes are still acceptable. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 11:27 Message: Logged In: YES user_id=108973 I just can't stop mucking with it. This time there are only documentation changes. I should also have pointed out that this patch changes the mechanism for overriding the dispatch mechanism: you used to subclass the request handler, now you subclass the server. I believe that this change is correct because the server actually has the required state information to do the dispatching. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 00:35 Message: Logged In: YES user_id=108973 Changed a name to fit other naming conventions ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470 From noreply@sourceforge.net Tue Dec 4 20:07:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 12:07:34 -0800 Subject: [Patches] [ python-Patches-487634 ] Fix for NDEBUG problem and extensions Message-ID: Patches item #487634, was opened at 2001-11-30 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487634&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Rejected Priority: 7 Submitted By: Robin Dunn (robind) Assigned to: Tim Peters (tim_one) Summary: Fix for NDEBUG problem and extensions Initial Comment: Python.h defines NDEBUG if not Py_DEBUG. This causes problems if 3rd party code has #ifdef NDEBUG's and is linked with other code that includes Python.h. See http://mail.python.org/pipermail/python-dev/2001-November/018669.html for more info. This patch simply undef's NDEBUG in Python.h after it includes assert.h if it was not defined before. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-04 12:07 Message: Logged In: YES user_id=31435 I'm rejecting this -- besides that it may create unknown problems across platforms, it's anti-social to insist that anyone including Python.h will have their assert stmts vanish. The right solution is the original one: have Python release builds define NDEBUG on the command line (as the Windows build has always done). Include/Python.h revision 2.40 removes the NDEBUG fiddling entirely; I'll open a new bug report to get the non-Windows builds repaired. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487634&group_id=5470 From noreply@sourceforge.net Tue Dec 4 20:42:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 12:42:19 -0800 Subject: [Patches] [ python-Patches-489066 ] Include RLIM_INFINITY constant Message-ID: Patches item #489066, was opened at 2001-12-04 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489066&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: Include RLIM_INFINITY constant Initial Comment: The following is a patch to the resource module to include the RLIM_INFINITY constant. It should handle platforms where RLIM_INFINITY is not a LONG_LONG, but I have no means to test that. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489066&group_id=5470 From noreply@sourceforge.net Tue Dec 4 21:27:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 13:27:18 -0800 Subject: [Patches] [ python-Patches-483085 ] Include windows default temp dir Message-ID: Patches item #483085, was opened at 2001-11-18 07:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483085&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Emile van Sebille (evansebille) Assigned to: Tim Peters (tim_one) Summary: Include windows default temp dir Initial Comment: Include os.getenv('TEMP') in attempdirs so that temp files by default are created per the environment setting. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-04 13:27 Message: Logged In: YES user_id=31435 Emile, I don't understand what the patch accomplishes for you. gettempdir() already contains these lines later: """ . for envname in 'TMPDIR', 'TEMP', 'TMP': . if os.environ.has_key(envname): . attempdirs.insert(0, os.environ[envname]) """ so if you have a TEMP envar set on Windows, its value should already be getting prepended to attemdirs (and it does, on my Win2K box -- doesn't it work on your box?). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 09:45 Message: Logged In: YES user_id=6380 Tim, does this look reasonable to you? It does to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483085&group_id=5470 From noreply@sourceforge.net Tue Dec 4 22:31:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 14:31:58 -0800 Subject: [Patches] [ python-Patches-483085 ] Include windows default temp dir Message-ID: Patches item #483085, was opened at 2001-11-18 07:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483085&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Emile van Sebille (evansebille) Assigned to: Tim Peters (tim_one) Summary: Include windows default temp dir Initial Comment: Include os.getenv('TEMP') in attempdirs so that temp files by default are created per the environment setting. ---------------------------------------------------------------------- >Comment By: Emile van Sebille (evansebille) Date: 2001-12-04 14:31 Message: Logged In: YES user_id=41612 Tim, I see that now. At the time, I thought it was my change that put it in there, but I also changed the envars at the same time and missed that it would have done it anyway. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-04 13:27 Message: Logged In: YES user_id=31435 Emile, I don't understand what the patch accomplishes for you. gettempdir() already contains these lines later: """ . for envname in 'TMPDIR', 'TEMP', 'TMP': . if os.environ.has_key(envname): . attempdirs.insert(0, os.environ[envname]) """ so if you have a TEMP envar set on Windows, its value should already be getting prepended to attemdirs (and it does, on my Win2K box -- doesn't it work on your box?). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 09:45 Message: Logged In: YES user_id=6380 Tim, does this look reasonable to you? It does to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483085&group_id=5470 From noreply@sourceforge.net Tue Dec 4 23:14:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 15:14:45 -0800 Subject: [Patches] [ python-Patches-483085 ] Include windows default temp dir Message-ID: Patches item #483085, was opened at 2001-11-18 07:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483085&group_id=5470 Category: Library (Lib) Group: None Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Emile van Sebille (evansebille) >Assigned to: Nobody/Anonymous (nobody) Summary: Include windows default temp dir Initial Comment: Include os.getenv('TEMP') in attempdirs so that temp files by default are created per the environment setting. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-04 15:14 Message: Logged In: YES user_id=31435 The patch is rejected since the functionality is already implemented. ---------------------------------------------------------------------- Comment By: Emile van Sebille (evansebille) Date: 2001-12-04 14:31 Message: Logged In: YES user_id=41612 Tim, I see that now. At the time, I thought it was my change that put it in there, but I also changed the envars at the same time and missed that it would have done it anyway. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-04 13:27 Message: Logged In: YES user_id=31435 Emile, I don't understand what the patch accomplishes for you. gettempdir() already contains these lines later: """ . for envname in 'TMPDIR', 'TEMP', 'TMP': . if os.environ.has_key(envname): . attempdirs.insert(0, os.environ[envname]) """ so if you have a TEMP envar set on Windows, its value should already be getting prepended to attemdirs (and it does, on my Win2K box -- doesn't it work on your box?). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 09:45 Message: Logged In: YES user_id=6380 Tim, does this look reasonable to you? It does to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483085&group_id=5470 From noreply@sourceforge.net Wed Dec 5 01:22:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 17:22:34 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) Assigned to: Nobody/Anonymous (nobody) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From news-fr@maniacosex.com Wed Dec 5 01:53:48 2001 From: news-fr@maniacosex.com (news-fr@maniacosex.com) Date: Wed, 05 Dec 2001 02:53:48 +0100 Subject: [Patches] ••••[MANIACOSEX.COM]•••• Ajoutez vos sites et galeries ! Message-ID: <20011205015928.9F1CF36159@mail2.fr.clara.net> Bonjour, Ce message s'adresse a tous les webmasters X. Vous pouvez dès a présent inscrire votre site, vos galeries photos et vidéos sur notre annuaire International du Sex MANIACOSEX.COM Version française : http://www.fr.maniacosex.com/html/sommaire.cfm English version : http://www.uk.maniacosex.com/html/sommaire.cfm Versión española : http://www.sp.maniacosex.com/html/sommaire.cfm Deutsche Version : http://www.de.maniacosex.com/html/sommaire.cfm Rejoignez l'un des futurs plus grands portails du Sex et systèmes TGP du WEB. Notre site fera grimper, grimper, grimper votre audience... A très bientôt. Si vous ne souhaitez plus recevoir nos messages Cliquez ici pour vous désabonner : http://www.fr.maniacosex.com/html/mailing.cfm?email=patches@python.org&state=remove From noreply@sourceforge.net Wed Dec 5 04:48:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 20:48:32 -0800 Subject: [Patches] [ python-Patches-486079 ] poplib contains unuseable code Message-ID: Patches item #486079, was opened at 2001-11-27 09:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 Category: None >Group: Python 2.3 Status: Open >Resolution: Later Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: poplib contains unuseable code Initial Comment: poplib contains a number of debugging statements, quite useful for debugging, which are turned on via the set_debuglevel function. However, all of the debug statements have been commented out, making it impossible to debug properly. Included is a patch which uncomments the commented code, but does *not* change default behavior. However, if someone issues the set_debuglevel(int N) function, then debugging works, just like the documentation and logic says it should. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:10 Message: Logged In: YES user_id=31435 Recategorized this as a patch. Note that it won't be considered for 2.2 (too late). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 From noreply@sourceforge.net Wed Dec 5 05:09:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 21:09:50 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 7 Submitted By: Hye-Shik Chang (perky) Assigned to: Jeremy Hylton (jhylton) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2001-12-04 21:09 Message: Logged In: YES user_id=55188 Oops! sorry. It was a mistake. changed to corrected patch. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-03 20:14 Message: Logged In: YES user_id=55188 On the ENOTCONN error: the error will be raised only if 'sock' was bound outside. (even if self.accepting get set) but using out-bound socket is unavoidable for some server models. and I and some co-workers are using it. How about this way instead of previous patch? if not self.accepting: self.addr = sock.getpeername() On passing maps: some part of asyncore supports using own socket map. (__init__, add_channel, del_channel), but when __init__ registers socket into map which passed by argument, asyncore can't del_channel from own map and it will raises KeyError because asyncore.socket_map doesn't have such fileno. And, current version of asynchat doesn't support to use another maps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:03 Message: Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Wed Dec 5 05:27:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 21:27:06 -0800 Subject: [Patches] [ python-Patches-474307 ] Fix send() to send all data Message-ID: Patches item #474307, was opened at 2001-10-23 18:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474307&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix send() to send all data Initial Comment: This patch attempts to fix the problem that *occasionally*, *rarely*, only on *some* operating systems, the send() call doesn't send all bytes but returns a short count. While this is totally OK according to the spec, it's so rare that most code (including almost all of the standard library) assumes that send() sends all bytes and doesn't bother to check the return value. Such code can occasionally misbehave, e.g. on FreeBSD which apparently returns "short counts" more frequently than other platforms. This has been reported before, e.g. SF bug #211710. The fix adds a loop to the send() and sendto() calls that repeats the call until all bytes are sent or an error is encountered. However, the code doesn't loop if the socket is in "non-blocking" mode, as set by the setblocking() method. It also doesn't loop if an explicit 'flags' argument is passed, except if flags is -1. Remaining problems: - If the blocking mode of the socket is set through other means than the setblocking() method (e.g. through a setsockopt() call, or an fcntl() or ioctl() call on the fileno(), or if fromfd() is passed a non-blocking socket), the blocking flag may be wrong. There doesn't seem to be a portable way to get the blocking flag, and I don't want to get it before each send() call. The caller should aways use setblocking() to change the blocking flag. - What should be returned if some bytes are written, and then an error is returned by the next send() call? I raise an exception in that case. - This may cause blocking in a carefully constructed application that uses blocking sockets but always calls select() to check that a socket is writable before calling send(). Such an application (maybe asyncore does this?) can be fixed by passing an explicit flags argument of zero to send(). For all these reasons, it's a tough call to decide to apply this, and I am submitting this patch for review. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:27 Message: Logged In: YES user_id=3066 Documentation updated with sendall() and additional information on send() in Doc/lib/libsocket.tex revision 1.58. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-25 20:25 Message: Logged In: YES user_id=6380 I've checked in sendall(). I'm handing this over to Fred for documentation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-25 06:07 Message: Logged In: YES user_id=6380 Here's a patch that implements sendall(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-25 06:06 Message: Logged In: YES user_id=6380 Here's a patch that implements sendall(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-25 05:50 Message: Logged In: YES user_id=6380 That's a possibility. I'd prefer a sendall() method in that case. I'm not sure I have the time for that; can you give it a crack? It would be much simpler than my patch. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-24 23:23 Message: Logged In: YES user_id=29957 How about, as a position in between, a new flag to send() to say 'send all of it'. That way, we can choose what semantics it should have. This simplifies the process of patching the std library for 2.2. Hm. socket.send() should probably be documented more clearly that it doesn't necessarily send all bytes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-24 12:10 Message: Logged In: YES user_id=6380 We discussed this at a PythonLabs meeting and rejected it, because it's impossible to really do the right thing at this level. Instead, we're going to have to fix all calls to send that don't check the return value. - Having the wrong value for the 'blocking' bit is not safe, and there's no portable way to get the blocking bit. - There's no good answer to the question of what to do when the looping call encounters an error after some bytes were written successfully. On the one hand we want to report the error, on the other hand we want to report how many bytes were written. Making this part of the exception state is too messy. - There's much more documentation for socket programming in C than in Python, and it's a real advantage to be able to do a 1-1 translation between C examples to Python examples. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474307&group_id=5470 From noreply@sourceforge.net Wed Dec 5 05:31:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 21:31:47 -0800 Subject: [Patches] [ python-Patches-487738 ] weaklist Message-ID: Patches item #487738, was opened at 2001-11-30 17:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 Category: Library (Lib) >Group: Python 2.3 >Status: Pending >Resolution: Later Priority: 7 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:31 Message: Logged In: YES user_id=3066 Needs motivation. Without an need for the data structure, this will be rejected. Lowering priority and marking this for consideration for Python 2.3; it's too late to add this for Python 2.2. Set to "pending" while awaiting an explanation of the motivation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 17:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 From noreply@sourceforge.net Wed Dec 5 05:33:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 21:33:50 -0800 Subject: [Patches] [ python-Patches-487739 ] test_weaklist Message-ID: Patches item #487739, was opened at 2001-11-30 17:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487739&group_id=5470 Category: Library (Lib) >Group: Python 2.3 >Status: Pending >Resolution: Later >Priority: 4 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: test_weaklist Initial Comment: Test case for weaklist. Look previous patch: weaklist ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:33 Message: Logged In: YES user_id=3066 Matched status changes for the feature patch. In the future, please add tests for a patch as a second attachment to the patch report. (Yeah, I know SF doesn't make it an obvious feature until after the report has been submitted -- I can't fix that.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487739&group_id=5470 From noreply@sourceforge.net Wed Dec 5 05:35:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 21:35:50 -0800 Subject: [Patches] [ python-Patches-487738 ] weaklist Message-ID: Patches item #487738, was opened at 2001-11-30 17:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Open Resolution: Later >Priority: 4 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:35 Message: Logged In: YES user_id=3066 Oops, I meant to adjust the priority on this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:31 Message: Logged In: YES user_id=3066 Needs motivation. Without an need for the data structure, this will be rejected. Lowering priority and marking this for consideration for Python 2.3; it's too late to add this for Python 2.2. Set to "pending" while awaiting an explanation of the motivation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 17:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 From noreply@sourceforge.net Wed Dec 5 05:36:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 21:36:19 -0800 Subject: [Patches] [ python-Patches-487738 ] weaklist Message-ID: Patches item #487738, was opened at 2001-11-30 17:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Pending Resolution: Later Priority: 4 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:35 Message: Logged In: YES user_id=3066 Oops, I meant to adjust the priority on this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:31 Message: Logged In: YES user_id=3066 Needs motivation. Without an need for the data structure, this will be rejected. Lowering priority and marking this for consideration for Python 2.3; it's too late to add this for Python 2.2. Set to "pending" while awaiting an explanation of the motivation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 17:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 From noreply@sourceforge.net Wed Dec 5 06:57:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 22:57:54 -0800 Subject: [Patches] [ python-Patches-481060 ] dylib & ncurses patches for Mac OS X for Python 2.1.2 Message-ID: Patches item #481060, was opened at 2001-11-12 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Anthony Baxter (anthonybaxter) Summary: dylib & ncurses patches for Mac OS X for Python 2.1.2 Initial Comment: The following existing 2.2 CVS patches need to be picked up by Python 2.1.2 for Mac OS X v. 10.1: Support for dylib - allow zlib included in OS to be used rather than have to compile and install in / usr/local: /cvsroot/python/python/dist/src/Lib/distutils/ unixccompiler.py,v retrieving revision 1.35 retrieving revision 1.36 diff -c -r1.35 -r1.36 /cvsroot/python/python/dist/src/Lib/distutils/ ccompiler.py,v retrieving revision 1.39 retrieving revision 1.40 diff -c -r1.39 -r1.40 Prevent ncurses from building on OS X: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.52 retrieving revision 1.53 diff -c -r1.52 -r1.53 ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 22:57 Message: Logged In: YES user_id=29957 These have now been checked in on the branch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 05:00 Message: Logged In: YES user_id=45365 Anthony (you _are_ doing 2.1.2, or am I gravely mistaken? Assign back to me if I am:-), these patch suggestions look good to me. If you decide to apply them let me know when you've done so and I'll see whether I can build a 2.1.2 on OSX 10.1. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:54 Message: Logged In: YES user_id=45365 Dan, ignore that note about the missing patches. I thought there was one that didn't come from the repository, but on looking again I saw all of them come from the repository, so no need to upload something. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:46 Message: Logged In: YES user_id=45365 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 From noreply@sourceforge.net Wed Dec 5 06:58:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 22:58:57 -0800 Subject: [Patches] [ python-Patches-481060 ] dylib & ncurses patches for Mac OS X for Python 2.1.2 Message-ID: Patches item #481060, was opened at 2001-11-12 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) >Assigned to: Jack Jansen (jackjansen) Summary: dylib & ncurses patches for Mac OS X for Python 2.1.2 Initial Comment: The following existing 2.2 CVS patches need to be picked up by Python 2.1.2 for Mac OS X v. 10.1: Support for dylib - allow zlib included in OS to be used rather than have to compile and install in / usr/local: /cvsroot/python/python/dist/src/Lib/distutils/ unixccompiler.py,v retrieving revision 1.35 retrieving revision 1.36 diff -c -r1.35 -r1.36 /cvsroot/python/python/dist/src/Lib/distutils/ ccompiler.py,v retrieving revision 1.39 retrieving revision 1.40 diff -c -r1.39 -r1.40 Prevent ncurses from building on OS X: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.52 retrieving revision 1.53 diff -c -r1.52 -r1.53 ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 22:58 Message: Logged In: YES user_id=29957 Darn. clicked submit too fast. Assigning back to Jack for testing. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 22:57 Message: Logged In: YES user_id=29957 These have now been checked in on the branch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 05:00 Message: Logged In: YES user_id=45365 Anthony (you _are_ doing 2.1.2, or am I gravely mistaken? Assign back to me if I am:-), these patch suggestions look good to me. If you decide to apply them let me know when you've done so and I'll see whether I can build a 2.1.2 on OSX 10.1. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:54 Message: Logged In: YES user_id=45365 Dan, ignore that note about the missing patches. I thought there was one that didn't come from the repository, but on looking again I saw all of them come from the repository, so no need to upload something. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:46 Message: Logged In: YES user_id=45365 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 From noreply@sourceforge.net Wed Dec 5 07:01:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 23:01:14 -0800 Subject: [Patches] [ python-Patches-481080 ] Read Me file Patch for Python 2.1.2 Message-ID: Patches item #481080, was opened at 2001-11-12 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Anthony Baxter (anthonybaxter) Summary: Read Me file Patch for Python 2.1.2 Initial Comment: The following paragraph replaces the existing Mac OS X v10.1 paragraph. It assumes that patches 481060 and 481075 are taken. - Dan Mac OS X 10.1: Run configure with ./configure -- with-suffix=.x --with-dyld". This generates executable file: 'python.x' (it cannot be named 'python' on an HFS or HFS+ disk as the file name clashes with directory 'Python'). The makefile is set up to correctly handle two- level namespaces for Mac OS X v10.1 and 10.0.x systems. However, running the prebinding tool on Mac OS X 10.0.x again will cause the tool to break as it cannot handle two level namespaces. The default Mac OS X has a default stacksize of 512K which causes the regular expression tests (RE and SRE) to SEGV. To temporarily increase the stacksize, type 'limit stacksize 2M' in the terminal window before running 'make test'. The test_largefile test will work on HFS+ and UFS filesystem, providing you have enough space and time. After sudo 'make installation', do the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:01 Message: Logged In: YES user_id=29957 481060 is in, but not 481075 - I don't have access to Mac OS X for easy testing of this. Hm, or does cf.sf.net have OS X boxes? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 16:03 Message: Logged In: YES user_id=45365 This sounds pretty reasonable to me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-28 23:25 Message: Logged In: YES user_id=3066 Assigned to the Mac OS expert for evaluation and integration. Jack, note that this is for the release21-maint branch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 From noreply@sourceforge.net Wed Dec 5 13:30:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 05:30:30 -0800 Subject: [Patches] [ python-Patches-486079 ] poplib contains unuseable code Message-ID: Patches item #486079, was opened at 2001-11-27 09:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: poplib contains unuseable code Initial Comment: poplib contains a number of debugging statements, quite useful for debugging, which are turned on via the set_debuglevel function. However, all of the debug statements have been commented out, making it impossible to debug properly. Included is a patch which uncomments the commented code, but does *not* change default behavior. However, if someone issues the set_debuglevel(int N) function, then debugging works, just like the documentation and logic says it should. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-05 05:30 Message: Logged In: YES user_id=6380 Are we sure this isn't a bugfix? OTOH, the patch file got lost. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:10 Message: Logged In: YES user_id=31435 Recategorized this as a patch. Note that it won't be considered for 2.2 (too late). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 From noreply@sourceforge.net Wed Dec 5 14:38:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 06:38:22 -0800 Subject: [Patches] [ python-Patches-489388 ] configure.in patch for OSX Message-ID: Patches item #489388, was opened at 2001-12-05 06:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489388&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: configure.in patch for OSX Initial Comment: Anthony, this patch is a sort-of backport of checkins 1.255 (make Python build on OSX 10.1) and 1.281 (reverse order of test for old OSX and new OSX releases). With this patch Python builds on 10.1 and 10.1.1, and I have pretty good confidence it will also build on 10.0. On 10.1.1 you will get an error because it tries to build curses, this will be fixed on the main branch shortly and I'll flag the patch (to setup.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489388&group_id=5470 From noreply@sourceforge.net Wed Dec 5 14:44:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 06:44:31 -0800 Subject: [Patches] [ python-Patches-481075 ] Makefile patches for Mac OS X for Python 2.1.2... Message-ID: Patches item #481075, was opened at 2001-11-12 14:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481075&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) >Assigned to: Jack Jansen (jackjansen) Summary: Makefile patches for Mac OS X for Python 2.1.2... Initial Comment: I'm not a config god, so I'll leave it to someone else to figure out how configuration needs to be changed to incorporate the following changes for Mac OS X 10.1: 1) Assume: ./configure --with-dyld --with-suffix=.x 2) handle BSD header problems by changing Makefile lines OPT= -g -O3 -Wall -Wstrict-prototypes to OPT= -g -O3 -Wall -Wstrict-prototypes -no- cpp-precomp 3) handle two level name spaces for 10.x and 10.0.x - and use bundle loader option vs flat name spaces. LDSHARED= $(CC) $(LDFLAGS) -bundle - undefined suppress BLDSHARED= $(CC) $(LDFLAGS) -bundle - undefined suppress to LDSHARED= $(CC) $(LDFLAGS) -bundle - undefined error -bundle_loader ./python.x BLDSHARED= $(CC) $(LDFLAGS) -bundle - undefined error -bundle_loader ./python.x NOTE: the '.x' in python.x is the suffix entered in the configure command. Also, I've been told the bundle_loader is only used to resolve undefined symbols and there is no likage between the resulting binary and the bundle_loader. Hence, we can rename python.x to python after installation. with the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 06:44 Message: Logged In: YES user_id=45365 Purely by accident I came across this patch. I've usurped it. (Dan: assigning a patch to no-one is a pretty sure way of making it go unnoticed, better assign it to a random person, who'll quickly pass it on to someone else:-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481075&group_id=5470 From noreply@sourceforge.net Wed Dec 5 14:47:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 06:47:43 -0800 Subject: [Patches] [ python-Patches-481080 ] Read Me file Patch for Python 2.1.2 Message-ID: Patches item #481080, was opened at 2001-11-12 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Anthony Baxter (anthonybaxter) Summary: Read Me file Patch for Python 2.1.2 Initial Comment: The following paragraph replaces the existing Mac OS X v10.1 paragraph. It assumes that patches 481060 and 481075 are taken. - Dan Mac OS X 10.1: Run configure with ./configure -- with-suffix=.x --with-dyld". This generates executable file: 'python.x' (it cannot be named 'python' on an HFS or HFS+ disk as the file name clashes with directory 'Python'). The makefile is set up to correctly handle two- level namespaces for Mac OS X v10.1 and 10.0.x systems. However, running the prebinding tool on Mac OS X 10.0.x again will cause the tool to break as it cannot handle two level namespaces. The default Mac OS X has a default stacksize of 512K which causes the regular expression tests (RE and SRE) to SEGV. To temporarily increase the stacksize, type 'limit stacksize 2M' in the terminal window before running 'make test'. The test_largefile test will work on HFS+ and UFS filesystem, providing you have enough space and time. After sudo 'make installation', do the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 06:47 Message: Logged In: YES user_id=45365 Let 481075 rest for now, I need to do this for the trunk too. I'll flag the checkin message. If you apply my new 489388 then everything should be fine for 2.1.2 for OSX. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:01 Message: Logged In: YES user_id=29957 481060 is in, but not 481075 - I don't have access to Mac OS X for easy testing of this. Hm, or does cf.sf.net have OS X boxes? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 16:03 Message: Logged In: YES user_id=45365 This sounds pretty reasonable to me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-28 23:25 Message: Logged In: YES user_id=3066 Assigned to the Mac OS expert for evaluation and integration. Jack, note that this is for the release21-maint branch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 From noreply@sourceforge.net Wed Dec 5 15:13:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 07:13:24 -0800 Subject: [Patches] [ python-Patches-486079 ] poplib contains unuseable code Message-ID: Patches item #486079, was opened at 2001-11-27 09:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: poplib contains unuseable code Initial Comment: poplib contains a number of debugging statements, quite useful for debugging, which are turned on via the set_debuglevel function. However, all of the debug statements have been commented out, making it impossible to debug properly. Included is a patch which uncomments the commented code, but does *not* change default behavior. However, if someone issues the set_debuglevel(int N) function, then debugging works, just like the documentation and logic says it should. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:13 Message: Logged In: YES user_id=3066 Creating an equivalent patch based on the report is trivial, but set_debuglevel() does not appear to be documented, so I'm not sure it should go in for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-05 05:30 Message: Logged In: YES user_id=6380 Are we sure this isn't a bugfix? OTOH, the patch file got lost. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:10 Message: Logged In: YES user_id=31435 Recategorized this as a patch. Note that it won't be considered for 2.2 (too late). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 From noreply@sourceforge.net Wed Dec 5 15:50:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 07:50:59 -0800 Subject: [Patches] [ python-Patches-486079 ] poplib contains unuseable code Message-ID: Patches item #486079, was opened at 2001-11-27 09:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: poplib contains unuseable code Initial Comment: poplib contains a number of debugging statements, quite useful for debugging, which are turned on via the set_debuglevel function. However, all of the debug statements have been commented out, making it impossible to debug properly. Included is a patch which uncomments the commented code, but does *not* change default behavior. However, if someone issues the set_debuglevel(int N) function, then debugging works, just like the documentation and logic says it should. ---------------------------------------------------------------------- >Comment By: Jon Nelson (jnelson) Date: 2001-12-05 07:50 Message: Logged In: YES user_id=8446 A quick scan of ftplib, imaplib, httplib, smtplib, and nntplib all show (in the Python 2.1.1 docs *and* Python 2.2b1 library source) the use of set_debuglevel. imaplib does have a similar mechanism, but it is 'debug' instead of 'set_debuglevel' wherein debug is a class variable and set_debuglevel is a class method. poplib is the only protocol library (except gopherlib) that does not document or use set_debuglevel, although the code is in the library -- its just commented out. Is it worth my time trying to get set_debuglevel into imaplib for consistency? Thanks for your time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:13 Message: Logged In: YES user_id=3066 Creating an equivalent patch based on the report is trivial, but set_debuglevel() does not appear to be documented, so I'm not sure it should go in for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-05 05:30 Message: Logged In: YES user_id=6380 Are we sure this isn't a bugfix? OTOH, the patch file got lost. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:10 Message: Logged In: YES user_id=31435 Recategorized this as a patch. Note that it won't be considered for 2.2 (too late). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 From noreply@sourceforge.net Wed Dec 5 16:03:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 08:03:08 -0800 Subject: [Patches] [ python-Patches-486079 ] poplib contains unuseable code Message-ID: Patches item #486079, was opened at 2001-11-27 09:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: poplib contains unuseable code Initial Comment: poplib contains a number of debugging statements, quite useful for debugging, which are turned on via the set_debuglevel function. However, all of the debug statements have been commented out, making it impossible to debug properly. Included is a patch which uncomments the commented code, but does *not* change default behavior. However, if someone issues the set_debuglevel(int N) function, then debugging works, just like the documentation and logic says it should. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 08:03 Message: Logged In: YES user_id=3066 So this can reasonably be described as a consistency bug -- the protocol API is not implemented consistently. ;-) I would not object to this on that basis; set_debuglevel() would have to be documented as well (I can take care of that). ---------------------------------------------------------------------- Comment By: Jon Nelson (jnelson) Date: 2001-12-05 07:50 Message: Logged In: YES user_id=8446 A quick scan of ftplib, imaplib, httplib, smtplib, and nntplib all show (in the Python 2.1.1 docs *and* Python 2.2b1 library source) the use of set_debuglevel. imaplib does have a similar mechanism, but it is 'debug' instead of 'set_debuglevel' wherein debug is a class variable and set_debuglevel is a class method. poplib is the only protocol library (except gopherlib) that does not document or use set_debuglevel, although the code is in the library -- its just commented out. Is it worth my time trying to get set_debuglevel into imaplib for consistency? Thanks for your time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:13 Message: Logged In: YES user_id=3066 Creating an equivalent patch based on the report is trivial, but set_debuglevel() does not appear to be documented, so I'm not sure it should go in for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-05 05:30 Message: Logged In: YES user_id=6380 Are we sure this isn't a bugfix? OTOH, the patch file got lost. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:10 Message: Logged In: YES user_id=31435 Recategorized this as a patch. Note that it won't be considered for 2.2 (too late). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 From noreply@sourceforge.net Wed Dec 5 22:38:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 14:38:08 -0800 Subject: [Patches] [ python-Patches-486079 ] poplib contains unuseable code Message-ID: Patches item #486079, was opened at 2001-11-27 09:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 Category: None >Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: poplib contains unuseable code Initial Comment: poplib contains a number of debugging statements, quite useful for debugging, which are turned on via the set_debuglevel function. However, all of the debug statements have been commented out, making it impossible to debug properly. Included is a patch which uncomments the commented code, but does *not* change default behavior. However, if someone issues the set_debuglevel(int N) function, then debugging works, just like the documentation and logic says it should. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 14:38 Message: Logged In: YES user_id=3066 Uncommented the conditional debugging prints in Lib/poplib.py revision 1.19; added documentation for set_debuglevel() in Doc/lib/libpoplib.tex revision 1.14. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 08:03 Message: Logged In: YES user_id=3066 So this can reasonably be described as a consistency bug -- the protocol API is not implemented consistently. ;-) I would not object to this on that basis; set_debuglevel() would have to be documented as well (I can take care of that). ---------------------------------------------------------------------- Comment By: Jon Nelson (jnelson) Date: 2001-12-05 07:50 Message: Logged In: YES user_id=8446 A quick scan of ftplib, imaplib, httplib, smtplib, and nntplib all show (in the Python 2.1.1 docs *and* Python 2.2b1 library source) the use of set_debuglevel. imaplib does have a similar mechanism, but it is 'debug' instead of 'set_debuglevel' wherein debug is a class variable and set_debuglevel is a class method. poplib is the only protocol library (except gopherlib) that does not document or use set_debuglevel, although the code is in the library -- its just commented out. Is it worth my time trying to get set_debuglevel into imaplib for consistency? Thanks for your time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:13 Message: Logged In: YES user_id=3066 Creating an equivalent patch based on the report is trivial, but set_debuglevel() does not appear to be documented, so I'm not sure it should go in for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-05 05:30 Message: Logged In: YES user_id=6380 Are we sure this isn't a bugfix? OTOH, the patch file got lost. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:10 Message: Logged In: YES user_id=31435 Recategorized this as a patch. Note that it won't be considered for 2.2 (too late). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 From noreply@sourceforge.net Thu Dec 6 03:11:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 19:11:33 -0800 Subject: [Patches] [ python-Patches-489680 ] h2py uses nonexistent method Message-ID: Patches item #489680, was opened at 2001-12-05 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489680&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: h2py uses nonexistent method Initial Comment: The h2py script, used in installation under Cygwin, uses a nonexistent method of strings, "splitfields". It should be "split". Patch follows ------------- --- h2py.old.py Thu Dec 06 03:10:48 2001 +++ h2py.py Thu Dec 06 03:11:00 2001 @@ -42,14 +42,14 @@ importable = {} try: - searchdirs=os.environ['include'].splitfields(';') + searchdirs=os.environ['include'].split(';') except KeyError: try: - searchdirs=os.environ['INCLUDE'].splitfields (';') + searchdirs=os.environ['INCLUDE'].split(';') except KeyError: try: if sys.platform.find("beos") == 0: - searchdirs=os.environ ['BEINCLUDES'].splitfields(';') + searchdirs=os.environ ['BEINCLUDES'].split(';') else: raise KeyError except KeyError: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489680&group_id=5470 From noreply@sourceforge.net Thu Dec 6 03:30:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 19:30:19 -0800 Subject: [Patches] [ python-Patches-489680 ] h2py uses nonexistent method Message-ID: Patches item #489680, was opened at 2001-12-05 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489680&group_id=5470 >Category: Demos and tools Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Guido van Rossum (gvanrossum) Summary: h2py uses nonexistent method Initial Comment: The h2py script, used in installation under Cygwin, uses a nonexistent method of strings, "splitfields". It should be "split". Patch follows ------------- --- h2py.old.py Thu Dec 06 03:10:48 2001 +++ h2py.py Thu Dec 06 03:11:00 2001 @@ -42,14 +42,14 @@ importable = {} try: - searchdirs=os.environ['include'].splitfields(';') + searchdirs=os.environ['include'].split(';') except KeyError: try: - searchdirs=os.environ['INCLUDE'].splitfields (';') + searchdirs=os.environ['INCLUDE'].split(';') except KeyError: try: if sys.platform.find("beos") == 0: - searchdirs=os.environ ['BEINCLUDES'].splitfields(';') + searchdirs=os.environ ['BEINCLUDES'].split(';') else: raise KeyError except KeyError: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-05 19:30 Message: Logged In: YES user_id=6380 Thanks! Applied in CVS (h2py.py rev. 1.15). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489680&group_id=5470 From noreply@sourceforge.net Thu Dec 6 07:57:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 23:57:26 -0800 Subject: [Patches] [ python-Patches-489388 ] configure.in patch for OSX Message-ID: Patches item #489388, was opened at 2001-12-05 06:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489388&group_id=5470 Category: Build >Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: configure.in patch for OSX Initial Comment: Anthony, this patch is a sort-of backport of checkins 1.255 (make Python build on OSX 10.1) and 1.281 (reverse order of test for old OSX and new OSX releases). With this patch Python builds on 10.1 and 10.1.1, and I have pretty good confidence it will also build on 10.0. On 10.1.1 you will get an error because it tries to build curses, this will be fixed on the main branch shortly and I'll flag the patch (to setup.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489388&group_id=5470 From noreply@sourceforge.net Thu Dec 6 07:57:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 23:57:44 -0800 Subject: [Patches] [ python-Patches-481080 ] Read Me file Patch for Python 2.1.2 Message-ID: Patches item #481080, was opened at 2001-11-12 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 Category: Documentation >Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Anthony Baxter (anthonybaxter) Summary: Read Me file Patch for Python 2.1.2 Initial Comment: The following paragraph replaces the existing Mac OS X v10.1 paragraph. It assumes that patches 481060 and 481075 are taken. - Dan Mac OS X 10.1: Run configure with ./configure -- with-suffix=.x --with-dyld". This generates executable file: 'python.x' (it cannot be named 'python' on an HFS or HFS+ disk as the file name clashes with directory 'Python'). The makefile is set up to correctly handle two- level namespaces for Mac OS X v10.1 and 10.0.x systems. However, running the prebinding tool on Mac OS X 10.0.x again will cause the tool to break as it cannot handle two level namespaces. The default Mac OS X has a default stacksize of 512K which causes the regular expression tests (RE and SRE) to SEGV. To temporarily increase the stacksize, type 'limit stacksize 2M' in the terminal window before running 'make test'. The test_largefile test will work on HFS+ and UFS filesystem, providing you have enough space and time. After sudo 'make installation', do the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 06:47 Message: Logged In: YES user_id=45365 Let 481075 rest for now, I need to do this for the trunk too. I'll flag the checkin message. If you apply my new 489388 then everything should be fine for 2.1.2 for OSX. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:01 Message: Logged In: YES user_id=29957 481060 is in, but not 481075 - I don't have access to Mac OS X for easy testing of this. Hm, or does cf.sf.net have OS X boxes? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 16:03 Message: Logged In: YES user_id=45365 This sounds pretty reasonable to me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-28 23:25 Message: Logged In: YES user_id=3066 Assigned to the Mac OS expert for evaluation and integration. Jack, note that this is for the release21-maint branch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 From noreply@sourceforge.net Thu Dec 6 12:04:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 04:04:26 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) Assigned to: Nobody/Anonymous (nobody) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:01:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:01:16 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) Assigned to: Nobody/Anonymous (nobody) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:01 Message: Logged In: YES user_id=6380 I see no problem with the patch. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:36:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:36:11 -0800 Subject: [Patches] [ python-Patches-489066 ] Include RLIM_INFINITY constant Message-ID: Patches item #489066, was opened at 2001-12-04 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489066&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) >Assigned to: Jeremy Hylton (jhylton) Summary: Include RLIM_INFINITY constant Initial Comment: The following is a patch to the resource module to include the RLIM_INFINITY constant. It should handle platforms where RLIM_INFINITY is not a LONG_LONG, but I have no means to test that. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489066&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:50:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:50:16 -0800 Subject: [Patches] [ python-Patches-473512 ] getopt with GNU style scanning Message-ID: Patches item #473512, was opened at 2001-10-21 14:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473512&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: Postponed Priority: 5 Submitted By: Peter Åstrand (astrand) Assigned to: Nobody/Anonymous (nobody) Summary: getopt with GNU style scanning Initial Comment: Implements GNU style scanning mode. The traditional mode is used if the option string begins with + or if the environment variable POSIXLY_CORRECT is set, just like GNU getopt. Patch includes updated documentation and test. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 06:50 Message: Logged In: YES user_id=3066 The documentation needs to clearly describe the differences between GNU-style scanning and what's done in getopt.getopt() -- it seems to assume the reader knows the differences. The implementation of gnu_getopt() also assumes that args will be non-empty. If the caller wants only long options and passes '' as args, IndexError will be raised. Check for a leading '+' with args.startswith('+') to be safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 02:10 Message: Logged In: YES user_id=21627 The patch looks good to me. Since it introduces a new feature, it will be postponed after 2.2 (negotiate with the 2.2 release manager if you want to see it included). Notice that it doesn't offer all features of GNU getopt. It doesn't support the getopt_long_only mechanism (where all options are long, even if they have a single - only). Further, it doesn't allow the caller to specify ordering, and it doesn't support the RETURN_IN_ORDER option (which would be difficult to support with the current calling convention, though). I'm not asking that these problems are somehow resolved; they are meant as proposals for improvements only. ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2001-11-11 08:09 Message: Logged In: YES user_id=344921 The new patch uses a new function, gnu_getopt, instead of changing the default behaviour. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-21 17:37 Message: Logged In: YES user_id=6380 Rejected in this form. We can't suddenly change the default behavior. If you want a way to support GNU style options (which I personally hate, but which I would accept as an option), try adding a different function (e.g. gnu_getopt(...)) or add a flag argument (e.g. getopt(..., gnu=1)). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473512&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:52:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:52:23 -0800 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: Closed >Resolution: Invalid 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. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 06:52 Message: Logged In: YES user_id=3066 Closing due to lack of response to Martin's plea for a patch -- appearantly the submitter did not supply an email address. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-19 10:53 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453204&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:57:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:57:04 -0800 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: Library (Lib) >Group: Python 2.3 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 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 06:57 Message: Logged In: YES user_id=3066 Another possible alternate home for this would be the Python Snippet repository on SourceForge: http://sourceforge.net/snippet/browse.php?by=lang&lang=6 I'm not suggesting that this doesn't belong in the standard library, however. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-19 10:46 Message: Logged In: YES user_id=21627 Nice patch. If you want to see this included, you should complete it: Decide on location of the function, provide documentation and test cases. As the location, it may be that the calendar module could provide a home, but you may ask in the newsgroup. If you merely wanted to publish this code snippet, I suggest that you find a better home than the Python patch database, e.g. the Cookbook: http://aspn.activestate.com/ASPN/Cookbook/Python There are a number of other places that collect Python snippets; this is just one option. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452232&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:12:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:12:08 -0800 Subject: [Patches] [ python-Patches-479898 ] Multibyte string on string::string_print Message-ID: Patches item #479898, was opened at 2001-11-08 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Multibyte string on string::string_print Initial Comment: Many multibyte language users are difficult to see native characters on list or dictionary and etc. This patch allows printing multibyte on UNIX98- compatible machines; mbtowc() is ISO/IEC 9899:1990 standard C-API function. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=21627 You are right, the code should use iswprint instead. The point is that multiple subsequent bytes can make up a single printable character. Not every character above 127 is necessarily printable (e.g. in Latin-1, only characters above 160 are printable). Likewise, a single byte may not be printable, but a combination will print fine. So this code is supposed to catch only those cases where printing will actually work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:08 Message: Logged In: YES user_id=6380 I don't understand the point of using mbtowc() here. The code extracts a wide character, but then it uses isprint() on it, and as far as I know, isprint() is not defined on wide characters, only on 'unsigned char' (and on -1). Isn't what the author wants simply to is isprint(c) instead of (c < ' ' || c >= 0x7f)??? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 13:21 Message: Logged In: YES user_id=21627 Even though I think this patch is correct in principle, I see a few problems with it: 1. Since it doesn't fix a bug, it probably cannot go into 2.2. 2. There is no autoconf test for mbtowc. You should test this in configure, and then conditionalize your code on HAVE_MBTOWC. 3. There is too much code duplication. Try to find a solution which special-cases the escape codes (\something) only once. For example, you may implement a trivial mbtowc redefinition if mbtowc is not available, and then use mbtowc always. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:25:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:25:10 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:25 Message: Logged In: YES user_id=3066 Are there any objections to my checking this in for Python 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:01 Message: Logged In: YES user_id=6380 I see no problem with the patch. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:26:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:26:55 -0800 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: Python 2.3 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. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-19 10:55 Message: Logged In: YES user_id=21627 Adding this feature sounds like a good thing. A shallow review of the patch reveals two major problems with it, though: no patches to the documentation, no patches to test_getopt. Would you consider providing these missing pieces? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454790&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:37:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:37:06 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:37 Message: Logged In: YES user_id=6380 Since it's Windows specific, can you test it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:25 Message: Logged In: YES user_id=3066 Are there any objections to my checking this in for Python 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:01 Message: Logged In: YES user_id=6380 I see no problem with the patch. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:57:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:57:51 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) >Assigned to: Tim Peters (tim_one) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:57 Message: Logged In: YES user_id=3066 Hmmm... it would take some time to get a Windows build environment up on this machine. I'll assign this to Tim; hopefully someone can contribute a test case for this so there will be some chance he'll get to this for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:37 Message: Logged In: YES user_id=6380 Since it's Windows specific, can you test it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:25 Message: Logged In: YES user_id=3066 Are there any objections to my checking this in for Python 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:01 Message: Logged In: YES user_id=6380 I see no problem with the patch. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:36:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:36:27 -0800 Subject: [Patches] [ python-Patches-489989 ] linuxaudiodev.c - fix initialization Message-ID: Patches item #489989, was opened at 2001-12-06 12:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489989&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Charles G Waldman (cgw) Assigned to: Nobody/Anonymous (nobody) Summary: linuxaudiodev.c - fix initialization Initial Comment: The OSS Programmer's Reference (www.4front-tech.com) states: *Setting Sampling Parameters There are three parameters which affect the sound quality (and therefore memory and bandwidth requirements) of sampled audio data. These are: ** sample format (sometimes called number of bits) ** number of channels (mono or stereo), and ** sampling rate (speed) NOTE: It is important to always set these parameters in the above order. Setting sampling rate before the number of channels doesn't work with all devices. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489989&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:55:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:55:24 -0800 Subject: [Patches] [ python-Patches-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Patches item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) >Assigned to: Thomas Heller (theller) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 12:55 Message: Logged In: YES user_id=11375 Reassigning to Thomas Heller; I know nothing about bdist_wininst. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:30:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:30:31 -0800 Subject: [Patches] [ python-Patches-475009 ] build_scripts.post_interp is None Message-ID: Patches item #475009, was opened at 2001-10-25 12:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=475009&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: A.M. Kuchling (akuchling) Summary: build_scripts.post_interp is None Initial Comment: in the first line regex, we assign group(1) to post_interp, which is None. So you get #!/usr/bin/pythonX.YNone as output, which is wrong. Heres da patch: --- build_scripts.py.orig Thu Oct 25 21:03:27 2001 +++ build_scripts.py Thu Oct 25 21:03:41 2001 @@ -80,7 +80,7 @@ match = first_line_re.match(first_line) if match: adjust = 1 - post_interp = match.group(1) + post_interp = match.group(1) or "" if adjust: self.announce("copying and adjusting %s -> %s" % ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 13:30 Message: Logged In: YES user_id=11375 calvin is correct; the bug is really that first_line_re can match when it shouldn't. Fixed in rev. 1.12 of build_scripts.py by adding $ to the end of first_line_re. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2001-10-25 12:28 Message: Logged In: YES user_id=9205 This occurs only with versioned interpreters,e.g. #!/usr/bin/python2 -O Proper fix is to adjust the first_line_re. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=475009&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:33:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:33:45 -0800 Subject: [Patches] [ python-Patches-420565 ] makes setup.py search sys.prefix Message-ID: Patches item #420565, was opened at 2001-05-01 14:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: makes setup.py search sys.prefix Initial Comment: It's useful to have setup.py search the lib and include directories in sys.prefix before it checks /usr/local. That way, if you are building Python into a custom location and want it to use the the libraries installed there rather than the system defaults, you can give the --prefix option to configure and setup.py will search that path first. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-01 08:19 Message: Logged In: NO I totally agree. I'm building for hard hat linux on a debian host, and the implicit search in /usr/lib is totally the wrong thing to do in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:34:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:34:20 -0800 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 and setup.py 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 Dec 6 21:34:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:34:02 -0800 Subject: [Patches] [ python-Patches-458898 ] --python-build for install Message-ID: Patches item #458898, was opened at 2001-09-05 13:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Nobody/Anonymous (nobody) Summary: --python-build for install Initial Comment: Sometimes, being able to install python tools without having python installed is desirable. When building an RPM package of python, for example, one may want to build/install IDLE as well, including it in a subpackage. Indeed, we're doing this with a couple of python tools here at Conectiva. Unfortunately, we have a egg-chicken problem when doing this. You need python installed in your system before you install tools. This limitation may be observed in the file Lib/distutils/sysconfig.py. It looks for Makefile in the final installation directory, for example. This patch adds a new option to dist-utils' install command: --python-build. When used, python will look for these files in the python build directory specified trough the option. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:35:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:35:07 -0800 Subject: [Patches] [ python-Patches-414775 ] Add --skip-build option to bdist command Message-ID: Patches item #414775, was opened at 2001-04-08 18:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414775&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kern (kern) >Assigned to: Nobody/Anonymous (nobody) Summary: Add --skip-build option to bdist command Initial Comment: Whenever one uses a non-default compiler to build an extension, the bdist command will try to rebuild the package with the default compiler and fail. The install command has a --skip-build option to manually skip the re-building part of the install. I adapted that code to add a similar --skip-build option to the bdist, bdist_dumb, and bdist_wininst commands. I'm not familiar enough with the bdist_rpm command's code to see where it would work in there. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-06 22:28 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=414775&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:35:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:35:13 -0800 Subject: [Patches] [ python-Patches-463656 ] setup.py, --with-includepath, and LD_LIB Message-ID: Patches item #463656, was opened at 2001-09-21 12:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) >Assigned to: Nobody/Anonymous (nobody) Summary: setup.py, --with-includepath, and LD_LIB Initial Comment: This patch improves the module detection capability in setup.py. The following improvements are implemented: - directories listed in LD_LIBRARY_PATH are also searched for shared libraries. - the --with-includepath option has been added to configure, to specify additional non-standard directories where the include files are to be searched for. The corresponding changes were added to setup.py (new function detect_include(), find_library_file() augmented, detect_tkinter() improved) I retroceeded manually the changes from configure into configure.in, but I did not run autoconf; you might want to double-check this. Sample aplication: ./configure --prefix=/something --with-includepath='/mgl/apps/include:/mgl/share/include' With this patch, I get Tkinter to build correctly without editing the Setup files, with non-standard tckl/tk 8.0 to 8.3 installations. where the only tcl.h file is in /mgl/share/include/tcl8.0 (therefore, tkinter is build with tcl8.0 on this configuration). FG ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-27 17:17 Message: Logged In: YES user_id=93657 I moved the functions find_library_file() and detect_include() to distutils.sysconfig(), so that they can be reused for configuring third party modules too (e.g.: PyOpenGL...). Let me know if you wish a patch for this. Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-26 15:56 Message: Logged In: YES user_id=93657 I'm replacing the patch with an improved version (against main line as of 09/26/01). New features: - configure is generated from configure.in, with autoconf - detect_tkinter also checks the version number inside the tcl.h and tk.h files (#define TCL_VERSION, #define TK_VERSION...). The 'tk_detect' improvement is in this same patch as the '--include-patch' feature; since the second one was written to get the first one working. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:35:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:35:35 -0800 Subject: [Patches] [ python-Patches-415226 ] new base class for binary packaging Message-ID: Patches item #415226, was opened at 2001-04-10 12:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Alexander (mwa) >Assigned to: Nobody/Anonymous (nobody) Summary: new base class for binary packaging Initial Comment: bdist_packager.py provides an abstract base class for bdist commands. It provides easy access to all the PEP 241 metadata fields, plus "revision" for the package revision and installation scripts for preinstall, postinstall preremove, and postremove. That covers the base characteristics of all the package managers that I'm familiar with. If anyone can think of any others, let me know, otherwise additional extensions would be implemented in the specific packager's commands. I would, however, discourage _requiring_ any additional fields. It would be nice if by simply supplying the PEP241 metadata under the [bdist_packager] section all subclassed packagers worked with no further effort. It also has rudimentary relocation support by including a --no-autorelocate option. The bdist_packager is also where I see creating seperate binary packages for sub-packages supported. My need for that is much less than my desire for it right now, so I didn't give it much thought as I wrote it. I'd be delighted to hear any comments and suggestions on how to approach sub-packaging, though. ---------------------------------------------------------------------- Comment By: Mark Alexander (mwa) Date: 2001-10-02 14:10 Message: Logged In: YES user_id=12810 Regarding script code: The preinstall, postinstall, etc. scripts are hooked into the package manager specific subclasses. It's the responsibility of the specific class to "do the right thing". For *NIX package managers, this is usually script code, although changing the help text to be more informative isn't a problem. More specifically, using python scripts under pkgtool and sdux would fail. Install scripts are not executed, they're sourced (in some wierd fashion I've yet to identify). Theoretically, using a shell script to find the python interpreter by querying the package manager and calling it with either -i or a runtime created script should work fine. This is intended as a class for instantiating new bdist commands with full support for pep 241. Current bdist commands do their own thing, and they do it very differently. I'd rather see this put in as a migration path than shut down bdist commands that function just fine on their own. Eventual adoption of a standard abstract base would mean that module authors could provide all metadata in a standard format, and distutils would be able to create binary packages for systems the author doesn't have access to. This works for Solaris pkgtool and HP-UX SDUX. All three patches can be included with ZERO side effects on any other aspect of Distutils. I'm really kind of curious why they're not integrated yet so other's can try them out. ---------------------------------------------------------------------- Comment By: david arnold (dja) Date: 2001-09-20 02:08 Message: Logged In: YES user_id=78574 i recently struck a case where i wanted the ability to run a post-install script on Windows (from a bdist_wininst-produced package). while i agree with what seems to be the basic intention of this patch, wouldn't it be more useful to have the various scripts run by the Python interpreter, rather than Bourne shell (which is extremely seldom available on Windows, MacOS, etc) ? i went looking for the source of the .exe file embedded in the wininst command, but couldn't find it. does anyone know where it lives? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-06 22:33 Message: Logged In: YES user_id=21627 Shouldn't the patch also modify the existing bdist commands to use this as a base class? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:35:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:35:59 -0800 Subject: [Patches] [ python-Patches-462754 ] no '_d' ending for mingw32 Message-ID: Patches item #462754, was opened at 2001-09-18 20:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) >Assigned to: Nobody/Anonymous (nobody) Summary: no '_d' ending for mingw32 Initial Comment: This patch prevents distutils from naming the extension modules _d.pyd when compiled with mingw32 on Windows in debug mode. Instead, the extension modules will get the normal name .pyd. Technically, the patch doesn't prevent the behaviour for mingw32, but only adds the _d for MS Visual C++ and Borland compilers (though I don't know about the Borland case). The reason for this? Adding "_d" doesn't make any sense for GNU compilers. I think it's just a MS Visual C++ madness. If you want to debug an extension module that was compiled with gcc, you have to use gdb anyway, because the debugging symbols of MSVC++ and gcc are incompatible. So you normally use a release Python version (from the python.org binary download) and compile your extensions with mingw32. To put it shortly: The current state is that you do a "setup.py build --compiler=mingw32 --debug" and then rename the extension modules, removing the _d. Then fire up gdb to debug your module. With this patch, the renaming isn't necessary anymore. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2001-09-28 14:28 Message: Logged In: YES user_id=163326 Yes. But mingw32 isn't emulating Unix under Windows (that would be Cygwin). It's just a version of gcc and friends that targets native win32. It links against msvcrt (not a Posix emulation library like Cygwin does). This is a bit hypothetical because I didn't yet hack the autoconf build process for native win32 with mingw32. Currently, you cannot build a complete Python with mingw32, but you *can* build extension modules against an existing Python (compiled with M$ VC++). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-28 13:43 Message: Logged In: YES user_id=31435 All else being equal, a system emulating Unix under Windows should strive to make life comfortable for Unix folks. The question is thus whether all else is in fact equal . ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2001-09-28 11:37 Message: Logged In: YES user_id=163326 Hmm. I don't like the _d endings at all. But if the policy on win32 is that debug executables and libraries get a "_d" ending, then I'm unsure wether this patch should be applied. I have plans to hack the autoconf madness to build a native win32 Python with mingw32. But that won't be ready by tomorror. And I don't think that I'll add "_d" endings there for debugging, because that would be inconsistent with the normal autoconf builds on Unix. I'm glad that *I* don't have to decide wether this patch is a Good Thing. Being consistent with Python win32 build or with GNU (gcc/autoconf). Take your pick :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-18 20:46 Message: Logged In: YES user_id=31435 FYI, MSVC never adds _d on its own -- Mark Hammond and/or Guido forced it to do that. I don't remember why, but one of them explained it to me long ago and it made good sense at the time . MSCV normally compiles debug and release builds into distinct subdirectories, and uses the same names in both. But *our* MSVC setup forces it to compile both flavors of build directly into the PCbuild directory, so has to give the resulting DLLs and executables different names (else the second build would overwrite the results of the first build). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:37:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:37:08 -0800 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 and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jörg Baumann (jgbauman) >Assigned to: Nobody/Anonymous (nobody) 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 Dec 6 21:37:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:37:21 -0800 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 and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Nobody/Anonymous (nobody) 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 Thu Dec 6 21:41:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:41:45 -0800 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 and setup.py Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Jörg Baumann (jgbauman) Assigned to: Nobody/Anonymous (nobody) Summary: Better SWIG with C++ support Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 13:41 Message: Logged In: YES user_id=6380 Neither Greg not Andrew seems to want this patch. Why don't you just reject and close it? ---------------------------------------------------------------------- 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 Dec 6 21:42:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:42:34 -0800 Subject: [Patches] [ python-Patches-490026 ] Namespace selection for rlcompleter Message-ID: Patches item #490026, was opened at 2001-12-06 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Namespace selection for rlcompleter Initial Comment: The standard rlcompleter is hardwired to work with __main__.__dict__. This is limiting, as one may have applications which execute in specially constructed 'sandboxed' namespaces. This patch extends rlcompleter with a constructor which provides an optional namespace specifier. This optional parameter defaults to __main__.__dict__, so the patch is 100% backwards compatible. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 From noreply@sourceforge.net Thu Dec 6 23:57:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 15:57:30 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) Assigned to: Tim Peters (tim_one) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:57 Message: Logged In: YES user_id=31435 To stevenknight: I don't see a description of "a bug" here, so it's hard to say whether this is a fix. If an app doesn't want to wait for a spawned program to complete, passing P_NOWAIT as the mode argument is the usual cure. There is some risk attached to this patch: it's possible that an app passing P_WAIT today is relying on that their program blocks until the spawned program completes. I expect that's a small risk, but any risk makes me uncomfortable for 2.2 since 2.2 had its final beta release. So I'd like to hear the case for why this patch is important (as above, there isn't a bug description here, just a purported cure). Note that if 2.2 were still in alpha test, I'd wouldn't think more than twice about applying the patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:57 Message: Logged In: YES user_id=3066 Hmmm... it would take some time to get a Windows build environment up on this machine. I'll assign this to Tim; hopefully someone can contribute a test case for this so there will be some chance he'll get to this for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:37 Message: Logged In: YES user_id=6380 Since it's Windows specific, can you test it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:25 Message: Logged In: YES user_id=3066 Are there any objections to my checking this in for Python 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:01 Message: Logged In: YES user_id=6380 I see no problem with the patch. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From noreply@sourceforge.net Fri Dec 7 00:02:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 16:02:51 -0800 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 and setup.py Group: None >Status: Deleted Resolution: None Priority: 3 Submitted By: Jörg Baumann (jgbauman) Assigned to: Nobody/Anonymous (nobody) Summary: Better SWIG with C++ support Initial Comment: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 13:41 Message: Logged In: YES user_id=6380 Neither Greg not Andrew seems to want this patch. Why don't you just reject and close it? ---------------------------------------------------------------------- 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 Fri Dec 7 00:16:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 16:16:08 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) Assigned to: Tim Peters (tim_one) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 16:16 Message: Logged In: YES user_id=216109 tim et al.-- Thanks for the discussion. Once I mentioned the word "bug," I probably should have filed an actual bug report to accompany Anthony's patch. However, at least for now, I'm less concerned (personally) about this making it into 2.2 than I am about knowing that this fix is "OK" so I can tell people who want -j (parallel build) support in SCons to patch their Python if they want it to work. That said, the problem this patch solves is: You can't use os.spawnve to spawn multiple processes from multiple *threads* simultaneously. In the SCons architecture, we create N threads when -j is used, and let each thread keep pulling the next thing to be done from an iterator and waiting for it to finish. This works fine with fork+exec, and if you accept that os.spawnve should have isomorphic behavior, it should work for os.spawnve as well. It doesn't, though, because the lack of Py_{BEGIN,END} _ALLOW_THREADS macros arround the _spawnv() call means the interpreter stops in its tracks, and no other threads run. A single thread waiting for a spawned process stops *all* threads from executing. Note that P_WAIT still works just fine in the non-threaded case, of course. I can see, though, that there *might* be someone out there who has multi-threaded code that's dependent on os.spawnv(P_WAIT) stopping all threads. Again, although it would be great to have this fixed, I'm not overly concerned about it being in 2.2, because I definitely agree about the need for caution once software is past final beta... If there's anything else I can do to help (file a bug report in Tracker, provide more info, etc.), let me know. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:57 Message: Logged In: YES user_id=31435 To stevenknight: I don't see a description of "a bug" here, so it's hard to say whether this is a fix. If an app doesn't want to wait for a spawned program to complete, passing P_NOWAIT as the mode argument is the usual cure. There is some risk attached to this patch: it's possible that an app passing P_WAIT today is relying on that their program blocks until the spawned program completes. I expect that's a small risk, but any risk makes me uncomfortable for 2.2 since 2.2 had its final beta release. So I'd like to hear the case for why this patch is important (as above, there isn't a bug description here, just a purported cure). Note that if 2.2 were still in alpha test, I'd wouldn't think more than twice about applying the patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:57 Message: Logged In: YES user_id=3066 Hmmm... it would take some time to get a Windows build environment up on this machine. I'll assign this to Tim; hopefully someone can contribute a test case for this so there will be some chance he'll get to this for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:37 Message: Logged In: YES user_id=6380 Since it's Windows specific, can you test it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:25 Message: Logged In: YES user_id=3066 Are there any objections to my checking this in for Python 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:01 Message: Logged In: YES user_id=6380 I see no problem with the patch. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From Keila - Curitiba" Ol=E1! Veja meu site pessoal. Basta clicar no endere=E7o abaixo. GARANTO SER SUI-GENERIS - CLIQUE ABAIXO: http://www.pastorinha.atfreeweb.com Mais de 162.000 internautas visitaram a PG., existe 6 =C1lbuns: Se voc=EA quiser, por favor, indique minha Home Page, a outros Internautas. Mais detalhes, se comunique, passe um e-mail, que responderei brevemente. Dentro da Home Page, ao lado das fotos, voc=EA poder=E1 saber muito mais sobre mim! Obrigada. e-mail: arosadesaron@zipmail.com.br Beijos:- Keila - Curitiba - Pr - Podes falar comigo, direto dela. Brevemente uma Carta Aberta. - Embora derrubem a p=E1gina eu a subo em 3 horas novamente. "Esta mensagem =E9 enviada com a complac=EAncia da nova legisla=E7=E3o=20 sobre correio eletr=F4nico, Se=E7=E3o 301, Par=E1grafo (a) (2) (c) Decreto S. 1= 618, T=EDtulo Terceiro aprovado pelo "105=BA Congresso Base das Normativas Internacionais sobre o SPAM". Este E-mail n=E3o poder=E1 ser considerado SPAM quando incluir uma forma de ser removido. Para ser removido de futuros correios, simplesmente responda indicando no Assunto: REMOVER" From noreply@sourceforge.net Fri Dec 7 02:44:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 18:44:32 -0800 Subject: [Patches] [ python-Patches-490100 ] Lets Tkinter work with MacOSX native Tk Message-ID: Patches item #490100, was opened at 2001-12-06 18:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490100&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: Lets Tkinter work with MacOSX native Tk Initial Comment: There is a new Tcl/Tk in alpha that works on MacOSX's windowing layer natively. This patch adds calls necessary for Tkinter to work with it. The Tcl/Tk alpha can be picked up here: http://sourceforge.net/project/showfiles.php?group_id=10894 NOTE: The amount of extra code needed to interface with Tcl/Tk will probably go down with the next alpha of Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490100&group_id=5470 From noreply@sourceforge.net Fri Dec 7 02:52:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 18:52:49 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) Assigned to: Tim Peters (tim_one) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:52 Message: Logged In: YES user_id=31435 I'm still not clear on what's wrong with using P_NOWAIT. A call to spawnv returns quickly then, and that's no real impediment to parallelization at the granularity of compiler invocations. Ah -- but on Windows, there's then no way in core Python to poll the returned process handle for termination, or to get the process exit status when it's done. Is *that* the hangup? If so, you coulda said so . I'm going to sleep on this one. I'm leaning toward applying the patch for 2.2: there wouldn't have been any controversy had that been done from the start, so it's where I want to see Python end up. You don't need to file a bug report, etc -- and thank you for explaining the situation. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 16:16 Message: Logged In: YES user_id=216109 tim et al.-- Thanks for the discussion. Once I mentioned the word "bug," I probably should have filed an actual bug report to accompany Anthony's patch. However, at least for now, I'm less concerned (personally) about this making it into 2.2 than I am about knowing that this fix is "OK" so I can tell people who want -j (parallel build) support in SCons to patch their Python if they want it to work. That said, the problem this patch solves is: You can't use os.spawnve to spawn multiple processes from multiple *threads* simultaneously. In the SCons architecture, we create N threads when -j is used, and let each thread keep pulling the next thing to be done from an iterator and waiting for it to finish. This works fine with fork+exec, and if you accept that os.spawnve should have isomorphic behavior, it should work for os.spawnve as well. It doesn't, though, because the lack of Py_{BEGIN,END} _ALLOW_THREADS macros arround the _spawnv() call means the interpreter stops in its tracks, and no other threads run. A single thread waiting for a spawned process stops *all* threads from executing. Note that P_WAIT still works just fine in the non-threaded case, of course. I can see, though, that there *might* be someone out there who has multi-threaded code that's dependent on os.spawnv(P_WAIT) stopping all threads. Again, although it would be great to have this fixed, I'm not overly concerned about it being in 2.2, because I definitely agree about the need for caution once software is past final beta... If there's anything else I can do to help (file a bug report in Tracker, provide more info, etc.), let me know. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:57 Message: Logged In: YES user_id=31435 To stevenknight: I don't see a description of "a bug" here, so it's hard to say whether this is a fix. If an app doesn't want to wait for a spawned program to complete, passing P_NOWAIT as the mode argument is the usual cure. There is some risk attached to this patch: it's possible that an app passing P_WAIT today is relying on that their program blocks until the spawned program completes. I expect that's a small risk, but any risk makes me uncomfortable for 2.2 since 2.2 had its final beta release. So I'd like to hear the case for why this patch is important (as above, there isn't a bug description here, just a purported cure). Note that if 2.2 were still in alpha test, I'd wouldn't think more than twice about applying the patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:57 Message: Logged In: YES user_id=3066 Hmmm... it would take some time to get a Windows build environment up on this machine. I'll assign this to Tim; hopefully someone can contribute a test case for this so there will be some chance he'll get to this for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:37 Message: Logged In: YES user_id=6380 Since it's Windows specific, can you test it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:25 Message: Logged In: YES user_id=3066 Are there any objections to my checking this in for Python 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:01 Message: Logged In: YES user_id=6380 I see no problem with the patch. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From noreply@sourceforge.net Fri Dec 7 06:38:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 22:38:07 -0800 Subject: [Patches] [ python-Patches-479898 ] Multibyte string on string::string_print Message-ID: Patches item #479898, was opened at 2001-11-08 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Multibyte string on string::string_print Initial Comment: Many multibyte language users are difficult to see native characters on list or dictionary and etc. This patch allows printing multibyte on UNIX98- compatible machines; mbtowc() is ISO/IEC 9899:1990 standard C-API function. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2001-12-06 22:38 Message: Logged In: YES user_id=55188 Yes, it should be changed to iswprint on Linux systems. (but, isprint of BSD systems was designed for wide characters) As loewis told, EUC codes of Korea, Japan, Taiwan doesn't use 0x7F-0x9F for printable character. So, I think that using mbtowc is unavoidable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=21627 You are right, the code should use iswprint instead. The point is that multiple subsequent bytes can make up a single printable character. Not every character above 127 is necessarily printable (e.g. in Latin-1, only characters above 160 are printable). Likewise, a single byte may not be printable, but a combination will print fine. So this code is supposed to catch only those cases where printing will actually work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:08 Message: Logged In: YES user_id=6380 I don't understand the point of using mbtowc() here. The code extracts a wide character, but then it uses isprint() on it, and as far as I know, isprint() is not defined on wide characters, only on 'unsigned char' (and on -1). Isn't what the author wants simply to is isprint(c) instead of (c < ' ' || c >= 0x7f)??? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 13:21 Message: Logged In: YES user_id=21627 Even though I think this patch is correct in principle, I see a few problems with it: 1. Since it doesn't fix a bug, it probably cannot go into 2.2. 2. There is no autoconf test for mbtowc. You should test this in configure, and then conditionalize your code on HAVE_MBTOWC. 3. There is too much code duplication. Try to find a solution which special-cases the escape codes (\something) only once. For example, you may implement a trivial mbtowc redefinition if mbtowc is not available, and then use mbtowc always. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 From noreply@sourceforge.net Fri Dec 7 09:20:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 01:20:50 -0800 Subject: [Patches] [ python-Patches-490100 ] Lets Tkinter work with MacOSX native Tk Message-ID: Patches item #490100, was opened at 2001-12-06 18:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490100&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: Lets Tkinter work with MacOSX native Tk Initial Comment: There is a new Tcl/Tk in alpha that works on MacOSX's windowing layer natively. This patch adds calls necessary for Tkinter to work with it. The Tcl/Tk alpha can be picked up here: http://sourceforge.net/project/showfiles.php?group_id=10894 NOTE: The amount of extra code needed to interface with Tcl/Tk will probably go down with the next alpha of Tcl/Tk. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-07 01:20 Message: Logged In: YES user_id=21627 Please review your patches carefully before submitting them. Why does this change PyOS_snprintf to sprintf? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490100&group_id=5470 From noreply@sourceforge.net Fri Dec 7 10:34:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 02:34:54 -0800 Subject: [Patches] [ python-Patches-490100 ] Lets Tkinter work with MacOSX native Tk Message-ID: Patches item #490100, was opened at 2001-12-06 18:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490100&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: Lets Tkinter work with MacOSX native Tk Initial Comment: There is a new Tcl/Tk in alpha that works on MacOSX's windowing layer natively. This patch adds calls necessary for Tkinter to work with it. The Tcl/Tk alpha can be picked up here: http://sourceforge.net/project/showfiles.php?group_id=10894 NOTE: The amount of extra code needed to interface with Tcl/Tk will probably go down with the next alpha of Tcl/Tk. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-07 02:34 Message: Logged In: YES user_id=45365 I assume the sprintf change was a mistake (I've undone it after I applied the patch). Aside from that the patch looks harmless to other platforms, but I haven't gotten it to work yet. It fails compilation with a missing X11/Xlib.h include. If I can get it to compile at least once I'll put it in CVS before 2.2 (even though it is only useful to the real die-hards: it requires a Tk alfa, and only works under the experimental framework-based Python.app). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-07 01:20 Message: Logged In: YES user_id=21627 Please review your patches carefully before submitting them. Why does this change PyOS_snprintf to sprintf? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490100&group_id=5470 From noreply@sourceforge.net Fri Dec 7 12:22:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 04:22:54 -0800 Subject: [Patches] [ python-Patches-489388 ] configure.in patch for OSX Message-ID: Patches item #489388, was opened at 2001-12-05 06:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489388&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: configure.in patch for OSX Initial Comment: Anthony, this patch is a sort-of backport of checkins 1.255 (make Python build on OSX 10.1) and 1.281 (reverse order of test for old OSX and new OSX releases). With this patch Python builds on 10.1 and 10.1.1, and I have pretty good confidence it will also build on 10.0. On 10.1.1 you will get an error because it tries to build curses, this will be fixed on the main branch shortly and I'll flag the patch (to setup.py). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-07 04:22 Message: Logged In: YES user_id=45365 It turns out the fix I did for the curses build in the tree trunk is not suitable for 2.1.2 (I've chaned the sys.platform value). I'll submit a 2.1.2-specific patch shortly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489388&group_id=5470 From noreply@sourceforge.net Fri Dec 7 13:21:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 05:21:59 -0800 Subject: [Patches] [ python-Patches-479898 ] Multibyte string on string::string_print Message-ID: Patches item #479898, was opened at 2001-11-08 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Multibyte string on string::string_print Initial Comment: Many multibyte language users are difficult to see native characters on list or dictionary and etc. This patch allows printing multibyte on UNIX98- compatible machines; mbtowc() is ISO/IEC 9899:1990 standard C-API function. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:21 Message: Logged In: YES user_id=6380 Still, the patch as it exists is unacceptable -- it needs configure support to decide whether to use mbtowc() and whether to use iswprint() or isprint() (I would hope on BSD there is also an iswprint(), to be standard-conforming). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-06 22:38 Message: Logged In: YES user_id=55188 Yes, it should be changed to iswprint on Linux systems. (but, isprint of BSD systems was designed for wide characters) As loewis told, EUC codes of Korea, Japan, Taiwan doesn't use 0x7F-0x9F for printable character. So, I think that using mbtowc is unavoidable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=21627 You are right, the code should use iswprint instead. The point is that multiple subsequent bytes can make up a single printable character. Not every character above 127 is necessarily printable (e.g. in Latin-1, only characters above 160 are printable). Likewise, a single byte may not be printable, but a combination will print fine. So this code is supposed to catch only those cases where printing will actually work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:08 Message: Logged In: YES user_id=6380 I don't understand the point of using mbtowc() here. The code extracts a wide character, but then it uses isprint() on it, and as far as I know, isprint() is not defined on wide characters, only on 'unsigned char' (and on -1). Isn't what the author wants simply to is isprint(c) instead of (c < ' ' || c >= 0x7f)??? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 13:21 Message: Logged In: YES user_id=21627 Even though I think this patch is correct in principle, I see a few problems with it: 1. Since it doesn't fix a bug, it probably cannot go into 2.2. 2. There is no autoconf test for mbtowc. You should test this in configure, and then conditionalize your code on HAVE_MBTOWC. 3. There is too much code duplication. Try to find a solution which special-cases the escape codes (\something) only once. For example, you may implement a trivial mbtowc redefinition if mbtowc is not available, and then use mbtowc always. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 From info@newyears.com Fri Dec 7 16:01:41 2001 From: info@newyears.com (NewYears.com) Date: Fri, 07 Dec 2001 11:01:41 -0500 Subject: [Patches] Newyears.com Newsletter Message-ID: --___KingMailer_Related_1964_asbhsdjhglwKM___ Content-Type: multipart/alternative; boundary="___KingMailer_Alternative_1964_asbhsdjhglwKM___" --___KingMailer_Alternative_1964_asbhsdjhglwKM___ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a HTML mail --___KingMailer_Alternative_1964_asbhsdjhglwKM___ Content-Type:text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NewYears.com Newsletter
=20
=20


Welcome to the Global New Year's Party Guide
[Note:] If you'd like to continue to r= eceive=20 updates on New Year's Eve parties in your city, click here,=20 or just go to NewYears.= com=20 and enter your e-mail address.

Looking for the best parties and biggest DJs for New Year'= s Eve?=20 The nightlife scientists at NewYears.com=20 have scoured the globe to help you have the best New Year's= Eve=20 ever.

Revelers around the world now have a global resource to he= lp them=20 make the most of the biggest party night of the year. NewYears.com=20 lists parties at top clubs in every major market, providing= in-depth=20 information on artist lineups, party details and advance ti= cket=20 sales.

Check out our featured party below, or check NewYears.com=20 for more parties. New events are being added all the time. =


=20
=20

FEATURED PA= RTY: AMERICA= =20 (NYC)
New Years Eve 2002
9 East 18th Street (bet. 5th and Bway)

Party Type: Dance & DJ, Formal
Music: Live DJ spining classics, R&B, House and Hip-Hop= =2E
Dress: Optional Black Tie
Time: 9:30 - 4:00
Price: $150 before 12/14; $175 before 12/21; $200 after 12/= 21

Mario Stewart, Chad Cooper, Erica Maurer and NewYears.com = present=20 New Year's 2002 at America. Join an uptown/downtown trendy = crowd=20 for the premier NYC party for young professionals.

Champagne reception from 9:30-10.
Top-shelf open bar from 10-4.
Gourmet hors d'oeuvres from 10-midnight.
Champagne toast at midnight.
Dessert bar.
Continental breakfast

$150.003D"pad"<= INPUT NAME=3Dvwcatalog TYPE=3DHIDDEN VALUE=3D"NEWYEARS">
=20
=20
=20
=20
You have received this = e-mail because=20 you you are a registered member of NewYears.com or another = affiliated=20 website. If you no longer wish to be on our mailing list, c= lick=20 here.=20

Copyright 2001 NewYears.com All Rights Re= served

=20 =20
--___KingMailer_Alternative_1964_asbhsdjhglwKM___-- --___KingMailer_Related_1964_asbhsdjhglwKM___-- From noreply@sourceforge.net Fri Dec 7 18:03:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 10:03:59 -0800 Subject: [Patches] [ python-Patches-490330 ] String format bug in test_b2 Message-ID: Patches item #490330, was opened at 2001-12-07 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490330&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: String format bug in test_b2 Initial Comment: The string formatting of an error message in test_b2 will raise a "TypeError: not all arguments converted" if the pow() implementation isn't correct. The patch will match the number of %s with the number of arguments. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490330&group_id=5470 From noreply@sourceforge.net Fri Dec 7 18:08:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 10:08:20 -0800 Subject: [Patches] [ python-Patches-490330 ] String format bug in test_b2 Message-ID: Patches item #490330, was opened at 2001-12-07 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490330&group_id=5470 >Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: String format bug in test_b2 Initial Comment: The string formatting of an error message in test_b2 will raise a "TypeError: not all arguments converted" if the pow() implementation isn't correct. The patch will match the number of %s with the number of arguments. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 10:08 Message: Logged In: YES user_id=6380 Looks good. Can you apply this yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490330&group_id=5470 From noreply@sourceforge.net Fri Dec 7 18:22:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 10:22:50 -0800 Subject: [Patches] [ python-Patches-490330 ] String format bug in test_b2 Message-ID: Patches item #490330, was opened at 2001-12-07 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490330&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: String format bug in test_b2 Initial Comment: The string formatting of an error message in test_b2 will raise a "TypeError: not all arguments converted" if the pow() implementation isn't correct. The patch will match the number of %s with the number of arguments. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-07 10:22 Message: Logged In: YES user_id=4201 Applied to test_b2.py: 1.29 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 10:08 Message: Logged In: YES user_id=6380 Looks good. Can you apply this yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490330&group_id=5470 From noreply@sourceforge.net Fri Dec 7 18:32:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 10:32:02 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) Assigned to: Tim Peters (tim_one) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- >Comment By: Anthony Roach (anthonyroach) Date: 2001-12-07 10:32 Message: Logged In: YES user_id=257519 Tim: You are correct that the problem is we need to get the return value from the process, so P_NOWAIT is not an option. My reason for seeing os.spawnv() blocking the interpreter as a bug is that os.system() does not block the interpreter. Based on the documentation and intended use of os.spawnv(), it should work just like os.system() wrt to blocking the interpreter. os.spawnv() just adds the ability to specify the arguments as a list, and os.spawnve() adds the ability to specify the environment. If os.spawnve() blocks the interpreter, then there is no way, on win32, to have a single process spawn multiple processes in parallel with a specific environment. I understand that you are concerned about breaking backward compatility. I'd like to see this fix get into Python 2.2, so we can tell our users that they can have -j support in scons if they use Python 2.2, but I would understand if you decide to put this off until Python 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:52 Message: Logged In: YES user_id=31435 I'm still not clear on what's wrong with using P_NOWAIT. A call to spawnv returns quickly then, and that's no real impediment to parallelization at the granularity of compiler invocations. Ah -- but on Windows, there's then no way in core Python to poll the returned process handle for termination, or to get the process exit status when it's done. Is *that* the hangup? If so, you coulda said so . I'm going to sleep on this one. I'm leaning toward applying the patch for 2.2: there wouldn't have been any controversy had that been done from the start, so it's where I want to see Python end up. You don't need to file a bug report, etc -- and thank you for explaining the situation. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 16:16 Message: Logged In: YES user_id=216109 tim et al.-- Thanks for the discussion. Once I mentioned the word "bug," I probably should have filed an actual bug report to accompany Anthony's patch. However, at least for now, I'm less concerned (personally) about this making it into 2.2 than I am about knowing that this fix is "OK" so I can tell people who want -j (parallel build) support in SCons to patch their Python if they want it to work. That said, the problem this patch solves is: You can't use os.spawnve to spawn multiple processes from multiple *threads* simultaneously. In the SCons architecture, we create N threads when -j is used, and let each thread keep pulling the next thing to be done from an iterator and waiting for it to finish. This works fine with fork+exec, and if you accept that os.spawnve should have isomorphic behavior, it should work for os.spawnve as well. It doesn't, though, because the lack of Py_{BEGIN,END} _ALLOW_THREADS macros arround the _spawnv() call means the interpreter stops in its tracks, and no other threads run. A single thread waiting for a spawned process stops *all* threads from executing. Note that P_WAIT still works just fine in the non-threaded case, of course. I can see, though, that there *might* be someone out there who has multi-threaded code that's dependent on os.spawnv(P_WAIT) stopping all threads. Again, although it would be great to have this fixed, I'm not overly concerned about it being in 2.2, because I definitely agree about the need for caution once software is past final beta... If there's anything else I can do to help (file a bug report in Tracker, provide more info, etc.), let me know. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:57 Message: Logged In: YES user_id=31435 To stevenknight: I don't see a description of "a bug" here, so it's hard to say whether this is a fix. If an app doesn't want to wait for a spawned program to complete, passing P_NOWAIT as the mode argument is the usual cure. There is some risk attached to this patch: it's possible that an app passing P_WAIT today is relying on that their program blocks until the spawned program completes. I expect that's a small risk, but any risk makes me uncomfortable for 2.2 since 2.2 had its final beta release. So I'd like to hear the case for why this patch is important (as above, there isn't a bug description here, just a purported cure). Note that if 2.2 were still in alpha test, I'd wouldn't think more than twice about applying the patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:57 Message: Logged In: YES user_id=3066 Hmmm... it would take some time to get a Windows build environment up on this machine. I'll assign this to Tim; hopefully someone can contribute a test case for this so there will be some chance he'll get to this for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:37 Message: Logged In: YES user_id=6380 Since it's Windows specific, can you test it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:25 Message: Logged In: YES user_id=3066 Are there any objections to my checking this in for Python 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:01 Message: Logged In: YES user_id=6380 I see no problem with the patch. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From noreply@sourceforge.net Fri Dec 7 18:34:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 10:34:21 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Roach (anthonyroach) Assigned to: Tim Peters (tim_one) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- >Comment By: Anthony Roach (anthonyroach) Date: 2001-12-07 10:34 Message: Logged In: YES user_id=257519 I meant "get the exit status of the process" rather than "get the return value from the process". :-) ---------------------------------------------------------------------- Comment By: Anthony Roach (anthonyroach) Date: 2001-12-07 10:32 Message: Logged In: YES user_id=257519 Tim: You are correct that the problem is we need to get the return value from the process, so P_NOWAIT is not an option. My reason for seeing os.spawnv() blocking the interpreter as a bug is that os.system() does not block the interpreter. Based on the documentation and intended use of os.spawnv(), it should work just like os.system() wrt to blocking the interpreter. os.spawnv() just adds the ability to specify the arguments as a list, and os.spawnve() adds the ability to specify the environment. If os.spawnve() blocks the interpreter, then there is no way, on win32, to have a single process spawn multiple processes in parallel with a specific environment. I understand that you are concerned about breaking backward compatility. I'd like to see this fix get into Python 2.2, so we can tell our users that they can have -j support in scons if they use Python 2.2, but I would understand if you decide to put this off until Python 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:52 Message: Logged In: YES user_id=31435 I'm still not clear on what's wrong with using P_NOWAIT. A call to spawnv returns quickly then, and that's no real impediment to parallelization at the granularity of compiler invocations. Ah -- but on Windows, there's then no way in core Python to poll the returned process handle for termination, or to get the process exit status when it's done. Is *that* the hangup? If so, you coulda said so . I'm going to sleep on this one. I'm leaning toward applying the patch for 2.2: there wouldn't have been any controversy had that been done from the start, so it's where I want to see Python end up. You don't need to file a bug report, etc -- and thank you for explaining the situation. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 16:16 Message: Logged In: YES user_id=216109 tim et al.-- Thanks for the discussion. Once I mentioned the word "bug," I probably should have filed an actual bug report to accompany Anthony's patch. However, at least for now, I'm less concerned (personally) about this making it into 2.2 than I am about knowing that this fix is "OK" so I can tell people who want -j (parallel build) support in SCons to patch their Python if they want it to work. That said, the problem this patch solves is: You can't use os.spawnve to spawn multiple processes from multiple *threads* simultaneously. In the SCons architecture, we create N threads when -j is used, and let each thread keep pulling the next thing to be done from an iterator and waiting for it to finish. This works fine with fork+exec, and if you accept that os.spawnve should have isomorphic behavior, it should work for os.spawnve as well. It doesn't, though, because the lack of Py_{BEGIN,END} _ALLOW_THREADS macros arround the _spawnv() call means the interpreter stops in its tracks, and no other threads run. A single thread waiting for a spawned process stops *all* threads from executing. Note that P_WAIT still works just fine in the non-threaded case, of course. I can see, though, that there *might* be someone out there who has multi-threaded code that's dependent on os.spawnv(P_WAIT) stopping all threads. Again, although it would be great to have this fixed, I'm not overly concerned about it being in 2.2, because I definitely agree about the need for caution once software is past final beta... If there's anything else I can do to help (file a bug report in Tracker, provide more info, etc.), let me know. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:57 Message: Logged In: YES user_id=31435 To stevenknight: I don't see a description of "a bug" here, so it's hard to say whether this is a fix. If an app doesn't want to wait for a spawned program to complete, passing P_NOWAIT as the mode argument is the usual cure. There is some risk attached to this patch: it's possible that an app passing P_WAIT today is relying on that their program blocks until the spawned program completes. I expect that's a small risk, but any risk makes me uncomfortable for 2.2 since 2.2 had its final beta release. So I'd like to hear the case for why this patch is important (as above, there isn't a bug description here, just a purported cure). Note that if 2.2 were still in alpha test, I'd wouldn't think more than twice about applying the patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:57 Message: Logged In: YES user_id=3066 Hmmm... it would take some time to get a Windows build environment up on this machine. I'll assign this to Tim; hopefully someone can contribute a test case for this so there will be some chance he'll get to this for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:37 Message: Logged In: YES user_id=6380 Since it's Windows specific, can you test it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:25 Message: Logged In: YES user_id=3066 Are there any objections to my checking this in for Python 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:01 Message: Logged In: YES user_id=6380 I see no problem with the patch. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From noreply@sourceforge.net Fri Dec 7 19:58:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 11:58:00 -0800 Subject: [Patches] [ python-Patches-490374 ] make inspect.stack() work with PyShell Message-ID: Patches item #490374, was opened at 2001-12-07 11:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490374&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: make inspect.stack() work with PyShell Initial Comment: I'm on Python 2.2b2 on Windows. Changed the 'inspect' module to use 'linecache' for loading source code. This is more efficient. Also, 'inspect' now can see the source code of stuff entered in the IDLE PyShell. E.g. In IDLE, type: >>> import inspect >>> inspect.stack()[0] Without the patch, the output would be like this: (, None, 1, '?', None, None) With this patch: (, '', 1, '?', ['inspect.stack()[0]'], 0) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490374&group_id=5470 From noreply@sourceforge.net Fri Dec 7 20:04:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 12:04:01 -0800 Subject: [Patches] [ python-Patches-490374 ] make inspect.stack() work with PyShell Message-ID: Patches item #490374, was opened at 2001-12-07 11:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490374&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) >Assigned to: Tim Peters (tim_one) Summary: make inspect.stack() work with PyShell Initial Comment: I'm on Python 2.2b2 on Windows. Changed the 'inspect' module to use 'linecache' for loading source code. This is more efficient. Also, 'inspect' now can see the source code of stuff entered in the IDLE PyShell. E.g. In IDLE, type: >>> import inspect >>> inspect.stack()[0] Without the patch, the output would be like this: (, None, 1, '?', None, None) With this patch: (, '', 1, '?', ['inspect.stack()[0]'], 0) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 12:04 Message: Logged In: YES user_id=6380 Assigned to Tim for review, since he knows inspect.py inside-out. :-) It's probably too late for 2.2, unless you can prove this is a bugfix and not a feature. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490374&group_id=5470 From noreply@sourceforge.net Fri Dec 7 20:07:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 12:07:40 -0800 Subject: [Patches] [ python-Patches-490374 ] make inspect.stack() work with PyShell Message-ID: Patches item #490374, was opened at 2001-12-07 11:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490374&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) >Assigned to: Nobody/Anonymous (nobody) Summary: make inspect.stack() work with PyShell Initial Comment: I'm on Python 2.2b2 on Windows. Changed the 'inspect' module to use 'linecache' for loading source code. This is more efficient. Also, 'inspect' now can see the source code of stuff entered in the IDLE PyShell. E.g. In IDLE, type: >>> import inspect >>> inspect.stack()[0] Without the patch, the output would be like this: (, None, 1, '?', None, None) With this patch: (, '', 1, '?', ['inspect.stack()[0]'], 0) ---------------------------------------------------------------------- >Comment By: Jason Orendorff (jorend) Date: 2001-12-07 12:07 Message: Logged In: YES user_id=18139 I'm afraid it's definitely a feature. (sigh) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 12:04 Message: Logged In: YES user_id=6380 Assigned to Tim for review, since he knows inspect.py inside-out. :-) It's probably too late for 2.2, unless you can prove this is a bugfix and not a feature. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490374&group_id=5470 From noreply@sourceforge.net Fri Dec 7 20:36:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 12:36:49 -0800 Subject: [Patches] [ python-Patches-489173 ] Make os.spawnv not block the interpreter Message-ID: Patches item #489173, was opened at 2001-12-04 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Anthony Roach (anthonyroach) Assigned to: Tim Peters (tim_one) Summary: Make os.spawnv not block the interpreter Initial Comment: Someone forgot to bracket the calls to _spawnv() and _spawnve() with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. This patch also fixes an error in the docstrings for os.spawnv and os.spawnve. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-07 12:36 Message: Logged In: YES user_id=31435 Accepted and applied, to python/Misc/ACKS; new revision: 1.142 Misc/NEWS; new revision: 1.331 Modules/posixmodule.c; new revision: 2.214 (So, yes, this will be in 2.2) Thanks for the patch! ---------------------------------------------------------------------- Comment By: Anthony Roach (anthonyroach) Date: 2001-12-07 10:34 Message: Logged In: YES user_id=257519 I meant "get the exit status of the process" rather than "get the return value from the process". :-) ---------------------------------------------------------------------- Comment By: Anthony Roach (anthonyroach) Date: 2001-12-07 10:32 Message: Logged In: YES user_id=257519 Tim: You are correct that the problem is we need to get the return value from the process, so P_NOWAIT is not an option. My reason for seeing os.spawnv() blocking the interpreter as a bug is that os.system() does not block the interpreter. Based on the documentation and intended use of os.spawnv(), it should work just like os.system() wrt to blocking the interpreter. os.spawnv() just adds the ability to specify the arguments as a list, and os.spawnve() adds the ability to specify the environment. If os.spawnve() blocks the interpreter, then there is no way, on win32, to have a single process spawn multiple processes in parallel with a specific environment. I understand that you are concerned about breaking backward compatility. I'd like to see this fix get into Python 2.2, so we can tell our users that they can have -j support in scons if they use Python 2.2, but I would understand if you decide to put this off until Python 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:52 Message: Logged In: YES user_id=31435 I'm still not clear on what's wrong with using P_NOWAIT. A call to spawnv returns quickly then, and that's no real impediment to parallelization at the granularity of compiler invocations. Ah -- but on Windows, there's then no way in core Python to poll the returned process handle for termination, or to get the process exit status when it's done. Is *that* the hangup? If so, you coulda said so . I'm going to sleep on this one. I'm leaning toward applying the patch for 2.2: there wouldn't have been any controversy had that been done from the start, so it's where I want to see Python end up. You don't need to file a bug report, etc -- and thank you for explaining the situation. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 16:16 Message: Logged In: YES user_id=216109 tim et al.-- Thanks for the discussion. Once I mentioned the word "bug," I probably should have filed an actual bug report to accompany Anthony's patch. However, at least for now, I'm less concerned (personally) about this making it into 2.2 than I am about knowing that this fix is "OK" so I can tell people who want -j (parallel build) support in SCons to patch their Python if they want it to work. That said, the problem this patch solves is: You can't use os.spawnve to spawn multiple processes from multiple *threads* simultaneously. In the SCons architecture, we create N threads when -j is used, and let each thread keep pulling the next thing to be done from an iterator and waiting for it to finish. This works fine with fork+exec, and if you accept that os.spawnve should have isomorphic behavior, it should work for os.spawnve as well. It doesn't, though, because the lack of Py_{BEGIN,END} _ALLOW_THREADS macros arround the _spawnv() call means the interpreter stops in its tracks, and no other threads run. A single thread waiting for a spawned process stops *all* threads from executing. Note that P_WAIT still works just fine in the non-threaded case, of course. I can see, though, that there *might* be someone out there who has multi-threaded code that's dependent on os.spawnv(P_WAIT) stopping all threads. Again, although it would be great to have this fixed, I'm not overly concerned about it being in 2.2, because I definitely agree about the need for caution once software is past final beta... If there's anything else I can do to help (file a bug report in Tracker, provide more info, etc.), let me know. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:57 Message: Logged In: YES user_id=31435 To stevenknight: I don't see a description of "a bug" here, so it's hard to say whether this is a fix. If an app doesn't want to wait for a spawned program to complete, passing P_NOWAIT as the mode argument is the usual cure. There is some risk attached to this patch: it's possible that an app passing P_WAIT today is relying on that their program blocks until the spawned program completes. I expect that's a small risk, but any risk makes me uncomfortable for 2.2 since 2.2 had its final beta release. So I'd like to hear the case for why this patch is important (as above, there isn't a bug description here, just a purported cure). Note that if 2.2 were still in alpha test, I'd wouldn't think more than twice about applying the patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:57 Message: Logged In: YES user_id=3066 Hmmm... it would take some time to get a Windows build environment up on this machine. I'll assign this to Tim; hopefully someone can contribute a test case for this so there will be some chance he'll get to this for Python 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:37 Message: Logged In: YES user_id=6380 Since it's Windows specific, can you test it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:25 Message: Logged In: YES user_id=3066 Are there any objections to my checking this in for Python 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:01 Message: Logged In: YES user_id=6380 I see no problem with the patch. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2001-12-06 04:04 Message: Logged In: YES user_id=216109 As the SCons project lead, it would be nice to have a response from someone on the Python team acknowledging that this is the right fix for this bug. As it is, it looks like we're going to have to ship SCons without -j support on WIN32 systems due to this problem in Python, but it would be nice to be able to point people to this patch with confidence, if they want to add the support to their own copy of Python themselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489173&group_id=5470 From noreply@sourceforge.net Fri Dec 7 20:46:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 12:46:18 -0800 Subject: [Patches] [ python-Patches-490393 ] test___all__ and Jython Message-ID: Patches item #490393, was opened at 2001-12-07 12:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490393&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: test___all__ and Jython Initial Comment: Whatever good it does to import _socket, it doesn't make any sense for Jython. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490393&group_id=5470 From noreply@sourceforge.net Fri Dec 7 20:54:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 12:54:03 -0800 Subject: [Patches] [ python-Patches-490393 ] test___all__ and Jython Message-ID: Patches item #490393, was opened at 2001-12-07 12:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490393&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Tim Peters (tim_one) Summary: test___all__ and Jython Initial Comment: Whatever good it does to import _socket, it doesn't make any sense for Jython. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490393&group_id=5470 From noreply@sourceforge.net Fri Dec 7 20:57:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 12:57:35 -0800 Subject: [Patches] [ python-Patches-490393 ] test___all__ and Jython Message-ID: Patches item #490393, was opened at 2001-12-07 12:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490393&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Tim Peters (tim_one) Summary: test___all__ and Jython Initial Comment: Whatever good it does to import _socket, it doesn't make any sense for Jython. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-07 12:57 Message: Logged In: YES user_id=31435 Finn, is there some reason you avoid .startswith() here? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490393&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:09:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:09:41 -0800 Subject: [Patches] [ python-Patches-490402 ] Improper PyMethodObject->im_class fix Message-ID: Patches item #490402, was opened at 2001-12-07 13:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Nobody/Anonymous (nobody) Summary: Improper PyMethodObject->im_class fix Initial Comment: In wxPython's code for reflecting virtual method calls to Python methods I have code that looks up the method by name and checks the class it comes from. If it's in the base Python shadow class then I just call the base C++ method directly to save time, otherwise I call the Python method. In the Python 2.2 betas I found that the class object returned from PyMethod_GET_CLASS is now the class of the instance, not the class where the method was defined as it was before, and as documented in classobject.h. This causes my code to recurse until the max stack depth is reached, and I've been unable to find a way to work around this change. The differences can be further illustrated by this little Python program: class A: def spam(self): print "spam" class B(A): pass import sys print sys.version b = B() print b.spam print B.spam When run with various version of Python I get this: [C:\temp] p15 method_test.py 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] [C:\temp] p20 method_test.py 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] [C:\temp] p21 method_test.py 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] [C:\temp] p22 method_test.py 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] > Notice the change from "A.spam" to "B.spam" in the final case. Going on the assumption that this is a bug and not intended behaviour, the attached patch fixes this issue as can be seen in this run of the test, but I don't know if there are any other ramifications: [C:\temp] \PROJECTS\Python-cvs\PCbuild\python_d.exe method_test.py Adding parser accelerators ... Done. 2.2b2+ (#26, Dec 7 2001, 11:46:31) [MSC 32 bit (Intel)] > [3306 refs] If this is not a bug then please let me know what the proper way is via the API to find the class that defined a particular method. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:15:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:15:36 -0800 Subject: [Patches] [ python-Patches-490402 ] Improper PyMethodObject->im_class fix Message-ID: Patches item #490402, was opened at 2001-12-07 13:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) >Assigned to: Guido van Rossum (gvanrossum) Summary: Improper PyMethodObject->im_class fix Initial Comment: In wxPython's code for reflecting virtual method calls to Python methods I have code that looks up the method by name and checks the class it comes from. If it's in the base Python shadow class then I just call the base C++ method directly to save time, otherwise I call the Python method. In the Python 2.2 betas I found that the class object returned from PyMethod_GET_CLASS is now the class of the instance, not the class where the method was defined as it was before, and as documented in classobject.h. This causes my code to recurse until the max stack depth is reached, and I've been unable to find a way to work around this change. The differences can be further illustrated by this little Python program: class A: def spam(self): print "spam" class B(A): pass import sys print sys.version b = B() print b.spam print B.spam When run with various version of Python I get this: [C:\temp] p15 method_test.py 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] [C:\temp] p20 method_test.py 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] [C:\temp] p21 method_test.py 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] [C:\temp] p22 method_test.py 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] > Notice the change from "A.spam" to "B.spam" in the final case. Going on the assumption that this is a bug and not intended behaviour, the attached patch fixes this issue as can be seen in this run of the test, but I don't know if there are any other ramifications: [C:\temp] \PROJECTS\Python-cvs\PCbuild\python_d.exe method_test.py Adding parser accelerators ... Done. 2.2b2+ (#26, Dec 7 2001, 11:46:31) [MSC 32 bit (Intel)] > [3306 refs] If this is not a bug then please let me know what the proper way is via the API to find the class that defined a particular method. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-07 13:15 Message: Logged In: YES user_id=31435 This one's for Guido. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:23:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:23:01 -0800 Subject: [Patches] [ python-Patches-490393 ] test___all__ and Jython Message-ID: Patches item #490393, was opened at 2001-12-07 12:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490393&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Tim Peters (tim_one) Summary: test___all__ and Jython Initial Comment: Whatever good it does to import _socket, it doesn't make any sense for Jython. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-07 13:23 Message: Logged In: YES user_id=4201 Tradition? No; no reason at all. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 12:57 Message: Logged In: YES user_id=31435 Finn, is there some reason you avoid .startswith() here? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490393&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:32:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:32:51 -0800 Subject: [Patches] [ python-Patches-490402 ] Improper PyMethodObject->im_class fix Message-ID: Patches item #490402, was opened at 2001-12-07 13:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Guido van Rossum (gvanrossum) Summary: Improper PyMethodObject->im_class fix Initial Comment: In wxPython's code for reflecting virtual method calls to Python methods I have code that looks up the method by name and checks the class it comes from. If it's in the base Python shadow class then I just call the base C++ method directly to save time, otherwise I call the Python method. In the Python 2.2 betas I found that the class object returned from PyMethod_GET_CLASS is now the class of the instance, not the class where the method was defined as it was before, and as documented in classobject.h. This causes my code to recurse until the max stack depth is reached, and I've been unable to find a way to work around this change. The differences can be further illustrated by this little Python program: class A: def spam(self): print "spam" class B(A): pass import sys print sys.version b = B() print b.spam print B.spam When run with various version of Python I get this: [C:\temp] p15 method_test.py 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] [C:\temp] p20 method_test.py 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] [C:\temp] p21 method_test.py 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] [C:\temp] p22 method_test.py 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] > Notice the change from "A.spam" to "B.spam" in the final case. Going on the assumption that this is a bug and not intended behaviour, the attached patch fixes this issue as can be seen in this run of the test, but I don't know if there are any other ramifications: [C:\temp] \PROJECTS\Python-cvs\PCbuild\python_d.exe method_test.py Adding parser accelerators ... Done. 2.2b2+ (#26, Dec 7 2001, 11:46:31) [MSC 32 bit (Intel)] > [3306 refs] If this is not a bug then please let me know what the proper way is via the API to find the class that defined a particular method. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:32 Message: Logged In: YES user_id=6380 It's not a bug. This change has acually revealed several bugs in existing code of the following sort: class A: def method(self): ... class B(A): ... # does not override method (yet) class C(A): def method(self): ...do something else... B.method(self) # invoke base class method Note that C doesn't inherit from B, yet the call to B.method(self) succeeded (in prior Python versions), because im_class was set to the defining class instead of the class used in the getattr operation. This kind of bug occurs when the class hierarchy is restructured but not all upcalls are fixed, and is waiting for problems (when B grows its own implementation of method(), C which is unrelated to B suddenly stops working). To find the class that defines a method, for new-style classes you can walk the __mro__ tuple looking in the __dict__ of each class found for the method; for classic classes you have to walk the hierarchy using __bases__. I hope this is not too much of an inconvenience. Let me know if further action is required; I'd like to close this bug report as "Won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 13:15 Message: Logged In: YES user_id=31435 This one's for Guido. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:34:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:34:20 -0800 Subject: [Patches] [ python-Patches-490411 ] Jython and test_grammar.py Message-ID: Patches item #490411, was opened at 2001-12-07 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490411&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Jython and test_grammar.py Initial Comment: The initial patch #468662 was not applied quite verbatim. This should one will fix the remaining issues. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490411&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:36:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:36:45 -0800 Subject: [Patches] [ python-Patches-490393 ] test___all__ and Jython Message-ID: Patches item #490393, was opened at 2001-12-07 12:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490393&group_id=5470 >Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Tim Peters (tim_one) Summary: test___all__ and Jython Initial Comment: Whatever good it does to import _socket, it doesn't make any sense for Jython. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-07 13:36 Message: Logged In: YES user_id=31435 Accepted and applied (after fiddling to use .startswith()), Lib/test/test___all__.py; new revision: 1.22 ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-12-07 13:23 Message: Logged In: YES user_id=4201 Tradition? No; no reason at all. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 12:57 Message: Logged In: YES user_id=31435 Finn, is there some reason you avoid .startswith() here? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490393&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:38:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:38:51 -0800 Subject: [Patches] [ python-Patches-490402 ] Improper PyMethodObject->im_class fix Message-ID: Patches item #490402, was opened at 2001-12-07 13:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Guido van Rossum (gvanrossum) Summary: Improper PyMethodObject->im_class fix Initial Comment: In wxPython's code for reflecting virtual method calls to Python methods I have code that looks up the method by name and checks the class it comes from. If it's in the base Python shadow class then I just call the base C++ method directly to save time, otherwise I call the Python method. In the Python 2.2 betas I found that the class object returned from PyMethod_GET_CLASS is now the class of the instance, not the class where the method was defined as it was before, and as documented in classobject.h. This causes my code to recurse until the max stack depth is reached, and I've been unable to find a way to work around this change. The differences can be further illustrated by this little Python program: class A: def spam(self): print "spam" class B(A): pass import sys print sys.version b = B() print b.spam print B.spam When run with various version of Python I get this: [C:\temp] p15 method_test.py 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] [C:\temp] p20 method_test.py 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] [C:\temp] p21 method_test.py 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] [C:\temp] p22 method_test.py 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] > Notice the change from "A.spam" to "B.spam" in the final case. Going on the assumption that this is a bug and not intended behaviour, the attached patch fixes this issue as can be seen in this run of the test, but I don't know if there are any other ramifications: [C:\temp] \PROJECTS\Python-cvs\PCbuild\python_d.exe method_test.py Adding parser accelerators ... Done. 2.2b2+ (#26, Dec 7 2001, 11:46:31) [MSC 32 bit (Intel)] > [3306 refs] If this is not a bug then please let me know what the proper way is via the API to find the class that defined a particular method. ---------------------------------------------------------------------- >Comment By: Robin Dunn (robind) Date: 2001-12-07 13:38 Message: Logged In: YES user_id=53955 Is there an easy way to do that in the C API? If not, can you give me some hints for how to do it the hard way? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:32 Message: Logged In: YES user_id=6380 It's not a bug. This change has acually revealed several bugs in existing code of the following sort: class A: def method(self): ... class B(A): ... # does not override method (yet) class C(A): def method(self): ...do something else... B.method(self) # invoke base class method Note that C doesn't inherit from B, yet the call to B.method(self) succeeded (in prior Python versions), because im_class was set to the defining class instead of the class used in the getattr operation. This kind of bug occurs when the class hierarchy is restructured but not all upcalls are fixed, and is waiting for problems (when B grows its own implementation of method(), C which is unrelated to B suddenly stops working). To find the class that defines a method, for new-style classes you can walk the __mro__ tuple looking in the __dict__ of each class found for the method; for classic classes you have to walk the hierarchy using __bases__. I hope this is not too much of an inconvenience. Let me know if further action is required; I'd like to close this bug report as "Won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 13:15 Message: Logged In: YES user_id=31435 This one's for Guido. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:40:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:40:14 -0800 Subject: [Patches] [ python-Patches-490414 ] Jython and test_socket Message-ID: Patches item #490414, was opened at 2001-12-07 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490414&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Jython and test_socket Initial Comment: refcounting isn't available in Jython. Put the jython test around it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490414&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:45:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:45:46 -0800 Subject: [Patches] [ python-Patches-490402 ] Improper PyMethodObject->im_class fix Message-ID: Patches item #490402, was opened at 2001-12-07 13:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Guido van Rossum (gvanrossum) Summary: Improper PyMethodObject->im_class fix Initial Comment: In wxPython's code for reflecting virtual method calls to Python methods I have code that looks up the method by name and checks the class it comes from. If it's in the base Python shadow class then I just call the base C++ method directly to save time, otherwise I call the Python method. In the Python 2.2 betas I found that the class object returned from PyMethod_GET_CLASS is now the class of the instance, not the class where the method was defined as it was before, and as documented in classobject.h. This causes my code to recurse until the max stack depth is reached, and I've been unable to find a way to work around this change. The differences can be further illustrated by this little Python program: class A: def spam(self): print "spam" class B(A): pass import sys print sys.version b = B() print b.spam print B.spam When run with various version of Python I get this: [C:\temp] p15 method_test.py 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] [C:\temp] p20 method_test.py 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] [C:\temp] p21 method_test.py 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] [C:\temp] p22 method_test.py 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] > Notice the change from "A.spam" to "B.spam" in the final case. Going on the assumption that this is a bug and not intended behaviour, the attached patch fixes this issue as can be seen in this run of the test, but I don't know if there are any other ramifications: [C:\temp] \PROJECTS\Python-cvs\PCbuild\python_d.exe method_test.py Adding parser accelerators ... Done. 2.2b2+ (#26, Dec 7 2001, 11:46:31) [MSC 32 bit (Intel)] > [3306 refs] If this is not a bug then please let me know what the proper way is via the API to find the class that defined a particular method. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:45 Message: Logged In: YES user_id=6380 I haven't had the need to do this elsewhere, so there's no C API. To do it for new-style classes, look at the implementation of _PyType_Lookup() in typeobject.c; at the point where it returns res, the defining class is base. (Please look at the current CVS or at least 2.2b2; there's a new special case in the code to allow classic classes in the MRO of a new-style class.) For classic classes, you can copy class_lookup() from classobject.c. ---------------------------------------------------------------------- Comment By: Robin Dunn (robind) Date: 2001-12-07 13:38 Message: Logged In: YES user_id=53955 Is there an easy way to do that in the C API? If not, can you give me some hints for how to do it the hard way? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:32 Message: Logged In: YES user_id=6380 It's not a bug. This change has acually revealed several bugs in existing code of the following sort: class A: def method(self): ... class B(A): ... # does not override method (yet) class C(A): def method(self): ...do something else... B.method(self) # invoke base class method Note that C doesn't inherit from B, yet the call to B.method(self) succeeded (in prior Python versions), because im_class was set to the defining class instead of the class used in the getattr operation. This kind of bug occurs when the class hierarchy is restructured but not all upcalls are fixed, and is waiting for problems (when B grows its own implementation of method(), C which is unrelated to B suddenly stops working). To find the class that defines a method, for new-style classes you can walk the __mro__ tuple looking in the __dict__ of each class found for the method; for classic classes you have to walk the hierarchy using __bases__. I hope this is not too much of an inconvenience. Let me know if further action is required; I'd like to close this bug report as "Won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 13:15 Message: Logged In: YES user_id=31435 This one's for Guido. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:49:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:49:32 -0800 Subject: [Patches] [ python-Patches-490402 ] Improper PyMethodObject->im_class fix Message-ID: Patches item #490402, was opened at 2001-12-07 13:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Guido van Rossum (gvanrossum) Summary: Improper PyMethodObject->im_class fix Initial Comment: In wxPython's code for reflecting virtual method calls to Python methods I have code that looks up the method by name and checks the class it comes from. If it's in the base Python shadow class then I just call the base C++ method directly to save time, otherwise I call the Python method. In the Python 2.2 betas I found that the class object returned from PyMethod_GET_CLASS is now the class of the instance, not the class where the method was defined as it was before, and as documented in classobject.h. This causes my code to recurse until the max stack depth is reached, and I've been unable to find a way to work around this change. The differences can be further illustrated by this little Python program: class A: def spam(self): print "spam" class B(A): pass import sys print sys.version b = B() print b.spam print B.spam When run with various version of Python I get this: [C:\temp] p15 method_test.py 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] [C:\temp] p20 method_test.py 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] [C:\temp] p21 method_test.py 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] [C:\temp] p22 method_test.py 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] > Notice the change from "A.spam" to "B.spam" in the final case. Going on the assumption that this is a bug and not intended behaviour, the attached patch fixes this issue as can be seen in this run of the test, but I don't know if there are any other ramifications: [C:\temp] \PROJECTS\Python-cvs\PCbuild\python_d.exe method_test.py Adding parser accelerators ... Done. 2.2b2+ (#26, Dec 7 2001, 11:46:31) [MSC 32 bit (Intel)] > [3306 refs] If this is not a bug then please let me know what the proper way is via the API to find the class that defined a particular method. ---------------------------------------------------------------------- >Comment By: Robin Dunn (robind) Date: 2001-12-07 13:49 Message: Logged In: YES user_id=53955 Thanks. BTW, the comment on line 34 of classobject.h (about im_class) should probably be changed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:45 Message: Logged In: YES user_id=6380 I haven't had the need to do this elsewhere, so there's no C API. To do it for new-style classes, look at the implementation of _PyType_Lookup() in typeobject.c; at the point where it returns res, the defining class is base. (Please look at the current CVS or at least 2.2b2; there's a new special case in the code to allow classic classes in the MRO of a new-style class.) For classic classes, you can copy class_lookup() from classobject.c. ---------------------------------------------------------------------- Comment By: Robin Dunn (robind) Date: 2001-12-07 13:38 Message: Logged In: YES user_id=53955 Is there an easy way to do that in the C API? If not, can you give me some hints for how to do it the hard way? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:32 Message: Logged In: YES user_id=6380 It's not a bug. This change has acually revealed several bugs in existing code of the following sort: class A: def method(self): ... class B(A): ... # does not override method (yet) class C(A): def method(self): ...do something else... B.method(self) # invoke base class method Note that C doesn't inherit from B, yet the call to B.method(self) succeeded (in prior Python versions), because im_class was set to the defining class instead of the class used in the getattr operation. This kind of bug occurs when the class hierarchy is restructured but not all upcalls are fixed, and is waiting for problems (when B grows its own implementation of method(), C which is unrelated to B suddenly stops working). To find the class that defines a method, for new-style classes you can walk the __mro__ tuple looking in the __dict__ of each class found for the method; for classic classes you have to walk the hierarchy using __bases__. I hope this is not too much of an inconvenience. Let me know if further action is required; I'd like to close this bug report as "Won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 13:15 Message: Logged In: YES user_id=31435 This one's for Guido. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:50:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:50:33 -0800 Subject: [Patches] [ python-Patches-490417 ] Jython and test_exceptions Message-ID: Patches item #490417, was opened at 2001-12-07 13:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490417&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Jython and test_exceptions Initial Comment: Two issues in this patch: 1. Acknowledge the welknown difference that jython allows continue in the finally clause. 2. Avoid using _testcapi when running with jython. FWIW, you only have to accept the patches. I don't mind doing the actual commit myself. After all, I have it applied to a my version already. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490417&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:54:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:54:58 -0800 Subject: [Patches] [ python-Patches-490402 ] Improper PyMethodObject->im_class fix Message-ID: Patches item #490402, was opened at 2001-12-07 13:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Guido van Rossum (gvanrossum) Summary: Improper PyMethodObject->im_class fix Initial Comment: In wxPython's code for reflecting virtual method calls to Python methods I have code that looks up the method by name and checks the class it comes from. If it's in the base Python shadow class then I just call the base C++ method directly to save time, otherwise I call the Python method. In the Python 2.2 betas I found that the class object returned from PyMethod_GET_CLASS is now the class of the instance, not the class where the method was defined as it was before, and as documented in classobject.h. This causes my code to recurse until the max stack depth is reached, and I've been unable to find a way to work around this change. The differences can be further illustrated by this little Python program: class A: def spam(self): print "spam" class B(A): pass import sys print sys.version b = B() print b.spam print B.spam When run with various version of Python I get this: [C:\temp] p15 method_test.py 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] [C:\temp] p20 method_test.py 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] [C:\temp] p21 method_test.py 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] [C:\temp] p22 method_test.py 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] > Notice the change from "A.spam" to "B.spam" in the final case. Going on the assumption that this is a bug and not intended behaviour, the attached patch fixes this issue as can be seen in this run of the test, but I don't know if there are any other ramifications: [C:\temp] \PROJECTS\Python-cvs\PCbuild\python_d.exe method_test.py Adding parser accelerators ... Done. 2.2b2+ (#26, Dec 7 2001, 11:46:31) [MSC 32 bit (Intel)] > [3306 refs] If this is not a bug then please let me know what the proper way is via the API to find the class that defined a particular method. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:54 Message: Logged In: YES user_id=6380 You're right. Fixed in CVS. ---------------------------------------------------------------------- Comment By: Robin Dunn (robind) Date: 2001-12-07 13:49 Message: Logged In: YES user_id=53955 Thanks. BTW, the comment on line 34 of classobject.h (about im_class) should probably be changed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:45 Message: Logged In: YES user_id=6380 I haven't had the need to do this elsewhere, so there's no C API. To do it for new-style classes, look at the implementation of _PyType_Lookup() in typeobject.c; at the point where it returns res, the defining class is base. (Please look at the current CVS or at least 2.2b2; there's a new special case in the code to allow classic classes in the MRO of a new-style class.) For classic classes, you can copy class_lookup() from classobject.c. ---------------------------------------------------------------------- Comment By: Robin Dunn (robind) Date: 2001-12-07 13:38 Message: Logged In: YES user_id=53955 Is there an easy way to do that in the C API? If not, can you give me some hints for how to do it the hard way? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:32 Message: Logged In: YES user_id=6380 It's not a bug. This change has acually revealed several bugs in existing code of the following sort: class A: def method(self): ... class B(A): ... # does not override method (yet) class C(A): def method(self): ...do something else... B.method(self) # invoke base class method Note that C doesn't inherit from B, yet the call to B.method(self) succeeded (in prior Python versions), because im_class was set to the defining class instead of the class used in the getattr operation. This kind of bug occurs when the class hierarchy is restructured but not all upcalls are fixed, and is waiting for problems (when B grows its own implementation of method(), C which is unrelated to B suddenly stops working). To find the class that defines a method, for new-style classes you can walk the __mro__ tuple looking in the __dict__ of each class found for the method; for classic classes you have to walk the hierarchy using __bases__. I hope this is not too much of an inconvenience. Let me know if further action is required; I'd like to close this bug report as "Won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 13:15 Message: Logged In: YES user_id=31435 This one's for Guido. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 From noreply@sourceforge.net Fri Dec 7 22:06:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 14:06:26 -0800 Subject: [Patches] [ python-Patches-490417 ] Jython and test_exceptions Message-ID: Patches item #490417, was opened at 2001-12-07 13:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490417&group_id=5470 >Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: Jython and test_exceptions Initial Comment: Two issues in this patch: 1. Acknowledge the welknown difference that jython allows continue in the finally clause. 2. Avoid using _testcapi when running with jython. FWIW, you only have to accept the patches. I don't mind doing the actual commit myself. After all, I have it applied to a my version already. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 14:06 Message: Logged In: YES user_id=6380 Fine with me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490417&group_id=5470 From noreply@sourceforge.net Fri Dec 7 22:07:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 14:07:14 -0800 Subject: [Patches] [ python-Patches-490402 ] Improper PyMethodObject->im_class fix Message-ID: Patches item #490402, was opened at 2001-12-07 13:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Guido van Rossum (gvanrossum) Summary: Improper PyMethodObject->im_class fix Initial Comment: In wxPython's code for reflecting virtual method calls to Python methods I have code that looks up the method by name and checks the class it comes from. If it's in the base Python shadow class then I just call the base C++ method directly to save time, otherwise I call the Python method. In the Python 2.2 betas I found that the class object returned from PyMethod_GET_CLASS is now the class of the instance, not the class where the method was defined as it was before, and as documented in classobject.h. This causes my code to recurse until the max stack depth is reached, and I've been unable to find a way to work around this change. The differences can be further illustrated by this little Python program: class A: def spam(self): print "spam" class B(A): pass import sys print sys.version b = B() print b.spam print B.spam When run with various version of Python I get this: [C:\temp] p15 method_test.py 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] [C:\temp] p20 method_test.py 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] [C:\temp] p21 method_test.py 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] [C:\temp] p22 method_test.py 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] > Notice the change from "A.spam" to "B.spam" in the final case. Going on the assumption that this is a bug and not intended behaviour, the attached patch fixes this issue as can be seen in this run of the test, but I don't know if there are any other ramifications: [C:\temp] \PROJECTS\Python-cvs\PCbuild\python_d.exe method_test.py Adding parser accelerators ... Done. 2.2b2+ (#26, Dec 7 2001, 11:46:31) [MSC 32 bit (Intel)] > [3306 refs] If this is not a bug then please let me know what the proper way is via the API to find the class that defined a particular method. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 14:07 Message: Logged In: YES user_id=6380 I grepped the docs for im_class and corrected those too in CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:54 Message: Logged In: YES user_id=6380 You're right. Fixed in CVS. ---------------------------------------------------------------------- Comment By: Robin Dunn (robind) Date: 2001-12-07 13:49 Message: Logged In: YES user_id=53955 Thanks. BTW, the comment on line 34 of classobject.h (about im_class) should probably be changed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:45 Message: Logged In: YES user_id=6380 I haven't had the need to do this elsewhere, so there's no C API. To do it for new-style classes, look at the implementation of _PyType_Lookup() in typeobject.c; at the point where it returns res, the defining class is base. (Please look at the current CVS or at least 2.2b2; there's a new special case in the code to allow classic classes in the MRO of a new-style class.) For classic classes, you can copy class_lookup() from classobject.c. ---------------------------------------------------------------------- Comment By: Robin Dunn (robind) Date: 2001-12-07 13:38 Message: Logged In: YES user_id=53955 Is there an easy way to do that in the C API? If not, can you give me some hints for how to do it the hard way? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:32 Message: Logged In: YES user_id=6380 It's not a bug. This change has acually revealed several bugs in existing code of the following sort: class A: def method(self): ... class B(A): ... # does not override method (yet) class C(A): def method(self): ...do something else... B.method(self) # invoke base class method Note that C doesn't inherit from B, yet the call to B.method(self) succeeded (in prior Python versions), because im_class was set to the defining class instead of the class used in the getattr operation. This kind of bug occurs when the class hierarchy is restructured but not all upcalls are fixed, and is waiting for problems (when B grows its own implementation of method(), C which is unrelated to B suddenly stops working). To find the class that defines a method, for new-style classes you can walk the __mro__ tuple looking in the __dict__ of each class found for the method; for classic classes you have to walk the hierarchy using __bases__. I hope this is not too much of an inconvenience. Let me know if further action is required; I'd like to close this bug report as "Won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 13:15 Message: Logged In: YES user_id=31435 This one's for Guido. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470 From noreply@sourceforge.net Fri Dec 7 23:11:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 15:11:56 -0800 Subject: [Patches] [ python-Patches-490456 ] Unicode support in email.Utils.encode Message-ID: Patches item #490456, was opened at 2001-12-07 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490456&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode support in email.Utils.encode Initial Comment: It's essentially an updated patch 486375, this time making a distinction of type for the passed string; if it's Unicode, the function encodes it to the character set specified as the charset parameter. The reasons: 1. The function in its current version doesn't support Unicode, throwing an exception if any non-ASCII characters are found within it. 2. With this patch, we reach a sort of operational symmetry on email.Utils.encode vs email.Utils.decode, as it can be seen in the tests. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490456&group_id=5470 From noreply@sourceforge.net Sat Dec 8 03:50:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 19:50:05 -0800 Subject: [Patches] [ python-Patches-490515 ] urllib.open_https() protocol issue Message-ID: Patches item #490515, was opened at 2001-12-07 19:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490515&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joe A (joefefifo) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.open_https() protocol issue Initial Comment: This patch was made for Python version 2.2, using a daily snapshot, python-20011207.tar.gz. I'm running Red Hat Linux 7.2. In urllib.py library module, URLopener.open_https() returns a class instance of addinfourl() with its self.url property missing the protocol. Instead of "https://www.someurl.com", it becomes "://www.someurl.com". This happens because the variable "url" used in the argument of the call to addinfourl() only represents the part of the url other than the protocol. In line 376 of urllib.py, instead of: 376: return addinfourl(fp, headers, url) It should read: 376: return addinfourl(fp, headers, "https:" + url) You can see that in URLopener.open_http() this is already the case: 298: return addinfourl(fp, headers, "http:" + url) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490515&group_id=5470 From noreply@sourceforge.net Sat Dec 8 10:16:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 02:16:46 -0800 Subject: [Patches] [ python-Patches-490417 ] Jython and test_exceptions Message-ID: Patches item #490417, was opened at 2001-12-07 13:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490417&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Jython and test_exceptions Initial Comment: Two issues in this patch: 1. Acknowledge the welknown difference that jython allows continue in the finally clause. 2. Avoid using _testcapi when running with jython. FWIW, you only have to accept the patches. I don't mind doing the actual commit myself. After all, I have it applied to a my version already. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-08 02:16 Message: Logged In: YES user_id=4201 Applied to test_exceptions.py: 1.16; ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 14:06 Message: Logged In: YES user_id=6380 Fine with me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490417&group_id=5470 From noreply@sourceforge.net Sat Dec 8 17:09:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 09:09:28 -0800 Subject: [Patches] [ python-Patches-490515 ] urllib.open_https() protocol issue Message-ID: Patches item #490515, was opened at 2001-12-07 19:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490515&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Joe A (joefefifo) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.open_https() protocol issue Initial Comment: This patch was made for Python version 2.2, using a daily snapshot, python-20011207.tar.gz. I'm running Red Hat Linux 7.2. In urllib.py library module, URLopener.open_https() returns a class instance of addinfourl() with its self.url property missing the protocol. Instead of "https://www.someurl.com", it becomes "://www.someurl.com". This happens because the variable "url" used in the argument of the call to addinfourl() only represents the part of the url other than the protocol. In line 376 of urllib.py, instead of: 376: return addinfourl(fp, headers, url) It should read: 376: return addinfourl(fp, headers, "https:" + url) You can see that in URLopener.open_http() this is already the case: 298: return addinfourl(fp, headers, "http:" + url) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:09 Message: Logged In: YES user_id=6380 Thanks! Fixed in CVS rev. 1.135. What's your full name (for the ACKS file)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490515&group_id=5470 From noreply@sourceforge.net Sat Dec 8 17:10:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 09:10:35 -0800 Subject: [Patches] [ python-Patches-490414 ] Jython and test_socket Message-ID: Patches item #490414, was opened at 2001-12-07 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490414&group_id=5470 >Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: Jython and test_socket Initial Comment: refcounting isn't available in Jython. Put the jython test around it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:10 Message: Logged In: YES user_id=6380 Sure, check it in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490414&group_id=5470 From noreply@sourceforge.net Sat Dec 8 17:11:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 09:11:10 -0800 Subject: [Patches] [ python-Patches-490411 ] Jython and test_grammar.py Message-ID: Patches item #490411, was opened at 2001-12-07 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490411&group_id=5470 >Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: Jython and test_grammar.py Initial Comment: The initial patch #468662 was not applied quite verbatim. This should one will fix the remaining issues. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:11 Message: Logged In: YES user_id=6380 Go for it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490411&group_id=5470 From noreply@sourceforge.net Sat Dec 8 17:14:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 09:14:08 -0800 Subject: [Patches] [ python-Patches-489989 ] linuxaudiodev.c - fix initialization Message-ID: Patches item #489989, was opened at 2001-12-06 12:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489989&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Charles G Waldman (cgw) >Assigned to: Guido van Rossum (gvanrossum) Summary: linuxaudiodev.c - fix initialization Initial Comment: The OSS Programmer's Reference (www.4front-tech.com) states: *Setting Sampling Parameters There are three parameters which affect the sound quality (and therefore memory and bandwidth requirements) of sampled audio data. These are: ** sample format (sometimes called number of bits) ** number of channels (mono or stereo), and ** sampling rate (speed) NOTE: It is important to always set these parameters in the above order. Setting sampling rate before the number of channels doesn't work with all devices. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:14 Message: Logged In: YES user_id=6380 Thanks! And welcome back. Fixed in CVS, rev 2.15. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489989&group_id=5470 From noreply@sourceforge.net Sat Dec 8 17:15:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 09:15:37 -0800 Subject: [Patches] [ python-Patches-490026 ] Namespace selection for rlcompleter Message-ID: Patches item #490026, was opened at 2001-12-06 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Namespace selection for rlcompleter Initial Comment: The standard rlcompleter is hardwired to work with __main__.__dict__. This is limiting, as one may have applications which execute in specially constructed 'sandboxed' namespaces. This patch extends rlcompleter with a constructor which provides an optional namespace specifier. This optional parameter defaults to __main__.__dict__, so the patch is 100% backwards compatible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:15 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 From noreply@sourceforge.net Sat Dec 8 18:39:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 10:39:52 -0800 Subject: [Patches] [ python-Patches-490026 ] Namespace selection for rlcompleter Message-ID: Patches item #490026, was opened at 2001-12-06 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Namespace selection for rlcompleter Initial Comment: The standard rlcompleter is hardwired to work with __main__.__dict__. This is limiting, as one may have applications which execute in specially constructed 'sandboxed' namespaces. This patch extends rlcompleter with a constructor which provides an optional namespace specifier. This optional parameter defaults to __main__.__dict__, so the patch is 100% backwards compatible. ---------------------------------------------------------------------- >Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 10:39 Message: Logged In: YES user_id=395388 Oops, sorry. You can tell I've never used the system before. I put the file in, but I just didn't see the stupid extra checkbox. Lack of orthogonality in an interface is always a recipe for problems. Anyway, it should be ok now. Cheers, Fernando. PS. And the obvious, *THANKS* a lot for putting such a fantastic tool out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:15 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 From noreply@sourceforge.net Sun Dec 9 01:38:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 17:38:33 -0800 Subject: [Patches] [ python-Patches-490026 ] Namespace selection for rlcompleter Message-ID: Patches item #490026, was opened at 2001-12-06 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Namespace selection for rlcompleter Initial Comment: The standard rlcompleter is hardwired to work with __main__.__dict__. This is limiting, as one may have applications which execute in specially constructed 'sandboxed' namespaces. This patch extends rlcompleter with a constructor which provides an optional namespace specifier. This optional parameter defaults to __main__.__dict__, so the patch is 100% backwards compatible. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 17:38 Message: Logged In: YES user_id=6380 Since this is obviously a new feature, I'll postpone this until after 2.2. One thing that worries me: you capture the identity of __main__.__dict__ early on in this patch. The original code uses whatever __main__.__dict__ at the time it is needed. ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 10:39 Message: Logged In: YES user_id=395388 Oops, sorry. You can tell I've never used the system before. I put the file in, but I just didn't see the stupid extra checkbox. Lack of orthogonality in an interface is always a recipe for problems. Anyway, it should be ok now. Cheers, Fernando. PS. And the obvious, *THANKS* a lot for putting such a fantastic tool out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:15 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 From noreply@sourceforge.net Sun Dec 9 02:42:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 18:42:22 -0800 Subject: [Patches] [ python-Patches-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Patches item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-08 18:42 Message: Logged In: YES user_id=21784 Looks like I've found the problem: line 244 in misc/extract.c is currently this: for (i = 0; *scheme[i].name; ++i) { The scheme list is terminated by a NULL, so *NULL causes an exception at the end of the list. Instead this should be: for (i = 0; scheme[i].name; ++i) { ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 12:55 Message: Logged In: YES user_id=11375 Reassigning to Thomas Heller; I know nothing about bdist_wininst. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 From noreply@sourceforge.net Sun Dec 9 02:53:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 18:53:25 -0800 Subject: [Patches] [ python-Patches-490026 ] Namespace selection for rlcompleter Message-ID: Patches item #490026, was opened at 2001-12-06 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Namespace selection for rlcompleter Initial Comment: The standard rlcompleter is hardwired to work with __main__.__dict__. This is limiting, as one may have applications which execute in specially constructed 'sandboxed' namespaces. This patch extends rlcompleter with a constructor which provides an optional namespace specifier. This optional parameter defaults to __main__.__dict__, so the patch is 100% backwards compatible. ---------------------------------------------------------------------- >Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 18:53 Message: Logged In: YES user_id=395388 I could rewrite it to use instead a namespace=None in the constructor. If a namespace is given it will be used, otherwise at completion time a check will be made: if self.namespace is None: self.namespace=__main__.__dict__ This means an extra if in the completer, but would address your concern. Do you want me to do that? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 17:38 Message: Logged In: YES user_id=6380 Since this is obviously a new feature, I'll postpone this until after 2.2. One thing that worries me: you capture the identity of __main__.__dict__ early on in this patch. The original code uses whatever __main__.__dict__ at the time it is needed. ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 10:39 Message: Logged In: YES user_id=395388 Oops, sorry. You can tell I've never used the system before. I put the file in, but I just didn't see the stupid extra checkbox. Lack of orthogonality in an interface is always a recipe for problems. Anyway, it should be ok now. Cheers, Fernando. PS. And the obvious, *THANKS* a lot for putting such a fantastic tool out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:15 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 From noreply@sourceforge.net Sun Dec 9 03:32:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 19:32:05 -0800 Subject: [Patches] [ python-Patches-490026 ] Namespace selection for rlcompleter Message-ID: Patches item #490026, was opened at 2001-12-06 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Namespace selection for rlcompleter Initial Comment: The standard rlcompleter is hardwired to work with __main__.__dict__. This is limiting, as one may have applications which execute in specially constructed 'sandboxed' namespaces. This patch extends rlcompleter with a constructor which provides an optional namespace specifier. This optional parameter defaults to __main__.__dict__, so the patch is 100% backwards compatible. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 19:32 Message: Logged In: YES user_id=6380 Yes, that's about right. ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 18:53 Message: Logged In: YES user_id=395388 I could rewrite it to use instead a namespace=None in the constructor. If a namespace is given it will be used, otherwise at completion time a check will be made: if self.namespace is None: self.namespace=__main__.__dict__ This means an extra if in the completer, but would address your concern. Do you want me to do that? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 17:38 Message: Logged In: YES user_id=6380 Since this is obviously a new feature, I'll postpone this until after 2.2. One thing that worries me: you capture the identity of __main__.__dict__ early on in this patch. The original code uses whatever __main__.__dict__ at the time it is needed. ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 10:39 Message: Logged In: YES user_id=395388 Oops, sorry. You can tell I've never used the system before. I put the file in, but I just didn't see the stupid extra checkbox. Lack of orthogonality in an interface is always a recipe for problems. Anyway, it should be ok now. Cheers, Fernando. PS. And the obvious, *THANKS* a lot for putting such a fantastic tool out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:15 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 From noreply@sourceforge.net Sun Dec 9 06:52:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 22:52:12 -0800 Subject: [Patches] [ python-Patches-485959 ] Final set of patches to Demo/tix Message-ID: Patches item #485959, was opened at 2001-11-27 03:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Martin v. Löwis (loewis) Summary: Final set of patches to Demo/tix Initial Comment: Final set of patches to Demo/tix - this should be it for a while. Tix.py: Fixed tix_configure and fixed some of the doc strings. tixwidgets.py: fixed loop, added some more docstrings, and made some progress on the global image1 problem. Look for the code around 'if 0:' - it may point towards a bug in Tkinter. Image class. Also if I can understand this proble, maybe I can solve the long outstanding bug described in Demo/tix/BUG.txt. samples/ Fixed SHList1 and 2 not quiting when run from samples/ and fixed a bug in all of the demos that was leaving zombie pythonw processes under Windows in 2.1.0 ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-12-08 22:52 Message: Logged In: YES user_id=33229 Are the reject significant or just spurious linefeeds at the end of the file? Please apply the patches of the files that run cleanly as the patches are all independent and are all against the current files. The Tix.py and tixiwdgets.py contain important bug fixes. Let me know if the rejects are signiifcant; I don't always have access to unix cvs, and the SF CVS download option under Windows adds spurious linefeeds at the end. That's why I add the .dst files to the tar so you can see if any rejects are trivial. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 04:35 Message: Logged In: YES user_id=21627 These patches don't apply cleanly; I get patch rejects in Control.py.rej SHList1.py.rej SHList2.py.rej Please obtain the current version through CVS, and produce a 'cvs diff -u', instead of individual diff files. We only need the diffs; the original files aren't needed (so you don't need to produce a tar file, either). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 From noreply@sourceforge.net Sun Dec 9 07:16:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 23:16:55 -0800 Subject: [Patches] [ python-Patches-490026 ] Namespace selection for rlcompleter Message-ID: Patches item #490026, was opened at 2001-12-06 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Namespace selection for rlcompleter Initial Comment: The standard rlcompleter is hardwired to work with __main__.__dict__. This is limiting, as one may have applications which execute in specially constructed 'sandboxed' namespaces. This patch extends rlcompleter with a constructor which provides an optional namespace specifier. This optional parameter defaults to __main__.__dict__, so the patch is 100% backwards compatible. ---------------------------------------------------------------------- >Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 23:16 Message: Logged In: YES user_id=395388 I've uploaded a new version of the patch with those changes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 19:32 Message: Logged In: YES user_id=6380 Yes, that's about right. ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 18:53 Message: Logged In: YES user_id=395388 I could rewrite it to use instead a namespace=None in the constructor. If a namespace is given it will be used, otherwise at completion time a check will be made: if self.namespace is None: self.namespace=__main__.__dict__ This means an extra if in the completer, but would address your concern. Do you want me to do that? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 17:38 Message: Logged In: YES user_id=6380 Since this is obviously a new feature, I'll postpone this until after 2.2. One thing that worries me: you capture the identity of __main__.__dict__ early on in this patch. The original code uses whatever __main__.__dict__ at the time it is needed. ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 10:39 Message: Logged In: YES user_id=395388 Oops, sorry. You can tell I've never used the system before. I put the file in, but I just didn't see the stupid extra checkbox. Lack of orthogonality in an interface is always a recipe for problems. Anyway, it should be ok now. Cheers, Fernando. PS. And the obvious, *THANKS* a lot for putting such a fantastic tool out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:15 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 From noreply@sourceforge.net Sun Dec 9 08:58:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 00:58:40 -0800 Subject: [Patches] [ python-Patches-490414 ] Jython and test_socket Message-ID: Patches item #490414, was opened at 2001-12-07 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490414&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Jython and test_socket Initial Comment: refcounting isn't available in Jython. Put the jython test around it. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-09 00:58 Message: Logged In: YES user_id=4201 Applied to test_socket.py: 1.23; ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:10 Message: Logged In: YES user_id=6380 Sure, check it in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490414&group_id=5470 From noreply@sourceforge.net Sun Dec 9 09:12:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 01:12:58 -0800 Subject: [Patches] [ python-Patches-490411 ] Jython and test_grammar.py Message-ID: Patches item #490411, was opened at 2001-12-07 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490411&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Jython and test_grammar.py Initial Comment: The initial patch #468662 was not applied quite verbatim. This should one will fix the remaining issues. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-09 01:12 Message: Logged In: YES user_id=4201 Applied to test_grammar.py: 1.40; ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:11 Message: Logged In: YES user_id=6380 Go for it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490411&group_id=5470 From noreply@sourceforge.net Sun Dec 9 12:04:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 04:04:21 -0800 Subject: [Patches] [ python-Patches-490811 ] Jython and test_string Message-ID: Patches item #490811, was opened at 2001-12-09 04:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490811&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Jython and test_string Initial Comment: If neither a method or a string module function exists, test_string.py will throw an ugly UnboundLocalError: local: 'f' exception at the print statement. This patch will fix the UnboundLocalError and write the real reason for the error to the log. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490811&group_id=5470 From noreply@sourceforge.net Sun Dec 9 14:21:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 06:21:00 -0800 Subject: [Patches] [ python-Patches-490811 ] Jython and test_string Message-ID: Patches item #490811, was opened at 2001-12-09 04:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490811&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: Jython and test_string Initial Comment: If neither a method or a string module function exists, test_string.py will throw an ugly UnboundLocalError: local: 'f' exception at the print statement. This patch will fix the UnboundLocalError and write the real reason for the error to the log. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 06:21 Message: Logged In: YES user_id=6380 Go! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490811&group_id=5470 From noreply@sourceforge.net Sun Dec 9 16:06:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 08:06:50 -0800 Subject: [Patches] [ python-Patches-490811 ] Jython and test_string Message-ID: Patches item #490811, was opened at 2001-12-09 04:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490811&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Jython and test_string Initial Comment: If neither a method or a string module function exists, test_string.py will throw an ugly UnboundLocalError: local: 'f' exception at the print statement. This patch will fix the UnboundLocalError and write the real reason for the error to the log. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-09 08:06 Message: Logged In: YES user_id=4201 Applied to test_string.py: 1.15; ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 06:21 Message: Logged In: YES user_id=6380 Go! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490811&group_id=5470 From noreply@sourceforge.net Sun Dec 9 16:11:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 08:11:44 -0800 Subject: [Patches] [ python-Patches-490850 ] Jython and test_StringIO Message-ID: Patches item #490850, was opened at 2001-12-09 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Jython and test_StringIO Initial Comment: A hackish workaround for the missing buffer() object in jython. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 From noreply@sourceforge.net Sun Dec 9 17:48:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 09:48:00 -0800 Subject: [Patches] [ python-Patches-485959 ] Final set of patches to Demo/tix Message-ID: Patches item #485959, was opened at 2001-11-27 03:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Martin v. Löwis (loewis) Summary: Final set of patches to Demo/tix Initial Comment: Final set of patches to Demo/tix - this should be it for a while. Tix.py: Fixed tix_configure and fixed some of the doc strings. tixwidgets.py: fixed loop, added some more docstrings, and made some progress on the global image1 problem. Look for the code around 'if 0:' - it may point towards a bug in Tkinter. Image class. Also if I can understand this proble, maybe I can solve the long outstanding bug described in Demo/tix/BUG.txt. samples/ Fixed SHList1 and 2 not quiting when run from samples/ and fixed a bug in all of the demos that was leaving zombie pythonw processes under Windows in 2.1.0 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-09 09:48 Message: Logged In: YES user_id=21627 I don't think I can find the time to look at this once more before 2.2 - it was already quite time-consuming the last time. I would apply a patch in the last minute with little inspection if it applies cleanly. As for the nature of the problems: I believe for atleast one of the files, the modified file was CRLF converted, so I can't use the file you provided, either. I recommend that you obtain a copy of cvs.exe for Windows, so that you don't have to use a web browser to download the files, and produce a diff. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-12-08 22:52 Message: Logged In: YES user_id=33229 Are the reject significant or just spurious linefeeds at the end of the file? Please apply the patches of the files that run cleanly as the patches are all independent and are all against the current files. The Tix.py and tixiwdgets.py contain important bug fixes. Let me know if the rejects are signiifcant; I don't always have access to unix cvs, and the SF CVS download option under Windows adds spurious linefeeds at the end. That's why I add the .dst files to the tar so you can see if any rejects are trivial. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 04:35 Message: Logged In: YES user_id=21627 These patches don't apply cleanly; I get patch rejects in Control.py.rej SHList1.py.rej SHList2.py.rej Please obtain the current version through CVS, and produce a 'cvs diff -u', instead of individual diff files. We only need the diffs; the original files aren't needed (so you don't need to produce a tar file, either). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 From noreply@sourceforge.net Sun Dec 9 19:14:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 11:14:11 -0800 Subject: [Patches] [ python-Patches-490850 ] Jython and test_StringIO Message-ID: Patches item #490850, was opened at 2001-12-09 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: Jython and test_StringIO Initial Comment: A hackish workaround for the missing buffer() object in jython. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 11:14 Message: Logged In: YES user_id=6380 Sure. I'm not saying I don't enjoy this reviewing, but why don't you just check these things in? I presume you have a CVS checkout of the C code so you can make sure that the tests still succeed after your patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 From noreply@sourceforge.net Sun Dec 9 20:04:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 12:04:07 -0800 Subject: [Patches] [ python-Patches-490850 ] Jython and test_StringIO Message-ID: Patches item #490850, was opened at 2001-12-09 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Jython and test_StringIO Initial Comment: A hackish workaround for the missing buffer() object in jython. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-09 12:04 Message: Logged In: YES user_id=4201 I lost my version of MSVC so I can only test my changes with the latest released binary version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 11:14 Message: Logged In: YES user_id=6380 Sure. I'm not saying I don't enjoy this reviewing, but why don't you just check these things in? I presume you have a CVS checkout of the C code so you can make sure that the tests still succeed after your patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 From noreply@sourceforge.net Sun Dec 9 20:05:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 12:05:54 -0800 Subject: [Patches] [ python-Patches-490850 ] Jython and test_StringIO Message-ID: Patches item #490850, was opened at 2001-12-09 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Jython and test_StringIO Initial Comment: A hackish workaround for the missing buffer() object in jython. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 12:05 Message: Logged In: YES user_id=6380 Oops. OK, I see your problem. :-) Please continue as before... ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-12-09 12:04 Message: Logged In: YES user_id=4201 I lost my version of MSVC so I can only test my changes with the latest released binary version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 11:14 Message: Logged In: YES user_id=6380 Sure. I'm not saying I don't enjoy this reviewing, but why don't you just check these things in? I presume you have a CVS checkout of the C code so you can make sure that the tests still succeed after your patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 From noreply@sourceforge.net Sun Dec 9 20:06:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 12:06:55 -0800 Subject: [Patches] [ python-Patches-490850 ] Jython and test_StringIO Message-ID: Patches item #490850, was opened at 2001-12-09 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Jython and test_StringIO Initial Comment: A hackish workaround for the missing buffer() object in jython. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-09 12:06 Message: Logged In: YES user_id=4201 Applied to test_StringIO.py: 1.10; ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 12:05 Message: Logged In: YES user_id=6380 Oops. OK, I see your problem. :-) Please continue as before... ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-12-09 12:04 Message: Logged In: YES user_id=4201 I lost my version of MSVC so I can only test my changes with the latest released binary version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 11:14 Message: Logged In: YES user_id=6380 Sure. I'm not saying I don't enjoy this reviewing, but why don't you just check these things in? I presume you have a CVS checkout of the C code so you can make sure that the tests still succeed after your patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 From noreply@sourceforge.net Sun Dec 9 20:08:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 12:08:22 -0800 Subject: [Patches] [ python-Patches-490850 ] Jython and test_StringIO Message-ID: Patches item #490850, was opened at 2001-12-09 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Jython and test_StringIO Initial Comment: A hackish workaround for the missing buffer() object in jython. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-09 12:08 Message: Logged In: YES user_id=4201 And close... ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-12-09 12:06 Message: Logged In: YES user_id=4201 Applied to test_StringIO.py: 1.10; ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 12:05 Message: Logged In: YES user_id=6380 Oops. OK, I see your problem. :-) Please continue as before... ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-12-09 12:04 Message: Logged In: YES user_id=4201 I lost my version of MSVC so I can only test my changes with the latest released binary version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 11:14 Message: Logged In: YES user_id=6380 Sure. I'm not saying I don't enjoy this reviewing, but why don't you just check these things in? I presume you have a CVS checkout of the C code so you can make sure that the tests still succeed after your patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490850&group_id=5470 From noreply@sourceforge.net Sun Dec 9 20:23:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 12:23:21 -0800 Subject: [Patches] [ python-Patches-490920 ] Jython and test_unicode Message-ID: Patches item #490920, was opened at 2001-12-09 12:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Jython and test_unicode Initial Comment: Skipping some tests by adding the usual jython conditional test around: - the repr of unicode. Jython only add the u'' if the string contains char values > 255. - A unicode arg to unicode() is perfectly valid in jython. - A test buffer() test. No buffer() on Jython. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 From noreply@sourceforge.net Sun Dec 9 21:12:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 13:12:29 -0800 Subject: [Patches] [ python-Patches-490920 ] Jython and test_unicode Message-ID: Patches item #490920, was opened at 2001-12-09 12:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Jython and test_unicode Initial Comment: Skipping some tests by adding the usual jython conditional test around: - the repr of unicode. Jython only add the u'' if the string contains char values > 255. - A unicode arg to unicode() is perfectly valid in jython. - A test buffer() test. No buffer() on Jython. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-09 13:12 Message: Logged In: NO Looks OK. (Guido, not logged in.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 From noreply@sourceforge.net Sun Dec 9 22:37:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 14:37:43 -0800 Subject: [Patches] [ python-Patches-490920 ] Jython and test_unicode Message-ID: Patches item #490920, was opened at 2001-12-09 12:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: M.-A. Lemburg (lemburg) Summary: Jython and test_unicode Initial Comment: Skipping some tests by adding the usual jython conditional test around: - the repr of unicode. Jython only add the u'' if the string contains char values > 255. - A unicode arg to unicode() is perfectly valid in jython. - A test buffer() test. No buffer() on Jython. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-09 14:37 Message: Logged In: YES user_id=38388 Why should decoding Unicode into Unicode using an UTF-8 encoding assumption be valid ? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-09 13:12 Message: Logged In: NO Looks OK. (Guido, not logged in.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 From noreply@sourceforge.net Sun Dec 9 23:17:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 15:17:05 -0800 Subject: [Patches] [ python-Patches-490100 ] Lets Tkinter work with MacOSX native Tk Message-ID: Patches item #490100, was opened at 2001-12-06 18:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490100&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: Lets Tkinter work with MacOSX native Tk Initial Comment: There is a new Tcl/Tk in alpha that works on MacOSX's windowing layer natively. This patch adds calls necessary for Tkinter to work with it. The Tcl/Tk alpha can be picked up here: http://sourceforge.net/project/showfiles.php?group_id=10894 NOTE: The amount of extra code needed to interface with Tcl/Tk will probably go down with the next alpha of Tcl/Tk. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-09 15:17 Message: Logged In: YES user_id=45365 The mods to _tkinter.c and tkappinit.c are in the repository. What still needs to be done is a readme file explaining where to obtain the X11 headers, what to put into Setup.local and how to run your Tkinter scripts. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-07 02:34 Message: Logged In: YES user_id=45365 I assume the sprintf change was a mistake (I've undone it after I applied the patch). Aside from that the patch looks harmless to other platforms, but I haven't gotten it to work yet. It fails compilation with a missing X11/Xlib.h include. If I can get it to compile at least once I'll put it in CVS before 2.2 (even though it is only useful to the real die-hards: it requires a Tk alfa, and only works under the experimental framework-based Python.app). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-07 01:20 Message: Logged In: YES user_id=21627 Please review your patches carefully before submitting them. Why does this change PyOS_snprintf to sprintf? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490100&group_id=5470 From noreply@sourceforge.net Mon Dec 10 00:01:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 16:01:06 -0800 Subject: [Patches] [ python-Patches-485959 ] Final set of patches to Demo/tix Message-ID: Patches item #485959, was opened at 2001-11-27 03:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Martin v. Löwis (loewis) Summary: Final set of patches to Demo/tix Initial Comment: Final set of patches to Demo/tix - this should be it for a while. Tix.py: Fixed tix_configure and fixed some of the doc strings. tixwidgets.py: fixed loop, added some more docstrings, and made some progress on the global image1 problem. Look for the code around 'if 0:' - it may point towards a bug in Tkinter. Image class. Also if I can understand this proble, maybe I can solve the long outstanding bug described in Demo/tix/BUG.txt. samples/ Fixed SHList1 and 2 not quiting when run from samples/ and fixed a bug in all of the demos that was leaving zombie pythonw processes under Windows in 2.1.0 ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-12-09 16:01 Message: Logged In: YES user_id=33229 Does the attached Tix.py patch run cleanly (it does for me). The bugs in Tix.py and tixwidgets.py should be be fixed before 2.2 goes final - the others are not so important. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-09 09:48 Message: Logged In: YES user_id=21627 I don't think I can find the time to look at this once more before 2.2 - it was already quite time-consuming the last time. I would apply a patch in the last minute with little inspection if it applies cleanly. As for the nature of the problems: I believe for atleast one of the files, the modified file was CRLF converted, so I can't use the file you provided, either. I recommend that you obtain a copy of cvs.exe for Windows, so that you don't have to use a web browser to download the files, and produce a diff. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-12-08 22:52 Message: Logged In: YES user_id=33229 Are the reject significant or just spurious linefeeds at the end of the file? Please apply the patches of the files that run cleanly as the patches are all independent and are all against the current files. The Tix.py and tixiwdgets.py contain important bug fixes. Let me know if the rejects are signiifcant; I don't always have access to unix cvs, and the SF CVS download option under Windows adds spurious linefeeds at the end. That's why I add the .dst files to the tar so you can see if any rejects are trivial. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 04:35 Message: Logged In: YES user_id=21627 These patches don't apply cleanly; I get patch rejects in Control.py.rej SHList1.py.rej SHList2.py.rej Please obtain the current version through CVS, and produce a 'cvs diff -u', instead of individual diff files. We only need the diffs; the original files aren't needed (so you don't need to produce a tar file, either). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 From noreply@sourceforge.net Mon Dec 10 03:26:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 19:26:27 -0800 Subject: [Patches] [ python-Patches-479898 ] Multibyte string on string::string_print Message-ID: Patches item #479898, was opened at 2001-11-08 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Multibyte string on string::string_print Initial Comment: Many multibyte language users are difficult to see native characters on list or dictionary and etc. This patch allows printing multibyte on UNIX98- compatible machines; mbtowc() is ISO/IEC 9899:1990 standard C-API function. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2001-12-09 19:26 Message: Logged In: YES user_id=55188 I uploaded 2nd patches which contains configure support. Unfortunately, Citrus(new generation locale support for *BSDs) didn't implemented iswprint() yet. but *BSDs supports wide character via Rune Locale isprint() func. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:21 Message: Logged In: YES user_id=6380 Still, the patch as it exists is unacceptable -- it needs configure support to decide whether to use mbtowc() and whether to use iswprint() or isprint() (I would hope on BSD there is also an iswprint(), to be standard-conforming). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-06 22:38 Message: Logged In: YES user_id=55188 Yes, it should be changed to iswprint on Linux systems. (but, isprint of BSD systems was designed for wide characters) As loewis told, EUC codes of Korea, Japan, Taiwan doesn't use 0x7F-0x9F for printable character. So, I think that using mbtowc is unavoidable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=21627 You are right, the code should use iswprint instead. The point is that multiple subsequent bytes can make up a single printable character. Not every character above 127 is necessarily printable (e.g. in Latin-1, only characters above 160 are printable). Likewise, a single byte may not be printable, but a combination will print fine. So this code is supposed to catch only those cases where printing will actually work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:08 Message: Logged In: YES user_id=6380 I don't understand the point of using mbtowc() here. The code extracts a wide character, but then it uses isprint() on it, and as far as I know, isprint() is not defined on wide characters, only on 'unsigned char' (and on -1). Isn't what the author wants simply to is isprint(c) instead of (c < ' ' || c >= 0x7f)??? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 13:21 Message: Logged In: YES user_id=21627 Even though I think this patch is correct in principle, I see a few problems with it: 1. Since it doesn't fix a bug, it probably cannot go into 2.2. 2. There is no autoconf test for mbtowc. You should test this in configure, and then conditionalize your code on HAVE_MBTOWC. 3. There is too much code duplication. Try to find a solution which special-cases the escape codes (\something) only once. For example, you may implement a trivial mbtowc redefinition if mbtowc is not available, and then use mbtowc always. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 From noreply@sourceforge.net Mon Dec 10 03:38:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 19:38:06 -0800 Subject: [Patches] [ python-Patches-479898 ] Multibyte string on string::string_print Message-ID: Patches item #479898, was opened at 2001-11-08 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Multibyte string on string::string_print Initial Comment: Many multibyte language users are difficult to see native characters on list or dictionary and etc. This patch allows printing multibyte on UNIX98- compatible machines; mbtowc() is ISO/IEC 9899:1990 standard C-API function. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2001-12-09 19:38 Message: Logged In: YES user_id=55188 Oops, one mistake. sorry. stringobject.c:646 else if (_ISPRINT(c)) { -> else if (cr > 0 && _ISPRINT(c)) { (to detect whether mbtowc failed to convert) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-09 19:26 Message: Logged In: YES user_id=55188 I uploaded 2nd patches which contains configure support. Unfortunately, Citrus(new generation locale support for *BSDs) didn't implemented iswprint() yet. but *BSDs supports wide character via Rune Locale isprint() func. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:21 Message: Logged In: YES user_id=6380 Still, the patch as it exists is unacceptable -- it needs configure support to decide whether to use mbtowc() and whether to use iswprint() or isprint() (I would hope on BSD there is also an iswprint(), to be standard-conforming). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-06 22:38 Message: Logged In: YES user_id=55188 Yes, it should be changed to iswprint on Linux systems. (but, isprint of BSD systems was designed for wide characters) As loewis told, EUC codes of Korea, Japan, Taiwan doesn't use 0x7F-0x9F for printable character. So, I think that using mbtowc is unavoidable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=21627 You are right, the code should use iswprint instead. The point is that multiple subsequent bytes can make up a single printable character. Not every character above 127 is necessarily printable (e.g. in Latin-1, only characters above 160 are printable). Likewise, a single byte may not be printable, but a combination will print fine. So this code is supposed to catch only those cases where printing will actually work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:08 Message: Logged In: YES user_id=6380 I don't understand the point of using mbtowc() here. The code extracts a wide character, but then it uses isprint() on it, and as far as I know, isprint() is not defined on wide characters, only on 'unsigned char' (and on -1). Isn't what the author wants simply to is isprint(c) instead of (c < ' ' || c >= 0x7f)??? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 13:21 Message: Logged In: YES user_id=21627 Even though I think this patch is correct in principle, I see a few problems with it: 1. Since it doesn't fix a bug, it probably cannot go into 2.2. 2. There is no autoconf test for mbtowc. You should test this in configure, and then conditionalize your code on HAVE_MBTOWC. 3. There is too much code duplication. Try to find a solution which special-cases the escape codes (\something) only once. For example, you may implement a trivial mbtowc redefinition if mbtowc is not available, and then use mbtowc always. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 From noreply@sourceforge.net Mon Dec 10 07:42:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 23:42:27 -0800 Subject: [Patches] [ python-Patches-491049 ] Small PyString_FromString optimization Message-ID: Patches item #491049, was opened at 2001-12-09 23:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491049&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) Summary: Small PyString_FromString optimization Initial Comment: Made a very small optimization change to the PyString_FromString routine. Since the length of the string is already being stored in size, changed the strcpy to a memcpy for a small speed improvement. diff is off the latest CVS. David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491049&group_id=5470 From noreply@sourceforge.net Mon Dec 10 10:29:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 02:29:41 -0800 Subject: [Patches] [ python-Patches-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Patches item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-12-10 02:29 Message: Logged In: YES user_id=11105 Tarn, this is really a problem. Thanks for finding it. I still wonder how this bug lead to a crash. Usually the for-loop doesn't run up to beyond the end of the list, because the prefix *should* always be found. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-08 18:42 Message: Logged In: YES user_id=21784 Looks like I've found the problem: line 244 in misc/extract.c is currently this: for (i = 0; *scheme[i].name; ++i) { The scheme list is terminated by a NULL, so *NULL causes an exception at the end of the list. Instead this should be: for (i = 0; scheme[i].name; ++i) { ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 12:55 Message: Logged In: YES user_id=11375 Reassigning to Thomas Heller; I know nothing about bdist_wininst. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 From noreply@sourceforge.net Mon Dec 10 11:53:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 03:53:15 -0800 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 03:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: A.M. Kuchling (akuchling) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Mon Dec 10 12:22:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 04:22:27 -0800 Subject: [Patches] [ python-Patches-490920 ] Jython and test_unicode Message-ID: Patches item #490920, was opened at 2001-12-09 12:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: M.-A. Lemburg (lemburg) Summary: Jython and test_unicode Initial Comment: Skipping some tests by adding the usual jython conditional test around: - the repr of unicode. Jython only add the u'' if the string contains char values > 255. - A unicode arg to unicode() is perfectly valid in jython. - A test buffer() test. No buffer() on Jython. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-10 04:22 Message: Logged In: YES user_id=4201 Jython have only one string type, so we can't differentiate between a string argument and an unicode argument. Instead we just trust that the argument to unicode() is a string that only contain a valid encoded sequence and throw an exception when it isn't the case. >From a type purity point of view, this is a bad design. But it works and I still think it is better than adding a 8bit string type just to be backward compatible with python. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-09 14:37 Message: Logged In: YES user_id=38388 Why should decoding Unicode into Unicode using an UTF-8 encoding assumption be valid ? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-09 13:12 Message: Logged In: NO Looks OK. (Guido, not logged in.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 From noreply@sourceforge.net Mon Dec 10 12:46:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 04:46:54 -0800 Subject: [Patches] [ python-Patches-490920 ] Jython and test_unicode Message-ID: Patches item #490920, was opened at 2001-12-09 12:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: Jython and test_unicode Initial Comment: Skipping some tests by adding the usual jython conditional test around: - the repr of unicode. Jython only add the u'' if the string contains char values > 255. - A unicode arg to unicode() is perfectly valid in jython. - A test buffer() test. No buffer() on Jython. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-10 04:46 Message: Logged In: YES user_id=38388 Ok. I've assigned this to back to you, Finn. Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-12-10 04:22 Message: Logged In: YES user_id=4201 Jython have only one string type, so we can't differentiate between a string argument and an unicode argument. Instead we just trust that the argument to unicode() is a string that only contain a valid encoded sequence and throw an exception when it isn't the case. >From a type purity point of view, this is a bad design. But it works and I still think it is better than adding a 8bit string type just to be backward compatible with python. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-09 14:37 Message: Logged In: YES user_id=38388 Why should decoding Unicode into Unicode using an UTF-8 encoding assumption be valid ? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-09 13:12 Message: Logged In: NO Looks OK. (Guido, not logged in.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:08:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:08:10 -0800 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 03:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Michael Hudson (mwh) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:21:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:21:38 -0800 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 03:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Michael Hudson (mwh) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 07:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:34:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:34:12 -0800 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 03:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Michael Hudson (mwh) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 07:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:37:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:37:10 -0800 Subject: [Patches] [ python-Patches-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Patches item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-10 07:37 Message: Logged In: YES user_id=21784 This fails on the first file lookup. I agree that it shouldn't but you can see the file that it is failing on by looking in the Python root. In the case of a installer called "foo-1.0.win32-py2.2.exe" the first file appears to be "foo-1.0.win32.zip" which looks like the archive name. An empty file of this name also gets created by the installer. I don't know if this is a normal part of a zip file. If it is then adding if (n==0) continue; before line 228 which is pcomp = &data[pcdir->ofs_local_header will fix it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-10 02:29 Message: Logged In: YES user_id=11105 Tarn, this is really a problem. Thanks for finding it. I still wonder how this bug lead to a crash. Usually the for-loop doesn't run up to beyond the end of the list, because the prefix *should* always be found. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-08 18:42 Message: Logged In: YES user_id=21784 Looks like I've found the problem: line 244 in misc/extract.c is currently this: for (i = 0; *scheme[i].name; ++i) { The scheme list is terminated by a NULL, so *NULL causes an exception at the end of the list. Instead this should be: for (i = 0; scheme[i].name; ++i) { ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 12:55 Message: Logged In: YES user_id=11375 Reassigning to Thomas Heller; I know nothing about bdist_wininst. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:46:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:46:46 -0800 Subject: [Patches] [ python-Patches-491049 ] Small PyString_FromString optimization Message-ID: Patches item #491049, was opened at 2001-12-09 23:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491049&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David Jacobs (dbj) >Assigned to: Guido van Rossum (gvanrossum) Summary: Small PyString_FromString optimization Initial Comment: Made a very small optimization change to the PyString_FromString routine. Since the length of the string is already being stored in size, changed the strcpy to a memcpy for a small speed improvement. diff is off the latest CVS. David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:46 Message: Logged In: YES user_id=6380 Thanks! Applied as stringobject.c 2.147. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491049&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:49:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:49:11 -0800 Subject: [Patches] [ python-Patches-489388 ] configure.in patch for OSX Message-ID: Patches item #489388, was opened at 2001-12-05 06:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489388&group_id=5470 >Category: Macintosh Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: configure.in patch for OSX Initial Comment: Anthony, this patch is a sort-of backport of checkins 1.255 (make Python build on OSX 10.1) and 1.281 (reverse order of test for old OSX and new OSX releases). With this patch Python builds on 10.1 and 10.1.1, and I have pretty good confidence it will also build on 10.0. On 10.1.1 you will get an error because it tries to build curses, this will be fixed on the main branch shortly and I'll flag the patch (to setup.py). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-07 04:22 Message: Logged In: YES user_id=45365 It turns out the fix I did for the curses build in the tree trunk is not suitable for 2.1.2 (I've chaned the sys.platform value). I'll submit a 2.1.2-specific patch shortly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489388&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:49:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:49:21 -0800 Subject: [Patches] [ python-Patches-481075 ] Makefile patches for Mac OS X for Python 2.1.2... Message-ID: Patches item #481075, was opened at 2001-11-12 14:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481075&group_id=5470 >Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Jack Jansen (jackjansen) Summary: Makefile patches for Mac OS X for Python 2.1.2... Initial Comment: I'm not a config god, so I'll leave it to someone else to figure out how configuration needs to be changed to incorporate the following changes for Mac OS X 10.1: 1) Assume: ./configure --with-dyld --with-suffix=.x 2) handle BSD header problems by changing Makefile lines OPT= -g -O3 -Wall -Wstrict-prototypes to OPT= -g -O3 -Wall -Wstrict-prototypes -no- cpp-precomp 3) handle two level name spaces for 10.x and 10.0.x - and use bundle loader option vs flat name spaces. LDSHARED= $(CC) $(LDFLAGS) -bundle - undefined suppress BLDSHARED= $(CC) $(LDFLAGS) -bundle - undefined suppress to LDSHARED= $(CC) $(LDFLAGS) -bundle - undefined error -bundle_loader ./python.x BLDSHARED= $(CC) $(LDFLAGS) -bundle - undefined error -bundle_loader ./python.x NOTE: the '.x' in python.x is the suffix entered in the configure command. Also, I've been told the bundle_loader is only used to resolve undefined symbols and there is no likage between the resulting binary and the bundle_loader. Hence, we can rename python.x to python after installation. with the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 06:44 Message: Logged In: YES user_id=45365 Purely by accident I came across this patch. I've usurped it. (Dan: assigning a patch to no-one is a pretty sure way of making it go unnoticed, better assign it to a random person, who'll quickly pass it on to someone else:-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481075&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:49:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:49:58 -0800 Subject: [Patches] [ python-Patches-420565 ] makes setup.py search sys.prefix Message-ID: Patches item #420565, was opened at 2001-05-01 14:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470 >Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: makes setup.py search sys.prefix Initial Comment: It's useful to have setup.py search the lib and include directories in sys.prefix before it checks /usr/local. That way, if you are building Python into a custom location and want it to use the the libraries installed there rather than the system defaults, you can give the --prefix option to configure and setup.py will search that path first. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-01 08:19 Message: Logged In: NO I totally agree. I'm building for hard hat linux on a debian host, and the implicit search in /usr/lib is totally the wrong thing to do in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:51:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:51:06 -0800 Subject: [Patches] [ python-Patches-410547 ] os.statvfs support for Windows Message-ID: Patches item #410547, was opened at 2001-03-22 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 Category: Windows Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: os.statvfs support for Windows Initial Comment: This patch adds (partial) os.statvfs support for Windows. The FRSIZE, BLOCKS, BFREE, BAVAIL, and NAMEMAX fields are set. Remaining fields are set to zero, but should probably be set to None. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:51 Message: Logged In: YES user_id=6380 Rejecting, since nobody seems interested in moving on this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-30 04:22 Message: Logged In: YES user_id=6380 Thanks for the investigation, Tim! Bouncing it back to Fredrik and lowered priority. I certainly don't want to spend a lot of time on it; I believe that the flamewar that started this was ill-advised anyway. Finding out free space is hard; too bad. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-29 20:13 Message: Logged In: YES user_id=31435 No, it did not go in. I asked for a doc patch first so I wouldn't have to pee away time trying to guess what it does. Now I've peed away the time, and I don't like it. Here's what it returns on my home desktop box (Win98SE, 20Gb drive): >>> os.statvfs("c:\") # argument is very touchy (32768, 32768, 65526, 65526, 65526, 0, 0, 0, 0, 1024) >>> *Nothing* there makes sense, except for the last "max path" result. Even the "block size" is wrong (the FAT32 fs on this box uses 16Kb clusters, not 32Kb). Digging into the MS docs, """The GetDiskFreeSpace function returns incorrect values for volumes that are larger than 2 gigabytes""" and """Even on volumes that are smaller than 2 gigabytes, the values stored into *lpSectorsPerCluster, *lpNumberOfFreeClusters, and *lpTotalNumberOfClusters values may be incorrect""" under Win95, and, to judge from my desktop box, it appears useless under the latest flavor of Win98 too. The function the patch uses is obsolete, and a ...Ex version is recommended in its place, which """returns correct values for all volumes, including those that are greater than 2 gigabytes""" BUT, *that* function isn't available under the original Win95, only under Win95 OSR2 and later. In addition, that function only returns number of bytes total and free (as 64 bit unsigned ints), nothing about block size, # clusters, etc. (OTOH, total bytes is free is what people asked for! I don't recall anyone asking for a statvfs() clone) So bouncing back to you: how much time do you want me to devote to this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-29 09:28 Message: Logged In: YES user_id=6380 Tim, wasn't this supposed to go into 2.1b2? Did it? Can it go into 2.1final? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-22 13:35 Message: Logged In: YES user_id=31435 /F, can you add a doc patch (for os.statvfs) that says enough so that a Windows user has some chance of guessing what this function returns? BTW, I have no problem w/ returning zeroes instead of Nones. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:59:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:59:41 -0800 Subject: [Patches] [ python-Patches-420565 ] makes setup.py search sys.prefix Message-ID: Patches item #420565, was opened at 2001-05-01 14:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Michael Hudson (mwh) Summary: makes setup.py search sys.prefix Initial Comment: It's useful to have setup.py search the lib and include directories in sys.prefix before it checks /usr/local. That way, if you are building Python into a custom location and want it to use the the libraries installed there rather than the system defaults, you can give the --prefix option to configure and setup.py will search that path first. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:59 Message: Logged In: YES user_id=6380 Michael, can you have a look at this for Python 2.3 (or 2.2.1)? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-01 08:19 Message: Logged In: NO I totally agree. I'm building for hard hat linux on a debian host, and the implicit search in /usr/lib is totally the wrong thing to do in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:03:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:03:30 -0800 Subject: [Patches] [ python-Patches-463656 ] setup.py, --with-includepath, and LD_LIB Message-ID: Patches item #463656, was opened at 2001-09-21 12:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 >Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py, --with-includepath, and LD_LIB Initial Comment: This patch improves the module detection capability in setup.py. The following improvements are implemented: - directories listed in LD_LIBRARY_PATH are also searched for shared libraries. - the --with-includepath option has been added to configure, to specify additional non-standard directories where the include files are to be searched for. The corresponding changes were added to setup.py (new function detect_include(), find_library_file() augmented, detect_tkinter() improved) I retroceeded manually the changes from configure into configure.in, but I did not run autoconf; you might want to double-check this. Sample aplication: ./configure --prefix=/something --with-includepath='/mgl/apps/include:/mgl/share/include' With this patch, I get Tkinter to build correctly without editing the Setup files, with non-standard tckl/tk 8.0 to 8.3 installations. where the only tcl.h file is in /mgl/share/include/tcl8.0 (therefore, tkinter is build with tcl8.0 on this configuration). FG ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-27 17:17 Message: Logged In: YES user_id=93657 I moved the functions find_library_file() and detect_include() to distutils.sysconfig(), so that they can be reused for configuring third party modules too (e.g.: PyOpenGL...). Let me know if you wish a patch for this. Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-26 15:56 Message: Logged In: YES user_id=93657 I'm replacing the patch with an improved version (against main line as of 09/26/01). New features: - configure is generated from configure.in, with autoconf - detect_tkinter also checks the version number inside the tcl.h and tk.h files (#define TCL_VERSION, #define TK_VERSION...). The 'tk_detect' improvement is in this same patch as the '--include-patch' feature; since the second one was written to get the first one working. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:10:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:10:29 -0800 Subject: [Patches] [ python-Patches-420565 ] makes setup.py search sys.prefix Message-ID: Patches item #420565, was opened at 2001-05-01 14:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470 Category: Distutils and setup.py Group: None >Status: Pending >Resolution: Later Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Michael Hudson (mwh) Summary: makes setup.py search sys.prefix Initial Comment: It's useful to have setup.py search the lib and include directories in sys.prefix before it checks /usr/local. That way, if you are building Python into a custom location and want it to use the the libraries installed there rather than the system defaults, you can give the --prefix option to configure and setup.py will search that path first. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 08:10 Message: Logged In: YES user_id=6656 Umm, yeah sure. I think I'd rather use sysconfig.get_config_var("LIBDIR") than sys.prefix+"/lib", though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:59 Message: Logged In: YES user_id=6380 Michael, can you have a look at this for Python 2.3 (or 2.2.1)? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-01 08:19 Message: Logged In: NO I totally agree. I'm building for hard hat linux on a debian host, and the implicit search in /usr/lib is totally the wrong thing to do in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470 From noreply@sourceforge.net Mon Dec 10 20:59:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 12:59:06 -0800 Subject: [Patches] [ python-Patches-490920 ] Jython and test_unicode Message-ID: Patches item #490920, was opened at 2001-12-09 12:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Jython and test_unicode Initial Comment: Skipping some tests by adding the usual jython conditional test around: - the repr of unicode. Jython only add the u'' if the string contains char values > 255. - A unicode arg to unicode() is perfectly valid in jython. - A test buffer() test. No buffer() on Jython. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-10 12:59 Message: Logged In: YES user_id=4201 Applied to test_unicode.py: 1.47; ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-10 04:46 Message: Logged In: YES user_id=38388 Ok. I've assigned this to back to you, Finn. Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-12-10 04:22 Message: Logged In: YES user_id=4201 Jython have only one string type, so we can't differentiate between a string argument and an unicode argument. Instead we just trust that the argument to unicode() is a string that only contain a valid encoded sequence and throw an exception when it isn't the case. >From a type purity point of view, this is a bad design. But it works and I still think it is better than adding a 8bit string type just to be backward compatible with python. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-09 14:37 Message: Logged In: YES user_id=38388 Why should decoding Unicode into Unicode using an UTF-8 encoding assumption be valid ? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-09 13:12 Message: Logged In: NO Looks OK. (Guido, not logged in.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490920&group_id=5470 From noreply@sourceforge.net Mon Dec 10 23:12:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 15:12:37 -0800 Subject: [Patches] [ python-Patches-491351 ] Static strcpy to memcpy Message-ID: Patches item #491351, was opened at 2001-12-10 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) Summary: Static strcpy to memcpy Initial Comment: This patch replaces all occurrances in the codebase of calls to strcpy that use static strings with calls to memcpy (e.g., strcpy(a, "a string") gets replaced with memcpy(a, "a string", 9)) David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 From noreply@sourceforge.net Tue Dec 11 02:27:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 18:27:47 -0800 Subject: [Patches] [ python-Patches-491401 ] strncpy to memcpy Message-ID: Patches item #491401, was opened at 2001-12-10 18:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491401&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) Summary: strncpy to memcpy Initial Comment: This patch replaces uses of strncpy with memcpy where appropriate. strncpy incurs the overhead of checking for a premature '\0' ending to the string. In cases where we know where the string terminates (e.g., we have performed a strlen) memcpy can safely replace strncpy. David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491401&group_id=5470 From noreply@sourceforge.net Tue Dec 11 02:28:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 18:28:48 -0800 Subject: [Patches] [ python-Patches-491401 ] Changes strncpy to memcpy for opt Message-ID: Patches item #491401, was opened at 2001-12-10 18:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491401&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) >Summary: Changes strncpy to memcpy for opt Initial Comment: This patch replaces uses of strncpy with memcpy where appropriate. strncpy incurs the overhead of checking for a premature '\0' ending to the string. In cases where we know where the string terminates (e.g., we have performed a strlen) memcpy can safely replace strncpy. David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491401&group_id=5470 From noreply@sourceforge.net Tue Dec 11 02:30:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 18:30:11 -0800 Subject: [Patches] [ python-Patches-491351 ] Changes static strcpy to memcpy Message-ID: Patches item #491351, was opened at 2001-12-10 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) >Summary: Changes static strcpy to memcpy Initial Comment: This patch replaces all occurrances in the codebase of calls to strcpy that use static strings with calls to memcpy (e.g., strcpy(a, "a string") gets replaced with memcpy(a, "a string", 9)) David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 From noreply@sourceforge.net Tue Dec 11 03:26:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 19:26:59 -0800 Subject: [Patches] [ python-Patches-491418 ] upgrade test to improve coverage test_b1 Message-ID: Patches item #491418, was opened at 2001-12-10 19:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491418&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: upgrade test to improve coverage test_b1 Initial Comment: exceptions from abs('a'), int('\0'), long('\0') ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491418&group_id=5470 From noreply@sourceforge.net Tue Dec 11 03:28:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 19:28:32 -0800 Subject: [Patches] [ python-Patches-491420 ] upgrade test to improve coverage descr Message-ID: Patches item #491420, was opened at 2001-12-10 19:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491420&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: upgrade test to improve coverage descr Initial Comment: new types, '' methods and format strings ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491420&group_id=5470 From noreply@sourceforge.net Tue Dec 11 03:30:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 19:30:04 -0800 Subject: [Patches] [ python-Patches-491421 ] upgrade test to improve coverage types Message-ID: Patches item #491421, was opened at 2001-12-10 19:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491421&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: upgrade test to improve coverage types Initial Comment: upgrade tests for type() may not be best place to put test, but I don't know where else to put it ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491421&group_id=5470 From noreply@sourceforge.net Tue Dec 11 04:38:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 20:38:23 -0800 Subject: [Patches] [ python-Patches-491418 ] upgrade test to improve coverage test_b1 Message-ID: Patches item #491418, was opened at 2001-12-10 19:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491418&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: upgrade test to improve coverage test_b1 Initial Comment: exceptions from abs('a'), int('\0'), long('\0') ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 20:38 Message: Logged In: YES user_id=6380 Thanks -- applied. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491418&group_id=5470 From noreply@sourceforge.net Tue Dec 11 04:38:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 20:38:43 -0800 Subject: [Patches] [ python-Patches-491420 ] upgrade test to improve coverage descr Message-ID: Patches item #491420, was opened at 2001-12-10 19:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491420&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: upgrade test to improve coverage descr Initial Comment: new types, '' methods and format strings ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 20:38 Message: Logged In: YES user_id=6380 Thanks -- applied. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491420&group_id=5470 From noreply@sourceforge.net Tue Dec 11 04:39:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 20:39:02 -0800 Subject: [Patches] [ python-Patches-491421 ] upgrade test to improve coverage types Message-ID: Patches item #491421, was opened at 2001-12-10 19:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491421&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: upgrade test to improve coverage types Initial Comment: upgrade tests for type() may not be best place to put test, but I don't know where else to put it ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 20:39 Message: Logged In: YES user_id=6380 Thanks -- applied. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491421&group_id=5470 From noreply@sourceforge.net Tue Dec 11 09:45:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 01:45:08 -0800 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 and setup.py >Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: M.-A. Lemburg (lemburg) 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 Tue Dec 11 18:21:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 10:21:25 -0800 Subject: [Patches] [ python-Patches-491351 ] Changes static strcpy to memcpy Message-ID: Patches item #491351, was opened at 2001-12-10 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) Summary: Changes static strcpy to memcpy Initial Comment: This patch replaces all occurrances in the codebase of calls to strcpy that use static strings with calls to memcpy (e.g., strcpy(a, "a string") gets replaced with memcpy(a, "a string", 9)) David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 10:21 Message: Logged In: YES user_id=21627 What is the rationale for this patch? Maintaining the memcpy calls is much more complicated and error-prone. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 From noreply@sourceforge.net Tue Dec 11 18:28:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 10:28:20 -0800 Subject: [Patches] [ python-Patches-490456 ] Unicode support in email.Utils.encode Message-ID: Patches item #490456, was opened at 2001-12-07 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490456&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode support in email.Utils.encode Initial Comment: It's essentially an updated patch 486375, this time making a distinction of type for the passed string; if it's Unicode, the function encodes it to the character set specified as the charset parameter. The reasons: 1. The function in its current version doesn't support Unicode, throwing an exception if any non-ASCII characters are found within it. 2. With this patch, we reach a sort of operational symmetry on email.Utils.encode vs email.Utils.decode, as it can be seen in the tests. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 10:28 Message: Logged In: YES user_id=21627 The patch looks good, except that I cannot really see the value in using "replace" for .encode. Wouldn't it be better to get an exception if the Unicode string contains an un-encodable character? Also, the Python 2.2 way to spell the type test is if isinstance(s, unicode) This makes use of the fact that the unicode builtin is a type now, and it supports unicode subtypes. This is a minor change, of course. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490456&group_id=5470 From noreply@sourceforge.net Tue Dec 11 18:55:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 10:55:23 -0800 Subject: [Patches] [ python-Patches-491351 ] Changes static strcpy to memcpy Message-ID: Patches item #491351, was opened at 2001-12-10 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) Summary: Changes static strcpy to memcpy Initial Comment: This patch replaces all occurrances in the codebase of calls to strcpy that use static strings with calls to memcpy (e.g., strcpy(a, "a string") gets replaced with memcpy(a, "a string", 9)) David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 10:55 Message: Logged In: YES user_id=6380 My thoughts exactly. This causes a maintenance nightmare, for no good reason. It's not like this mechanical translation plugs any security leaks either... At best it silences naive security tools that complain about every strcpy() call they see. But that's not my problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 10:21 Message: Logged In: YES user_id=21627 What is the rationale for this patch? Maintaining the memcpy calls is much more complicated and error-prone. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 From noreply@sourceforge.net Tue Dec 11 18:44:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 10:44:41 -0800 Subject: [Patches] [ python-Patches-490026 ] Namespace selection for rlcompleter Message-ID: Patches item #490026, was opened at 2001-12-06 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Namespace selection for rlcompleter Initial Comment: The standard rlcompleter is hardwired to work with __main__.__dict__. This is limiting, as one may have applications which execute in specially constructed 'sandboxed' namespaces. This patch extends rlcompleter with a constructor which provides an optional namespace specifier. This optional parameter defaults to __main__.__dict__, so the patch is 100% backwards compatible. ---------------------------------------------------------------------- >Comment By: Fernando Pérez (fer_perez) Date: 2001-12-11 10:44 Message: Logged In: YES user_id=395388 Updated with a one-line fix (a mistyped variable name). Deleted v2 of the patch with the typo. ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 23:16 Message: Logged In: YES user_id=395388 I've uploaded a new version of the patch with those changes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 19:32 Message: Logged In: YES user_id=6380 Yes, that's about right. ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 18:53 Message: Logged In: YES user_id=395388 I could rewrite it to use instead a namespace=None in the constructor. If a namespace is given it will be used, otherwise at completion time a check will be made: if self.namespace is None: self.namespace=__main__.__dict__ This means an extra if in the completer, but would address your concern. Do you want me to do that? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 17:38 Message: Logged In: YES user_id=6380 Since this is obviously a new feature, I'll postpone this until after 2.2. One thing that worries me: you capture the identity of __main__.__dict__ early on in this patch. The original code uses whatever __main__.__dict__ at the time it is needed. ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2001-12-08 10:39 Message: Logged In: YES user_id=395388 Oops, sorry. You can tell I've never used the system before. I put the file in, but I just didn't see the stupid extra checkbox. Lack of orthogonality in an interface is always a recipe for problems. Anyway, it should be ok now. Cheers, Fernando. PS. And the obvious, *THANKS* a lot for putting such a fantastic tool out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:15 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490026&group_id=5470 From noreply@sourceforge.net Tue Dec 11 20:28:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 12:28:30 -0800 Subject: [Patches] [ python-Patches-491351 ] Changes static strcpy to memcpy Message-ID: Patches item #491351, was opened at 2001-12-10 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) Summary: Changes static strcpy to memcpy Initial Comment: This patch replaces all occurrances in the codebase of calls to strcpy that use static strings with calls to memcpy (e.g., strcpy(a, "a string") gets replaced with memcpy(a, "a string", 9)) David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- >Comment By: David Jacobs (dbj) Date: 2001-12-11 12:28 Message: Logged In: YES user_id=19903 This patch and the strncpy patch are both attempts to achieve easy optimizations. I agree that it does add to the maintenance. However memcpy's can be optimized much more than a strcpy. I haven't done any profiling to check whether any of them fall into current hot spots, but the addtional maintenance (having to count the length of strings when they are changed) burden does not seem excessive. But as one who is not responsible for maintaining the whole, I respect the judgement of those who do :-). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 10:55 Message: Logged In: YES user_id=6380 My thoughts exactly. This causes a maintenance nightmare, for no good reason. It's not like this mechanical translation plugs any security leaks either... At best it silences naive security tools that complain about every strcpy() call they see. But that's not my problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 10:21 Message: Logged In: YES user_id=21627 What is the rationale for this patch? Maintaining the memcpy calls is much more complicated and error-prone. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 From noreply@sourceforge.net Tue Dec 11 20:37:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 12:37:57 -0800 Subject: [Patches] [ python-Patches-491351 ] Changes static strcpy to memcpy Message-ID: Patches item #491351, was opened at 2001-12-10 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) Summary: Changes static strcpy to memcpy Initial Comment: This patch replaces all occurrances in the codebase of calls to strcpy that use static strings with calls to memcpy (e.g., strcpy(a, "a string") gets replaced with memcpy(a, "a string", 9)) David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 12:37 Message: Logged In: YES user_id=6380 OK, then I will reject the patch away. I value the readability of the source much more than a pico-optimization for which no performance benchmarks indicate the need. Hey, we've rejected performance tweaks that were shown to speed up certain programs by 5% because the benefits weren't clear! :-) ---------------------------------------------------------------------- Comment By: David Jacobs (dbj) Date: 2001-12-11 12:28 Message: Logged In: YES user_id=19903 This patch and the strncpy patch are both attempts to achieve easy optimizations. I agree that it does add to the maintenance. However memcpy's can be optimized much more than a strcpy. I haven't done any profiling to check whether any of them fall into current hot spots, but the addtional maintenance (having to count the length of strings when they are changed) burden does not seem excessive. But as one who is not responsible for maintaining the whole, I respect the judgement of those who do :-). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 10:55 Message: Logged In: YES user_id=6380 My thoughts exactly. This causes a maintenance nightmare, for no good reason. It's not like this mechanical translation plugs any security leaks either... At best it silences naive security tools that complain about every strcpy() call they see. But that's not my problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 10:21 Message: Logged In: YES user_id=21627 What is the rationale for this patch? Maintaining the memcpy calls is much more complicated and error-prone. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491351&group_id=5470 From noreply@sourceforge.net Tue Dec 11 20:38:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 12:38:33 -0800 Subject: [Patches] [ python-Patches-491401 ] Changes strncpy to memcpy for opt Message-ID: Patches item #491401, was opened at 2001-12-10 18:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491401&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: David Jacobs (dbj) >Assigned to: Guido van Rossum (gvanrossum) Summary: Changes strncpy to memcpy for opt Initial Comment: This patch replaces uses of strncpy with memcpy where appropriate. strncpy incurs the overhead of checking for a premature '\0' ending to the string. In cases where we know where the string terminates (e.g., we have performed a strlen) memcpy can safely replace strncpy. David Jacobs jacobsl001@hawaii.rr.com ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 12:38 Message: Logged In: YES user_id=6380 Rejected, see #491351 for reason. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491401&group_id=5470 From noreply@sourceforge.net Tue Dec 11 21:19:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 13:19:13 -0800 Subject: [Patches] [ python-Patches-491736 ] Eliminate redundant code in PyString_Fro Message-ID: Patches item #491736, was opened at 2001-12-11 13:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491736&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) Summary: Eliminate redundant code in PyString_Fro Initial Comment: stringobject.c - revision 2.147 Realized that PyString_FromString replicates the code from PyString_FromStringAndSize so I thought maintenance would be improved by calling PyString_FromStringAndSize instead of duplicating the code. If patches like these are considered a nusuiance please let me know and I'll stop and only submit bug patches. I am still trying to learn what kinds of contributions this community like to receive :-). I find doing things like this helps me learn a new codebase. Thanks for you time, David ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491736&group_id=5470 From noreply@sourceforge.net Tue Dec 11 21:31:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 13:31:22 -0800 Subject: [Patches] [ python-Patches-491736 ] Eliminate redundant code in PyString_Fro Message-ID: Patches item #491736, was opened at 2001-12-11 13:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491736&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) Summary: Eliminate redundant code in PyString_Fro Initial Comment: stringobject.c - revision 2.147 Realized that PyString_FromString replicates the code from PyString_FromStringAndSize so I thought maintenance would be improved by calling PyString_FromStringAndSize instead of duplicating the code. If patches like these are considered a nusuiance please let me know and I'll stop and only submit bug patches. I am still trying to learn what kinds of contributions this community like to receive :-). I find doing things like this helps me learn a new codebase. Thanks for you time, David ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 13:31 Message: Logged In: YES user_id=6380 In this particular case there's a documented need to squeeze as much performance out of the CPU as desired, hence the code duplication. Keep on trying, you'll find something that's useful! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491736&group_id=5470 From noreply@sourceforge.net Tue Dec 11 22:52:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 14:52:59 -0800 Subject: [Patches] [ python-Patches-490456 ] Unicode support in email.Utils.encode Message-ID: Patches item #490456, was opened at 2001-12-07 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490456&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode support in email.Utils.encode Initial Comment: It's essentially an updated patch 486375, this time making a distinction of type for the passed string; if it's Unicode, the function encodes it to the character set specified as the charset parameter. The reasons: 1. The function in its current version doesn't support Unicode, throwing an exception if any non-ASCII characters are found within it. 2. With this patch, we reach a sort of operational symmetry on email.Utils.encode vs email.Utils.decode, as it can be seen in the tests. ---------------------------------------------------------------------- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2001-12-11 14:52 Message: Logged In: YES user_id=313104 2loewis: In a typical email application, it'd be better to display partially encoded text than to face a hard stop when trying to process a message, hence 'replace'. Actually, the encoding mode could be an optional parameter, but I don't feel like deciding on parameters for a function not developed by me. Barry? The isinstance part seems to be valid, I'm updating the patch here accordingly. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 10:28 Message: Logged In: YES user_id=21627 The patch looks good, except that I cannot really see the value in using "replace" for .encode. Wouldn't it be better to get an exception if the Unicode string contains an un-encodable character? Also, the Python 2.2 way to spell the type test is if isinstance(s, unicode) This makes use of the fact that the unicode builtin is a type now, and it supports unicode subtypes. This is a minor change, of course. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490456&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:14:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:14:51 -0800 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: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Gregor Hoffleit (flight) Assigned to: Guido van Rossum (gvanrossum) 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-12-11 21:14 Message: Logged In: YES user_id=6380 Closing as Won't fix. If Gregor still wants this, he can always add a note and I'll reopen it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:44 Message: Logged In: YES user_id=6380 Gregor, care to respond? Or should I just reject this? ---------------------------------------------------------------------- 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 Wed Dec 12 05:22:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:22:02 -0800 Subject: [Patches] [ python-Patches-410161 ] Create parsermodule.h Message-ID: Patches item #410161, was opened at 2001-03-20 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 Category: Modules Group: None Status: Open Resolution: Out of Date Priority: 4 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (supercedes #409307) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The basic idea is that parsermodule declared all of its types and functions in the .c file instead of a .h. That meant that they were unavailable to other code. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:22 Message: Logged In: YES user_id=6380 Fred, can you ping Paul to ask if he still wants this? If not, we should close the patch. (Paul doesn't respond to email sent to his SF account, at least he ignores SF change messages, so you'll have to write him directly at ActiveState.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-13 14:58 Message: Logged In: YES user_id=21627 The current patch fails to apply, which is complicated by the fact that it is an oldstyle diff, rather than a context (-c) or unified (-u) one. So I mark it outdated. I think that the idea, in general, was a good one. So if it gets updated, I'd encourage a more speedy processing of it before it outdates again. OTOH, if it is not updated, I propose to close it as rejected in October 2001. ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-23 18:26 Message: Logged In: YES user_id=31788 Well here's some incentive to check it in when you get a chance. I've got another patch that allows for pluggable compilers. parsermodule is used to build node objects to pass to Python code that replaces the compiler. Of course we may soon want pluggable parsers too... ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-23 18:26 Message: Logged In: YES user_id=31788 Well here's some incentive to check it in when you get a chance. I've got another patch that allows for pluggable compilers. parsermodule is used to build node objects to pass to Python code that replaces the compiler. Of course we may soon want pluggable parsers too... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-20 22:17 Message: Logged In: YES user_id=3066 I'll try to check in something similar tomorrow, when I've had a little time to sit on this now that I've actually read the comments. ;-) I don't think the included header is exactly right, but that's in part that I don't think the names are good (yes, I know they're mine!). ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:41 Message: Logged In: YES user_id=31788 (argh...the patch didn't show up) ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:39 Message: Logged In: YES user_id=31788 I'm adding the changes to parsermodule.c that need to be made so as not to duplicate the information in the new parsermodule.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:22:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:22:34 -0800 Subject: [Patches] [ python-Patches-410395 ] death module Message-ID: Patches item #410395, was opened at 2001-03-21 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410395&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: death module Initial Comment: This module makes it easy to generate core dumps from Python. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:22 Message: Logged In: YES user_id=6380 Closed. I see no point in keeping this around forever. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-21 14:40 Message: Logged In: YES user_id=12800 Looks good, a few comments. - the deathmodule.c patch was included three times! Guess you really want it to die. - you should include a death_die_abort() which calls the abort() function. - the functions return NULL but don't set an exception. while I agree it's highly unlikely that the functions actually return, you might want to do something saner than cause a SystemError if they magically manage to return on some platform. - be sure that this module isn't built/enabled by default! if an app had a hole which allowed this module to be invoked, it would be a nice DoS attack. - you may want to coordinate a bit with Dave Beazley based on his IPC9 presentation. Assigning back to Jeremy with a +1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410395&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:23:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:23:13 -0800 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: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:23 Message: Logged In: YES user_id=6380 Barry, is this still relevant given the email package? ---------------------------------------------------------------------- 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 Wed Dec 12 05:23:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:23:42 -0800 Subject: [Patches] [ python-Patches-477752 ] Drop old-style getargs from curses Message-ID: Patches item #477752, was opened at 2001-11-03 02:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477752&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Nobody/Anonymous (nobody) Summary: Drop old-style getargs from curses Initial Comment: This patch converts _cursesmodule and _curses_panel into using ParseTuple, METH_VARARGS, METH_NOARGS, and METH_O throughout. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477752&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:24:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:24:01 -0800 Subject: [Patches] [ python-Patches-477750 ] Use METH_ constants in Modules Message-ID: Patches item #477750, was opened at 2001-11-03 02:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Nobody/Anonymous (nobody) Summary: Use METH_ constants in Modules Initial Comment: This patch addes METH_OLDARGS and METH_VARARGS into every method table (except for curses, for which a separate patch is upcoming). ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:19 Message: Logged In: YES user_id=31392 We should probably wait until after 2.2 to make all these changes. I expect they're harmless, but it's a lot of code to change at the last minute. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:24:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:24:42 -0800 Subject: [Patches] [ python-Patches-489066 ] Include RLIM_INFINITY constant Message-ID: Patches item #489066, was opened at 2001-12-04 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489066&group_id=5470 Category: Modules Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Eric Huss (ehuss) Assigned to: Jeremy Hylton (jhylton) Summary: Include RLIM_INFINITY constant Initial Comment: The following is a patch to the resource module to include the RLIM_INFINITY constant. It should handle platforms where RLIM_INFINITY is not a LONG_LONG, but I have no means to test that. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:24 Message: Logged In: YES user_id=6380 Jeremy, please review and apply or reject (or postpone and lower priority). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489066&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:41:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:41:52 -0800 Subject: [Patches] [ python-Patches-485794 ] calendar.isleap should return 1 not true Message-ID: Patches item #485794, was opened at 2001-11-26 14:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485794&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: calendar.isleap should return 1 not true Initial Comment: The documentation for calendar.isleap should state the function returns 1, not only true. The documentation says only that calendar.isleap returns true if the year is a leap year. The docstring is more specific and speaks of 1 vs. 0. The latter is convenient for days_in_february = 28 + calendar.isleap(year) However, if the docstring describes only the - possibly changing - implementation you would strictly have to write the much more verbose if calendar.isleap(year): days_in_february = 29 else: days_in_february = 28 (Is the actual interface of calendar.isleap going to change? (I don't think so.)) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 21:41 Message: Logged In: YES user_id=3066 Why not use: from calendar import isleap days_in_february = 28 + (isleap(year) and 1 or 0) That remains reasonably brief and is essentially the same. Anyway, I'm adjusting the docs to match the docstring, since that already makes the requested guarantee (Doc/lib/libcalendar.tex revision 1.14). Also added a simple test case to check for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485794&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:43:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:43:39 -0800 Subject: [Patches] [ python-Patches-410161 ] Create parsermodule.h Message-ID: Patches item #410161, was opened at 2001-03-20 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Out of Date Priority: 4 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Create parsermodule.h Initial Comment: (supercedes #409307) When Fred created parsermodule.c back in the mid-90's he put in a comment that some of the code should really be moved into a header file for more general use. Now I need that feature to implement compiler hooks. The basic idea is that parsermodule declared all of its types and functions in the .c file instead of a .h. That meant that they were unavailable to other code. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 21:43 Message: Logged In: YES user_id=3066 It should probably be done anyway, but there's no meaningful priority associated with this. Closing since Paul hasn't responded to Martin's comment on his own; if he still cares he can re-open the report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:22 Message: Logged In: YES user_id=6380 Fred, can you ping Paul to ask if he still wants this? If not, we should close the patch. (Paul doesn't respond to email sent to his SF account, at least he ignores SF change messages, so you'll have to write him directly at ActiveState.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-13 14:58 Message: Logged In: YES user_id=21627 The current patch fails to apply, which is complicated by the fact that it is an oldstyle diff, rather than a context (-c) or unified (-u) one. So I mark it outdated. I think that the idea, in general, was a good one. So if it gets updated, I'd encourage a more speedy processing of it before it outdates again. OTOH, if it is not updated, I propose to close it as rejected in October 2001. ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-23 18:26 Message: Logged In: YES user_id=31788 Well here's some incentive to check it in when you get a chance. I've got another patch that allows for pluggable compilers. parsermodule is used to build node objects to pass to Python code that replaces the compiler. Of course we may soon want pluggable parsers too... ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-23 18:26 Message: Logged In: YES user_id=31788 Well here's some incentive to check it in when you get a chance. I've got another patch that allows for pluggable compilers. parsermodule is used to build node objects to pass to Python code that replaces the compiler. Of course we may soon want pluggable parsers too... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-20 22:17 Message: Logged In: YES user_id=3066 I'll try to check in something similar tomorrow, when I've had a little time to sit on this now that I've actually read the comments. ;-) I don't think the included header is exactly right, but that's in part that I don't think the names are good (yes, I know they're mine!). ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:41 Message: Logged In: YES user_id=31788 (argh...the patch didn't show up) ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-03-20 13:39 Message: Logged In: YES user_id=31788 I'm adding the changes to parsermodule.c that need to be made so as not to duplicate the information in the new parsermodule.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410161&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:46:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:46:44 -0800 Subject: [Patches] [ python-Patches-479551 ] fix complex() with 2 string args Message-ID: Patches item #479551, was opened at 2001-11-08 05:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fix complex() with 2 string args Initial Comment: reported on c.l.py >>> complex ("1", "1") (1+0j) >From my reading of the docs, this should fail. Patch does this, adds test case. Assigned to Fred, largely at random. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 21:46 Message: Logged In: YES user_id=3066 The documentation updates should be made for Python 2.2; I can work with Tim on this on Thursday to make sure this is right. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-08 10:00 Message: Logged In: YES user_id=31435 Note that 2.2 complex also accepts keyword "real" and "imag" arguments; if we're changing the docs anyway, may as well sneak that in too. BTW, I'm really surprised nobody complained about this : >>> complex(1, 1j) 0j >>> Alas, that's "a feature". ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-08 08:02 Message: Logged In: YES user_id=44345 Yeah, I didn't think they were that different. I had already completed (but not completed testing) my patch when I saw your c.l.py patch. Once I completed testing I simple wrapped it up and uploaded it. I figure Fred can merge our two versions as well as we can. ;-) (As for diff-mode, it's likely the same thing as in Emacs 21.1, but XEmacs 21.1 didn't have a diff mode at all, so I was quite surprised the other day after upgrading to XEmacs 21.4 when I visited a .diff file and had it pop into diff-mode. Today, to create my complex patch, I just cvs diff'd the entire Python tree, edited the file in diff-mode and used M-k/M-n to migrate around, deleting the stuff unrelated to this patch. I didn't have to figure out what lines to cut. When I deleted the last chunk for a particular file it automatically zapped the file's header as well. I was in diff heaven... ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-11-08 07:47 Message: Logged In: YES user_id=6656 Agree with your changes to complexobject.c, though they're not v. different from mine. Your tests reproduce what's in test_b1.py so are probably redunant. I don't think you can read the current docs with your head screwed on and get the wrong idea, but am willing to defer to Fred on that one... What does XEmacs 21.4's diff-mode do that GNU Emacs 21.1's doesn't? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-08 07:31 Message: Logged In: YES user_id=44345 I have a slightly different patch. If the first arg is not a string, the second arg can't be a string. The current implementation raises a TypeError with a not entirely comprehensible message, so I added a special case to catch that. Also, my test cases are in test_complex.py instead of test_b1.py and I have some doc changes. (God, I just *loooove* the new diff-mode in XEmacs 21.4. Ya gotta try it -- if you're not a vi-head, that is!) ---------------------------------------------------------------------- Comment By: Grant Griffin (dspguru) Date: 2001-11-08 07:13 Message: Logged In: YES user_id=70844 I agree with the discussion on c.l.py as to the interpretation of the docs, so it sounds like Michael's patch is a good thing. However, along with the patch, I'd like to see the docs clarified a little. Specifically, it would be nice if the docs stated that the imaginary part (if any) can be specified as part of the string using the standard "j" suffix: ActivePython 2.1.1, build 212 (ActiveState) >>> complex('1+1j') (1+1j) This feature appears to be the reason that a separate imaginary argument was disallowed in the string case, so spelling that aspect out will help people understand (and therefore remember) the rules on this. =g2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 From noreply@sourceforge.net Wed Dec 12 08:00:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 00:00:59 -0800 Subject: [Patches] [ python-Patches-491936 ] Opt for tok_nextc Message-ID: Patches item #491936, was opened at 2001-12-12 00:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Jacobs (dbj) Assigned to: Nobody/Anonymous (nobody) Summary: Opt for tok_nextc Initial Comment: tokenizer.c - revision 2.53 I tried to pick a routine that looked like it was heavily used and optimizations that do not increase the maintenance burden (I wont feel bad if you reject it though, I'll keep on trying as long as you don't consider it a burden :-). I changed one strcpy to a memcpy because the length had already been computed. I also changed the pattern: a = strchr(b,'\0'); to a = b + strlen(b); Which is an idiom I've seen in many other places in the code so I don't think it makes it harder to understand and strlen is significantly more efficient than strchr. Aloha, David Jacobs (your pico optimizer :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491936&group_id=5470 From noreply@sourceforge.net Wed Dec 12 14:40:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 06:40:27 -0800 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 03:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Michael Hudson (mwh) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-12 06:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 07:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Wed Dec 12 15:25:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 07:25:47 -0800 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 03:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Michael Hudson (mwh) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2001-12-12 07:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 06:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 07:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Wed Dec 12 17:21:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 09:21:08 -0800 Subject: [Patches] [ python-Patches-492105 ] Import from Zip archive Message-ID: Patches item #492105, was opened at 2001-12-12 09:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=492105&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: Import from Zip archive Initial Comment: This is the "final" patch to support imports from zip archives, and directory caching using os.listdir(). It replaces patch 483466 and 476047. It is a separate patch since I can't delete file attachments. It adds support for importing from "" and from relative paths. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=492105&group_id=5470 From noreply@sourceforge.net Wed Dec 12 17:22:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 09:22:03 -0800 Subject: [Patches] [ python-Patches-483466 ] Import from Zip Archive, Obsolete Message-ID: Patches item #483466, was opened at 2001-11-19 07:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) >Summary: Import from Zip Archive, Obsolete Initial Comment: This is the "final" patch to import.c to support imports from zip archives and directory caching using os.listdir(). It replaces patch 476047. It it intended to be part of Python 2.3. There are five files requiring patches, and these are in context diff's in five separate attached files. I have tested this on Linux and Windows 2000. It needs testing on bigendian machines, and those with 64-bit integers. Please complain about bugs, but let me know if you plan to change the code. The documentation for the imp module needs a patch. This is added right after "PY_FROZEN": PY_ZIPFILE The module was found in a zip archive file. BUGS ==== There are a couple of bugs I wasn't sure were worth fixing. Please complain if these are a problem: The use of os.listdir() for normal directory imports makes case_ok() unnecessary, but it was not removed. It might be needed if os.listdir() is missing. There is no problem if os.listdir() doesn't exist, but if it exists, it must perform as documented, and must return both file and directory names in their correct case. The PYTHONCASEOK flag is ineffective. This is a consequence of dictionary name lookup. ---------------------------------------------------------------------- Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-11-30 08:41 Message: Logged In: YES user_id=64929 I added newer file versions to implement the changes discussed on python-dev. I still need to patch import.c to properly handle "" and relative paths in sys.path. The current changes are: 1) Creation of sys.path[0] is moved out of PySys_SetArgv() and into Py_GetPath(). Creation of the zip path is also moved into Py_GetPath(), so that all sys.path's are now in Py_GetPath(). 2) sys.path[0] is the absolute path of the Python script being run. For "-c" or an interactive interpreter, it remains "". There are two new Python API functions Py_SetScriptName() and Py_GetScriptName(). These are similar to the existing Py_[GS]etProgramName() functions, and are used for the same purpose, namely passing information to Py_GetPath(). All these functions are arguably hacks which should be replaced with additional arguments to Py_Initialize(). Here is the documentation: char* Py_GetScriptName () Return the script name set with Py_SetScriptName(), or NULL. The returned string points into static storage; the caller should not modify its value. void Py_SetScriptName (char *name) This is similar to Py_SetProgramName(), but tells the interpreter the file name of the Python script being run. This is used by Py_GetPath() to add the directory of the script to sys.path. If name is NULL no script item is added to sys.path. If name is "", the item "" will be added to sys.path, and "" means the current directory. Otherwise the absolute directory path will be added. The argument must point to a string in static storage whose contents will not change for the duration of the program's execution. ---------------------------------------------------------------------- Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-11-20 06:49 Message: Logged In: YES user_id=64929 The zero length string "" is not handled correctly as an item of sys.path. It should mean current directory, but its contents will not be cached. What happens if the current directory changes? Should the new directory be searched, or only the original current directory? I will submit a further patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470 From bizopp2002us@yahoo.com Wed Dec 12 20:52:46 2001 From: bizopp2002us@yahoo.com (John McCuullen) Date: Wed, 12 Dec 2001 21:52:46 +0100 Subject: [Patches] The Secret to Supercharge your MLM! Message-ID: <2356121-2200112312205246610@yahoo.com> Discover "The Secret to Supercharge your MLM!"=20 A must read=2E=2E=2E=20 Hi there,=20 The secret is out!=20 Here's the mail we've all been waiting for! Read carefully and take immediate action on it!=20 I've discovered an amazing formula that will give your MLM an enormous enrollers explosion=2E You'll benefit hugely if you use it with YOUR primary MLM!=20 -THE ULTIMATE RECRUITMENT FORMULA-=20 So if you are already in MLM or about to get into one this will be the most important mail you will ever read=2E=20 Right now I know people who enroll dozens in their downlines WEEKLY using the formula I'm about to reveal=2E=20 Fred Stege, Founder of the company enrolled 127 people within 7 day's after launching! One of his enrollees from this batch has become top recruiter in his company within 90 days after using this incredible easy-to-use concept=2E=20 The NEW Formula is meant as a Front End Program to enhance "YOUR" MLM=2E I'm NOT pitching you in any MLM=2E ____________________________________________ In fact you may try it for absolutely FREE and you'll get an electrifying stack of tools straight away! ____________________________________________=20 We've discovered that the majority of Qualified MLM Leads (Prospects) all have 1 thing in common=2E=2E=2E=20 They all are looking for 3 things they desperately want and can't get in any one 100% generic System=2E=2E=2E=20 I just know that you'll agree with these 3 things and they are all to your advantage!=20 Let me reveal you the 3 most sought after topics first:=20 =B7 Cutting Edge MLM Information=2E =B7 A Legitimate Proven Formula=2E =B7 Pre Qualified Leads=2E (And how to get them for FREE)=20 Isn't that what everybody is looking for?=2E=2E Will these topics ever go out of style?=2E=2E Doesn't THAT Attract the Masses?=2E=2E=20 Does 'OLD SCHOOL MLM' attract the masses?=2E=2E=20 Discover "How you can EARN RESIDUAL INCOME While Recruiting on Auto Pilot whether they join your MLM or not!"=20 Welcome to 21st Century Massive Recruitment=2E=20 I encourage you to check the details and sign up immediately=2E That means NOW!=20 For more info please mail to mccuullen47@zonnet=2Enl and write your First Name + 'MORE INFO' in the subject line=2E You'll receive further instructions immediately=2E=20 Sincerely,=20 John McCuullen P=2ES=2E Don't forget to write your FIRST NAME + 'MORE INFO' In Subject line!=20 P=2EP=2ES=2E On the given site you'll find a secret that every PRO in our industry knows and uses=2E=2E=2E It's called: S-L-L-G: Self Liquidating Lead Generation=2E It will Create a Huge, Electrifying Surge in Your Cash Flow=2E=20 P=2EP=2EP=2ES=2E Find out the NEW 3 foot rule in MLM=2E "Why Old School MLM is nearly dead=2E"=20 From noreply@sourceforge.net Wed Dec 12 22:42:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 14:42:31 -0800 Subject: [Patches] [ python-Patches-476047 ] Zip importing; do NOT install Message-ID: Patches item #476047, was opened at 2001-10-29 08:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476047&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: Zip importing; do NOT install Initial Comment: Here is the zip importing implementation. Do not install, just look at it. A known bug is that a sys.path item "/A/arch.zip/Lib" fails. Patch is against 2.2a3. JimA ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-12 14:42 Message: Logged In: YES user_id=21627 Obsoleted by #492105. ---------------------------------------------------------------------- Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-11-07 07:08 Message: Logged In: YES user_id=64929 I have attached a second version of the patches to import.c. Do not install this either, but it is closer. The major change is the use of os.listdir() to list the files in directories, and the use of the resultant dictionary entries to speed up imports. Highly interesting is the use of Python module os.listdir() as part of the import process. This means that any Python module could be used as well, thus making possible the replacement of import.c by a custom importer after a boot phase. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-10-30 12:11 Message: Logged In: YES user_id=31392 I wonder if it would be better to do more of the work at the C level, rather than passing everything up to Python. The tuples that describe the ZIP file contents could be C structs and the actual retrieval could be written in C. I suspect it is worthwhile, since our goal is to make imports faster. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476047&group_id=5470 From noreply@sourceforge.net Wed Dec 12 22:44:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 14:44:09 -0800 Subject: [Patches] [ python-Patches-483466 ] Import from Zip Archive, Obsolete Message-ID: Patches item #483466, was opened at 2001-11-19 07:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: Import from Zip Archive, Obsolete Initial Comment: This is the "final" patch to import.c to support imports from zip archives and directory caching using os.listdir(). It replaces patch 476047. It it intended to be part of Python 2.3. There are five files requiring patches, and these are in context diff's in five separate attached files. I have tested this on Linux and Windows 2000. It needs testing on bigendian machines, and those with 64-bit integers. Please complain about bugs, but let me know if you plan to change the code. The documentation for the imp module needs a patch. This is added right after "PY_FROZEN": PY_ZIPFILE The module was found in a zip archive file. BUGS ==== There are a couple of bugs I wasn't sure were worth fixing. Please complain if these are a problem: The use of os.listdir() for normal directory imports makes case_ok() unnecessary, but it was not removed. It might be needed if os.listdir() is missing. There is no problem if os.listdir() doesn't exist, but if it exists, it must perform as documented, and must return both file and directory names in their correct case. The PYTHONCASEOK flag is ineffective. This is a consequence of dictionary name lookup. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-12 14:44 Message: Logged In: YES user_id=21627 Obsoleted by #492105. ---------------------------------------------------------------------- Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-11-30 08:41 Message: Logged In: YES user_id=64929 I added newer file versions to implement the changes discussed on python-dev. I still need to patch import.c to properly handle "" and relative paths in sys.path. The current changes are: 1) Creation of sys.path[0] is moved out of PySys_SetArgv() and into Py_GetPath(). Creation of the zip path is also moved into Py_GetPath(), so that all sys.path's are now in Py_GetPath(). 2) sys.path[0] is the absolute path of the Python script being run. For "-c" or an interactive interpreter, it remains "". There are two new Python API functions Py_SetScriptName() and Py_GetScriptName(). These are similar to the existing Py_[GS]etProgramName() functions, and are used for the same purpose, namely passing information to Py_GetPath(). All these functions are arguably hacks which should be replaced with additional arguments to Py_Initialize(). Here is the documentation: char* Py_GetScriptName () Return the script name set with Py_SetScriptName(), or NULL. The returned string points into static storage; the caller should not modify its value. void Py_SetScriptName (char *name) This is similar to Py_SetProgramName(), but tells the interpreter the file name of the Python script being run. This is used by Py_GetPath() to add the directory of the script to sys.path. If name is NULL no script item is added to sys.path. If name is "", the item "" will be added to sys.path, and "" means the current directory. Otherwise the absolute directory path will be added. The argument must point to a string in static storage whose contents will not change for the duration of the program's execution. ---------------------------------------------------------------------- Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-11-20 06:49 Message: Logged In: YES user_id=64929 The zero length string "" is not handled correctly as an item of sys.path. It should mean current directory, but its contents will not be cached. What happens if the current directory changes? Should the new directory be searched, or only the original current directory? I will submit a further patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470 From noreply@sourceforge.net Thu Dec 13 01:19:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 17:19:28 -0800 Subject: [Patches] [ python-Patches-492301 ] Fink Patch for Python 2.2 Message-ID: Patches item #492301, was opened at 2001-12-12 17:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=492301&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven J. Burr (sburrious) Assigned to: Jack Jansen (jackjansen) Summary: Fink Patch for Python 2.2 Initial Comment: Patch applied to Fink distribution of Python. Requested by Jack Jansen. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=492301&group_id=5470 From noreply@sourceforge.net Thu Dec 13 01:49:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 17:49:00 -0800 Subject: [Patches] [ python-Patches-492301 ] Fink Patch for Python 2.2 Message-ID: Patches item #492301, was opened at 2001-12-12 17:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=492301&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven J. Burr (sburrious) Assigned to: Jack Jansen (jackjansen) Summary: Fink Patch for Python 2.2 Initial Comment: Patch applied to Fink distribution of Python. Requested by Jack Jansen. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 17:49 Message: Logged In: YES user_id=6380 (Just curious - what kind of file format is this?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=492301&group_id=5470 From noreply@sourceforge.net Thu Dec 13 02:38:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 18:38:10 -0800 Subject: [Patches] [ python-Patches-492301 ] Fink Patch for Python 2.2 Message-ID: Patches item #492301, was opened at 2001-12-12 17:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=492301&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven J. Burr (sburrious) Assigned to: Jack Jansen (jackjansen) Summary: Fink Patch for Python 2.2 Initial Comment: Patch applied to Fink distribution of Python. Requested by Jack Jansen. ---------------------------------------------------------------------- >Comment By: Steven J. Burr (sburrious) Date: 2001-12-12 18:38 Message: Logged In: YES user_id=322368 I didn't prepare the patch, but I think it's the "unified" format for diff files. This particular patch is used by "fink," a command line tool for automating the installation of open source software, including the Unix version of Python, on Mac OS X. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 17:49 Message: Logged In: YES user_id=6380 (Just curious - what kind of file format is this?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=492301&group_id=5470 From noreply@sourceforge.net Thu Dec 13 14:19:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 06:19:25 -0800 Subject: [Patches] [ python-Patches-488749 ] MacOS 8.1 support in IDE, W Message-ID: Patches item #488749, was opened at 2001-12-03 22:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 Category: Macintosh Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) Assigned to: Just van Rossum (jvr) Summary: MacOS 8.1 support in IDE, W Initial Comment: These patches allow the IDE and W framework to continue working under MacOS 8.1. All calls to (Get|Set)ControlViewSize are allowed to silently fail with a NotImplementedError - they're only relevant with proportional scrollbars, which appeared in 8.5. 8.1 doesn't support (Get|Set)Control32Bit(Value|Minimum| Maximum), so always use or fall back to the original 16- bit versions when possible. (The 16-bit calls are listed as fully supported under Carbon, so this shouldn't introduce any compatibility problems.) The only time a control is likely to need a full 32-bit parameter is a scrollbar for a very tall document: errors will occur when trying to edit a file taller than 32K pixels (2500+ lines of 9-point text) under 8.1, but this bug doesn't prevent the file from being saved. Made 32-bit control parameters work better on the system versions that do support them: large values can be passed to the ControlWidget constructor, in which case NewControl is called with zeros, and the actual value then set via a 32-bit call. Changed Wtext's scrollbar routines to explicitly disable scrollbars when their max is <= their min (which is automatically done in later systems, I don't think there will be any problem with this being done twice). Fixed up Appearance support for Wlists, they now fully use Appearance frames & focusing. Tried to do the same for Wtext, but ran into some problems - there are lots of places that assume that an EditText's border is exactly one pixel thick and located just inside the widget bounds (for example, the line number field in PyEditor windows). I left my commented- out changes in the code for the benefit of anyone who tries to fix this later, but for now the frame of EditText boxes is still a Qd.FrameRect. I have NOT tested these patches with anything except 8.1. Running the Panes or Two Lists widget demo, and tabbing/resizing/deactivating/activating the window, will exercise most of the changes I've made. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 05:31 Message: Logged In: YES user_id=45365 Checked in, and done minimal testing (IDE still runs:-), I'll leave real testing and possibly integration of the Wtext mods to you. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 04:01 Message: Logged In: YES user_id=45365 I'll check it in and assign it back to you (Just) for testing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2001-12-04 03:59 Message: Logged In: YES user_id=92689 Thanks for this patch: looks good to me. Jack: is it easy for you to check it in? For me it's not. Alternatively: Jason: could you send me the modified files? Thanks. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 03:28 Message: Logged In: YES user_id=45365 Just, I had a quick look at this patch (only a look, not tried it) and to me it looks fine. Jason did this patch on my request, so that 2.2 will run on MacOS 8.1 (it'll be the last MacPython to run on that system). Could you have a look at these and apply them, or assign them back to me if you don't have the time? You definitely should have a look at the frame stuff, which is over my head. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488749&group_id=5470 From noreply@sourceforge.net Thu Dec 13 19:09:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 11:09:21 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Later >Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Jeremy Hylton (jhylton) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-13 11:09 Message: Logged In: YES user_id=31392 I'm not comfortable making changes like this with only the release candidate for testing. I think we should postpone until 2.3. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-04 21:09 Message: Logged In: YES user_id=55188 Oops! sorry. It was a mistake. changed to corrected patch. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-03 20:14 Message: Logged In: YES user_id=55188 On the ENOTCONN error: the error will be raised only if 'sock' was bound outside. (even if self.accepting get set) but using out-bound socket is unavoidable for some server models. and I and some co-workers are using it. How about this way instead of previous patch? if not self.accepting: self.addr = sock.getpeername() On passing maps: some part of asyncore supports using own socket map. (__init__, add_channel, del_channel), but when __init__ registers socket into map which passed by argument, asyncore can't del_channel from own map and it will raises KeyError because asyncore.socket_map doesn't have such fileno. And, current version of asynchat doesn't support to use another maps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:03 Message: Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Thu Dec 13 19:58:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 11:58:59 -0800 Subject: [Patches] [ python-Patches-479551 ] fix complex() with 2 string args Message-ID: Patches item #479551, was opened at 2001-11-08 05:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fix complex() with 2 string args Initial Comment: reported on c.l.py >>> complex ("1", "1") (1+0j) >From my reading of the docs, this should fail. Patch does this, adds test case. Assigned to Fred, largely at random. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-13 11:58 Message: Logged In: YES user_id=3066 Checked in a variant of Skip's patch as Objects/complexobject.c revision 2.53, Lib/test/test_b1.py revision 1.42, and Doc/lib/libfuncs.tex revision 1.99. The tests for this were moved to test_b1.py since these are basic constructor tests and not advanced complex math tests. I made the constructor raise TypeError instead of ValueError as was done in the patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 21:46 Message: Logged In: YES user_id=3066 The documentation updates should be made for Python 2.2; I can work with Tim on this on Thursday to make sure this is right. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-08 10:00 Message: Logged In: YES user_id=31435 Note that 2.2 complex also accepts keyword "real" and "imag" arguments; if we're changing the docs anyway, may as well sneak that in too. BTW, I'm really surprised nobody complained about this : >>> complex(1, 1j) 0j >>> Alas, that's "a feature". ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-08 08:02 Message: Logged In: YES user_id=44345 Yeah, I didn't think they were that different. I had already completed (but not completed testing) my patch when I saw your c.l.py patch. Once I completed testing I simple wrapped it up and uploaded it. I figure Fred can merge our two versions as well as we can. ;-) (As for diff-mode, it's likely the same thing as in Emacs 21.1, but XEmacs 21.1 didn't have a diff mode at all, so I was quite surprised the other day after upgrading to XEmacs 21.4 when I visited a .diff file and had it pop into diff-mode. Today, to create my complex patch, I just cvs diff'd the entire Python tree, edited the file in diff-mode and used M-k/M-n to migrate around, deleting the stuff unrelated to this patch. I didn't have to figure out what lines to cut. When I deleted the last chunk for a particular file it automatically zapped the file's header as well. I was in diff heaven... ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-11-08 07:47 Message: Logged In: YES user_id=6656 Agree with your changes to complexobject.c, though they're not v. different from mine. Your tests reproduce what's in test_b1.py so are probably redunant. I don't think you can read the current docs with your head screwed on and get the wrong idea, but am willing to defer to Fred on that one... What does XEmacs 21.4's diff-mode do that GNU Emacs 21.1's doesn't? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-08 07:31 Message: Logged In: YES user_id=44345 I have a slightly different patch. If the first arg is not a string, the second arg can't be a string. The current implementation raises a TypeError with a not entirely comprehensible message, so I added a special case to catch that. Also, my test cases are in test_complex.py instead of test_b1.py and I have some doc changes. (God, I just *loooove* the new diff-mode in XEmacs 21.4. Ya gotta try it -- if you're not a vi-head, that is!) ---------------------------------------------------------------------- Comment By: Grant Griffin (dspguru) Date: 2001-11-08 07:13 Message: Logged In: YES user_id=70844 I agree with the discussion on c.l.py as to the interpretation of the docs, so it sounds like Michael's patch is a good thing. However, along with the patch, I'd like to see the docs clarified a little. Specifically, it would be nice if the docs stated that the imaginary part (if any) can be specified as part of the string using the standard "j" suffix: ActivePython 2.1.1, build 212 (ActiveState) >>> complex('1+1j') (1+1j) This feature appears to be the reason that a separate imaginary argument was disallowed in the string case, so spelling that aspect out will help people understand (and therefore remember) the rules on this. =g2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 From noreply@sourceforge.net Thu Dec 13 20:43:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 12:43:38 -0800 Subject: [Patches] [ python-Patches-489066 ] Include RLIM_INFINITY constant Message-ID: Patches item #489066, was opened at 2001-12-04 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489066&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Later >Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Jeremy Hylton (jhylton) Summary: Include RLIM_INFINITY constant Initial Comment: The following is a patch to the resource module to include the RLIM_INFINITY constant. It should handle platforms where RLIM_INFINITY is not a LONG_LONG, but I have no means to test that. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-13 12:43 Message: Logged In: YES user_id=31392 I'd rather see this go through a beta release where we can verify that it works for both the LONG_LONG and non-LONG_LONG cases. Among other things, it looks possible (though probably unlikely) that there are platforms that do not have long long and do not representation rlim_t as long. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:24 Message: Logged In: YES user_id=6380 Jeremy, please review and apply or reject (or postpone and lower priority). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489066&group_id=5470 From noreply@sourceforge.net Thu Dec 13 22:05:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 14:05:48 -0800 Subject: [Patches] [ python-Patches-492301 ] Fink Patch for Python 2.2 Message-ID: Patches item #492301, was opened at 2001-12-12 17:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=492301&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Steven J. Burr (sburrious) Assigned to: Jack Jansen (jackjansen) Summary: Fink Patch for Python 2.2 Initial Comment: Patch applied to Fink distribution of Python. Requested by Jack Jansen. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-13 14:05 Message: Logged In: YES user_id=45365 Steve, I'm afraid I can't accept these patches as-is. There's a couple of problems with them (aside from the file format, what is it, MacBinary? AppleSingle?). Also, I think most of the issues, except the /sw one, which should probably be fink-specific anyway, are solved with the current cvs tree. If not please let me know. The patch the the $(PGEN) line in Makefile.pre.in will not work, the LDFLAGS are specifically for Python itself, they may contain stuff for creating a framework, etc. The CPPFLAGS patch is probably fink-specific, the syntaxt I haven't seen before. The /sw convention in setup.py looks interesting, but I'm not sure whether this is a fink-only thing. The configure patch should be to configure.in (which is the sourcefile), and moreover I don't agree with it. Removing -ltermcap unconditionally will break builds on other platforms, which do need termcap. ---------------------------------------------------------------------- Comment By: Steven J. Burr (sburrious) Date: 2001-12-12 18:38 Message: Logged In: YES user_id=322368 I didn't prepare the patch, but I think it's the "unified" format for diff files. This particular patch is used by "fink," a command line tool for automating the installation of open source software, including the Unix version of Python, on Mac OS X. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 17:49 Message: Logged In: YES user_id=6380 (Just curious - what kind of file format is this?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=492301&group_id=5470 From noreply@sourceforge.net Thu Dec 13 23:57:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 15:57:27 -0800 Subject: [Patches] [ python-Patches-476814 ] foreign-platform newline support Message-ID: Patches item #476814, was opened at 2001-10-31 08:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476814&group_id=5470 >Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: foreign-platform newline support Initial Comment: This patch enables Python to interpret all known newline conventions, CR, LF or CRLF, on all platforms. This support is enabled by configuring with --with-universal-newlines (so by default it is off, and everything should behave as usual). With universal newline support enabled two things happen: - When importing or otherwise parsing .py files any newline convention is accepted. - Python code can pass a new "t" mode parameter to open() which reads files with any newline convention. "t" cannot be combined with any other mode flags like "w" or "+", for obvious reasons. File objects have a new attribute "newlines" which contains the type of newlines encountered in the file (or None when no newline has been seen, or "mixed" if there were various types of newlines). Also included is a test script which tests both file I/O and parsing. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-13 15:57 Message: Logged In: YES user_id=31435 Back to Jack -- and sorry for sitting on it so long. Clearly this isn't making it into 2.2 in the core. As I said on Python-Dev, I believe this needs a PEP: the design decisions are debatable, so *should* be debated outside the Mac community too. Note, though, that I can't stop you from adding it to the 2.2 Mac distribution (if you want it badly enough there). If a PEP won't be written, I suggest finding someone else to review it again; maybe Guido. Note that the patch needs doc changes too. The patch to regrtest.py doesn't belong here (I assume it just slipped in). There seems a lot of code in support of the f_newlinetypes member, and the value of that member isn't clear -- I can't imagine a good use for it (maybe it's a Mac thing?). The implementation of Py_UniversalNewlineFread appears incorrect to me: it reads n bytes *every* time around the outer loop, no matter how few characters are still required, and n doesn't change inside the loop. The business about the GIL may be due to the lack of docs: are, or are not, people supposed to release the GIL themselves around calls to these guys? It's not documented, and it appears your intent differed from my guess. Finally, it would be better to call ferror () after calling fread() instead of before it . ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-14 07:13 Message: Logged In: YES user_id=45365 Here's a new version of the patch. To address your issues one by one: - get_line and Py_UniversalNewlineFgets are too difficult to integrate, at leat, I don't see how I could do it. The storage management of get_line gets in the way. - The global lock comment I don't understand. The Universal... routines are replacements for fgets() and fread(), so have nothing to do with the interpreter lock. - The logic of all three routines (get_line too) has changed and I've put comments in. I hope this addresses some of the points. - If universal_newline is false for a certain PyFileObject we now immedeately take a quick exit via fgets() or fread(). There's also a new test script, that tests some more border cases (like lines longer than 100 characters, and a lone CR just before end of file). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-05 00:16 Message: Logged In: YES user_id=31435 It would be better if get_line just called Py_UniversalNewlineFgets (when appropriate) instead of duplicating its logic inline. Py_UniversalNewlineFgets and Py_UniversalNewlineFread should deal with releasing the global lock themselves -- the correct granularity for lock release/reacquire is around the C-level input routines (esp. for fread). The new routines never check for I/O errors! Why not? It seems essential. The new Fgets checks for EOF at the end of the loop instead of the top. This is surprising, and I stared a long time in vain trying to guess why. Setting newlinetypes |= NEWLINE_CR; immediately after seeing an '\r' would be as fast (instead of waiting to see EOF and then inferring the prior existence of '\r' indirectly from the state of the skipnextlf flag). Speaking of which , the fobj tests in the inner loop waste cycles. Set the local flag vrbls whether or not fobj is NULL. When you're *out* of the inner loop you can simply decline to store the new masks when fobj is NULL (and you're already doing the latter anyway). A test and branch inside the loop is much more expensive than or'ing in a flag bit inside the loop, ditto harder to understand. Floating the univ_newline test out of the loop (and duplicating the loop body, one way for univ_newline true and the other for it false) would also save a test and branch on every character. Doing fread one character at a time is very inefficient. Since you know you need to obtain n characters in the end, and that these transformations require reading at least n characters, you could very profitably read n characters in one gulp at the start, then switch to k at a time where k is the number of \r\n pairs seen since the last fread call. This is easier to code than it sounds . It would be fine by me if you included (and initialized) the new file-object fields all the time, whether or not universal newlines are configured. I'd rather waste a few bytes in a file object than see #ifdefs spread thru the code. I'll be damned if I can think of a quick way to do this stuff on Windows -- native Windows fgets() is still the only Windows handle we have on avoiding crushing thread overhead inside MS's C library. I'll think some more about it (the thrust still being to eliminate the 't' mode flag, as whined about on Python-Dev). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 09:38 Message: Logged In: YES user_id=6380 Tim, can you review this or pass it on to someone else who has time? Jack developed this patch after a discussion in which I was involved in some of the design, but I won't have time to look at it until December. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476814&group_id=5470 From noreply@sourceforge.net Fri Dec 14 04:39:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 20:39:57 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Later Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Jeremy Hylton (jhylton) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2001-12-13 20:39 Message: Logged In: YES user_id=55188 But, failure of sock.getpeername() is fatal for me. It interrupts initializing dispatcher class on programs which runs perfectly on all of past versions of Python. Without this patch, difference between 1.19 and 1.20 of asyncore.py must be rollbacked. (It is not important feature but fancy for __repr__) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-13 11:09 Message: Logged In: YES user_id=31392 I'm not comfortable making changes like this with only the release candidate for testing. I think we should postpone until 2.3. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-04 21:09 Message: Logged In: YES user_id=55188 Oops! sorry. It was a mistake. changed to corrected patch. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-03 20:14 Message: Logged In: YES user_id=55188 On the ENOTCONN error: the error will be raised only if 'sock' was bound outside. (even if self.accepting get set) but using out-bound socket is unavoidable for some server models. and I and some co-workers are using it. How about this way instead of previous patch? if not self.accepting: self.addr = sock.getpeername() On passing maps: some part of asyncore supports using own socket map. (__init__, add_channel, del_channel), but when __init__ registers socket into map which passed by argument, asyncore can't del_channel from own map and it will raises KeyError because asyncore.socket_map doesn't have such fileno. And, current version of asynchat doesn't support to use another maps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:03 Message: Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Fri Dec 14 15:14:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 07:14:05 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Later >Priority: 7 Submitted By: Hye-Shik Chang (perky) Assigned to: Jeremy Hylton (jhylton) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-14 07:14 Message: Logged In: YES user_id=31392 I see. It was hard to tell what was bug and what was feature. It does sound like you've identified a bug introduced during 2.2 development. I'll see if it's not too late. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-13 20:39 Message: Logged In: YES user_id=55188 But, failure of sock.getpeername() is fatal for me. It interrupts initializing dispatcher class on programs which runs perfectly on all of past versions of Python. Without this patch, difference between 1.19 and 1.20 of asyncore.py must be rollbacked. (It is not important feature but fancy for __repr__) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-13 11:09 Message: Logged In: YES user_id=31392 I'm not comfortable making changes like this with only the release candidate for testing. I think we should postpone until 2.3. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-04 21:09 Message: Logged In: YES user_id=55188 Oops! sorry. It was a mistake. changed to corrected patch. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-03 20:14 Message: Logged In: YES user_id=55188 On the ENOTCONN error: the error will be raised only if 'sock' was bound outside. (even if self.accepting get set) but using out-bound socket is unavoidable for some server models. and I and some co-workers are using it. How about this way instead of previous patch? if not self.accepting: self.addr = sock.getpeername() On passing maps: some part of asyncore supports using own socket map. (__init__, add_channel, del_channel), but when __init__ registers socket into map which passed by argument, asyncore can't del_channel from own map and it will raises KeyError because asyncore.socket_map doesn't have such fileno. And, current version of asynchat doesn't support to use another maps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:03 Message: Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Fri Dec 14 15:21:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 07:21:19 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Later Priority: 7 Submitted By: Hye-Shik Chang (perky) Assigned to: Jeremy Hylton (jhylton) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-14 07:21 Message: Logged In: YES user_id=31392 The dispatcher constructor sets connected to 1 when you pass it a socket. This suggests to me that the contract is that you only pass a connected socket to dispatcher. Is this what you're doing? If not, perhaps you need to create a subclass of dispatcher that behaves appropriately for non-connected sockets. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-14 07:14 Message: Logged In: YES user_id=31392 I see. It was hard to tell what was bug and what was feature. It does sound like you've identified a bug introduced during 2.2 development. I'll see if it's not too late. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-13 20:39 Message: Logged In: YES user_id=55188 But, failure of sock.getpeername() is fatal for me. It interrupts initializing dispatcher class on programs which runs perfectly on all of past versions of Python. Without this patch, difference between 1.19 and 1.20 of asyncore.py must be rollbacked. (It is not important feature but fancy for __repr__) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-13 11:09 Message: Logged In: YES user_id=31392 I'm not comfortable making changes like this with only the release candidate for testing. I think we should postpone until 2.3. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-04 21:09 Message: Logged In: YES user_id=55188 Oops! sorry. It was a mistake. changed to corrected patch. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-03 20:14 Message: Logged In: YES user_id=55188 On the ENOTCONN error: the error will be raised only if 'sock' was bound outside. (even if self.accepting get set) but using out-bound socket is unavoidable for some server models. and I and some co-workers are using it. How about this way instead of previous patch? if not self.accepting: self.addr = sock.getpeername() On passing maps: some part of asyncore supports using own socket map. (__init__, add_channel, del_channel), but when __init__ registers socket into map which passed by argument, asyncore can't del_channel from own map and it will raises KeyError because asyncore.socket_map doesn't have such fileno. And, current version of asynchat doesn't support to use another maps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:03 Message: Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Fri Dec 14 16:25:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 08:25:08 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Later Priority: 7 Submitted By: Hye-Shik Chang (perky) Assigned to: Jeremy Hylton (jhylton) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2001-12-14 08:25 Message: Logged In: YES user_id=55188 Hmm. thanks for your appreciation. ;) I'm using this way for non-connected sockets. class asyncore_accepting_mixin: def __init__(self, sock=None, map=None): if map is not None: self.map = map asyncore.dispatcher.__init__(self, sock, map) self.connected = 0 self.accepting = 1 I call asyncore.dispatcher.__init__ for adapting any version of asyncore. I thought this way: def __init__(.... of subclass or mixin.. try: asyncore.dispatcher.__init__(self, sock, map) except socket.error, why: if why[0] != ENOTCONN: raise socket.error, why but, this can be reasonable only if sock.getpeername() is on last line of __init__. So, subclass can't use dispatch.__init__ clearly on this condition. Anyway, thanks for your help and commit. ;) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-14 07:21 Message: Logged In: YES user_id=31392 The dispatcher constructor sets connected to 1 when you pass it a socket. This suggests to me that the contract is that you only pass a connected socket to dispatcher. Is this what you're doing? If not, perhaps you need to create a subclass of dispatcher that behaves appropriately for non-connected sockets. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-14 07:14 Message: Logged In: YES user_id=31392 I see. It was hard to tell what was bug and what was feature. It does sound like you've identified a bug introduced during 2.2 development. I'll see if it's not too late. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-13 20:39 Message: Logged In: YES user_id=55188 But, failure of sock.getpeername() is fatal for me. It interrupts initializing dispatcher class on programs which runs perfectly on all of past versions of Python. Without this patch, difference between 1.19 and 1.20 of asyncore.py must be rollbacked. (It is not important feature but fancy for __repr__) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-13 11:09 Message: Logged In: YES user_id=31392 I'm not comfortable making changes like this with only the release candidate for testing. I think we should postpone until 2.3. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-04 21:09 Message: Logged In: YES user_id=55188 Oops! sorry. It was a mistake. changed to corrected patch. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-03 20:14 Message: Logged In: YES user_id=55188 On the ENOTCONN error: the error will be raised only if 'sock' was bound outside. (even if self.accepting get set) but using out-bound socket is unavoidable for some server models. and I and some co-workers are using it. How about this way instead of previous patch? if not self.accepting: self.addr = sock.getpeername() On passing maps: some part of asyncore supports using own socket map. (__init__, add_channel, del_channel), but when __init__ registers socket into map which passed by argument, asyncore can't del_channel from own map and it will raises KeyError because asyncore.socket_map doesn't have such fileno. And, current version of asynchat doesn't support to use another maps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:03 Message: Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Fri Dec 14 20:53:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 12:53:21 -0800 Subject: [Patches] [ python-Patches-493452 ] docstrings for staticmethod/classmethod Message-ID: Patches item #493452, was opened at 2001-12-14 12:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493452&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: docstrings for staticmethod/classmethod Initial Comment: Attached is a context diff for funcobject.c that adds docstrings to staticmethod & classmethod. I simply adapted comments in the source code. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493452&group_id=5470 From noreply@sourceforge.net Fri Dec 14 20:58:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 12:58:46 -0800 Subject: [Patches] [ python-Patches-493452 ] docstrings for staticmethod/classmethod Message-ID: Patches item #493452, was opened at 2001-12-14 12:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493452&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Skip Montanaro (montanaro) >Assigned to: Guido van Rossum (gvanrossum) Summary: docstrings for staticmethod/classmethod Initial Comment: Attached is a context diff for funcobject.c that adds docstrings to staticmethod & classmethod. I simply adapted comments in the source code. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493452&group_id=5470 From newsletters@the-financial-news.org Thu Dec 13 19:07:28 2001 From: newsletters@the-financial-news.org (The Financial News) Date: Thu, 13 Dec 2001 20:07:28 +0100 Subject: [Patches] Production Mini-plants in mobile containers. Co-investment Program Message-ID: This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Financial News, December 2001 Production Mini-plants in mobile containers. Co-investment Program =22...Science Network will supply to countries and developing regions the technology and the necessary support for the production in series of Mini-plants in mobile=20containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring,=20piping, and installation parts; that is to say, they are fully equipped... and the mini-plant is ready for production.=22 More than 700 portable production systems: Bakeries, Steel Nails, Welding Electrodes, Tire Retreading, Reinforcement Bar Bending for Construction Framework,=20Sheeting for Roofing, Ceilings and Fa=E7ades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasses, Cups,=20Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Mobile units of medical assistance, Sanitary Material,=20Hypodermic Syringes, Hemostatic Clamps, etc.=20 Science Network has started a process of Co-investment for the installation of small Assembly plants to manufacture in series the Mini-plants of portable=20production on the site, region or country where they may be required. One of the most relevant features is the fact that these plants will be connected to the World=20Trade System (WTS) with access to more than 50 million raw materials, products and services and automatic transactions for world trade. Because of financial reasons, involving cost and social impact, the right thing to do is to set up assembly plants in the same countries and regions, using local=20resources (labor, some equipment, etc.) For more information: Mini-plants in mobile containers By Steven P. Leibacher, The Financial News, Editor Mini-plantas de produccion en contenedores moviles. Programa de Co-inversion =22...Science Network suministrara a paises y regiones en vias de desarrollo la tecnologia y el apoyo necesario para la fabricacion en serie de Mini-plantas de=20produccion en contenedores moviles (40-foot). El sistema de mini-plantas esta dise=F1ado de forma que todas las maquinas de produccion van instaladas fijas=20sobre la propia plataforma del contenedor, con el cableado, tuberias e instalaciones; es decir, completamente equipadas... y a partir de ese momento est=E1n listas=20para producir.=22=20 Mas de 700 sistemas de produccion portatil: Panaderias, Producci=F3n de clavos de acero, Electrodos para soldadura, Recauchutado de neumaticos, Curvado de=20hierro para armaduras de construccion, Lamina perfilada para cubiertas, techos y cerramientos de fachada, Bidones de chapa, Cubos de aluminio, Menaje de=20polipropileno inyectado, Piezas de melamina prensada (vasos, platos, tazas, cafeteras, etc.) Silenciadores para vehiculos, Malla electrosoldada para la=20construccion, Bolsas y envases de plastico, Unidades moviles de asistencia medica, Material sanitario (jeringas hipodermicas, Pinzas hemostaticas, etc.) Science Network ha puesto en marcha un proceso de Co-inversion para la instalacion de peque=F1as Plantas ensambladoras para fabricar en serie las Mini-plantas=20de produccion portatil, en el lugar, region o pais que lo necesite. Una de las caracter=EDsticas relevantes es el hecho de que dichas plantas quedaran conectadas al=20Sistema del Comercio Mundial (WTS) con acceso a mas de 50 millones de mercancias, materia primas, productos, servicios y las operaciones automaticas de=20comercio internacional.=20 Resulta obvio que por razones economicas, de costes y de impacto social, lo apropiado es instalar plantas ensambladoras en los mismos paises y regiones asi=20como utilizar los recursos locales (mano de obra, ciertos equipamientos, etc.) Para recibir mas infromacion: Mini-plantas de produccion en contenedores moviles Steven P. Leibacher, The Financial News, Editor ------------------------------------------------------------------------- If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in 'subject' field, Thanks. Editor =A9 2001 The Financial News. All rights reserved. --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The Financial News, December 2001

Production Mini-plants in mobile containers. Co-investment Program

=22...Science Network will supply to countries and developing regions the technology and the necessary support for the production in series of Mini-plants in mobile containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring, piping, and installation parts; that is to say, they are fully equipped... and the mini-plant is ready for production.=22

More than 700 portable production systems: Bakeries, Steel Nails, Welding Electrodes, Tire Retreading, Reinforcement Bar Bending for Construction Framework, Sheeting for Roofing, Ceilings and Façades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasses, Cups, Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Mobile units of medical assistance, Sanitary Material, Hypodermic Syringes, Hemostatic Clamps, etc.

Science Network has started a process of Co-investment for the installation of small Assembly plants to manufacture in series the Mini-plants of portable production on the site, region or country where they may be required. One of the most relevant features is the fact that these plants will be connected to the World Trade System (WTS) with access to more than 50 million raw materials, products and services and automatic transactions for world trade.

Because of financial reasons, involving cost and social impact, the right thing to do is to set up assembly plants in the same countries and regions, using local resources (labor, some equipment, etc.)

For more information: Mini-plants in mobile containers

By Steven P. Leibacher, The Financial News, Editor


Mini-plantas de produccion en contenedores moviles. Programa de Co-inversion

=22...Science Network suministrara a paises y regiones en vias de desarrollo la tecnologia y el apoyo necesario para la fabricacion en serie de Mini-plantas de produccion en contenedores moviles (40-foot). El sistema de mini-plantas esta diseñado de forma que todas las maquinas de produccion van instaladas fijas sobre la propia plataforma del contenedor, con el cableado, tuberias e instalaciones; es decir, completamente equipadas... y a partir de ese momento están listas para producir.=22

Mas de 700 sistemas de produccion portatil: Panaderias, Producción de clavos de acero, Electrodos para soldadura, Recauchutado de neumaticos, Curvado de hierro para armaduras de construccion, Lamina perfilada para cubiertas, techos y cerramientos de fachada, Bidones de chapa, Cubos de aluminio, Menaje de polipropileno inyectado, Piezas de melamina prensada (vasos, platos, tazas, cafeteras, etc.) Silenciadores para vehiculos, Malla electrosoldada para la construccion, Bolsas y envases de plastico, Unidades moviles de asistencia medica, Material sanitario (jeringas hipodermicas, Pinzas hemostaticas, etc.)

Science Network ha puesto en marcha un proceso de Co-inversion para la instalacion de pequeñas Plantas ensambladoras para fabricar en serie las Mini-plantas de produccion portatil, en el lugar, region o pais que lo necesite. Una de las características relevantes es el hecho de que dichas plantas quedaran conectadas al Sistema del Comercio Mundial (WTS) con acceso a mas de 50 millones de mercancias, materia primas, productos, servicios y las operaciones automaticas de comercio internacional.

Resulta obvio que por razones economicas, de costes y de impacto social, lo apropiado es instalar plantas ensambladoras en los mismos paises y regiones asi como utilizar los recursos locales (mano de obra, ciertos equipamientos, etc.)

Para recibir mas infromacion: Mini-plantas de produccion en contenedores moviles

Steven P. Leibacher, The Financial News, Editor

-------------------------------------------------------------------------
If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in 'subject' field, Thanks. Editor
© 2001 The Financial News. All rights reserved.




 --=_NextPart_2rfkindysadvnqw3nerasdf-- From noreply@sourceforge.net Sat Dec 15 20:54:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 12:54:56 -0800 Subject: [Patches] [ python-Patches-493739 ] 2 Bugfixes for 2.2c1 (RISC OS specific) Message-ID: Patches item #493739, was opened at 2001-12-15 12:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493739&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) Assigned to: Nobody/Anonymous (nobody) Summary: 2 Bugfixes for 2.2c1 (RISC OS specific) Initial Comment: 2 fixes: RISCOS/Modules/getpath_riscos.c: Include trailing '\0' when using strncpy [copy strlen(...)+1 characters]. Lib/plat-riscos/riscospath.py: Use riscosmodule.expand for os.path.abspath. [fixes problems with site.py where abspath("") returned join(os.getcwd(), "") as e.g. "SCSI::SCSI4.$." because "" wasn't recognised as an absolute path.] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493739&group_id=5470 From noreply@sourceforge.net Sat Dec 15 22:07:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 14:07:26 -0800 Subject: [Patches] [ python-Patches-493739 ] 2 Bugfixes for 2.2c1 (RISC OS specific) Message-ID: Patches item #493739, was opened at 2001-12-15 12:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493739&group_id=5470 Category: Core (C code) >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) >Assigned to: Tim Peters (tim_one) Summary: 2 Bugfixes for 2.2c1 (RISC OS specific) Initial Comment: 2 fixes: RISCOS/Modules/getpath_riscos.c: Include trailing '\0' when using strncpy [copy strlen(...)+1 characters]. Lib/plat-riscos/riscospath.py: Use riscosmodule.expand for os.path.abspath. [fixes problems with site.py where abspath("") returned join(os.getcwd(), "") as e.g. "SCSI::SCSI4.$." because "" wasn't recognised as an absolute path.] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-15 14:07 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493739&group_id=5470 From noreply@sourceforge.net Sat Dec 15 22:13:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 14:13:49 -0800 Subject: [Patches] [ python-Patches-493739 ] 2 Bugfixes for 2.2c1 (RISC OS specific) Message-ID: Patches item #493739, was opened at 2001-12-15 12:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493739&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) Assigned to: Tim Peters (tim_one) Summary: 2 Bugfixes for 2.2c1 (RISC OS specific) Initial Comment: 2 fixes: RISCOS/Modules/getpath_riscos.c: Include trailing '\0' when using strncpy [copy strlen(...)+1 characters]. Lib/plat-riscos/riscospath.py: Use riscosmodule.expand for os.path.abspath. [fixes problems with site.py where abspath("") returned join(os.getcwd(), "") as e.g. "SCSI::SCSI4.$." because "" wasn't recognised as an absolute path.] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-15 14:13 Message: Logged In: YES user_id=31435 Thanks! Applied the patches to Lib/plat-riscos/riscospath.py; new revision: 1.8 RISCOS/Modules/getpath_riscos.c; new revision: 1.5 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 14:07 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493739&group_id=5470 From noreply@sourceforge.net Mon Dec 17 01:05:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 17:05:59 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Later >Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Jeremy Hylton (jhylton) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-14 08:25 Message: Logged In: YES user_id=55188 Hmm. thanks for your appreciation. ;) I'm using this way for non-connected sockets. class asyncore_accepting_mixin: def __init__(self, sock=None, map=None): if map is not None: self.map = map asyncore.dispatcher.__init__(self, sock, map) self.connected = 0 self.accepting = 1 I call asyncore.dispatcher.__init__ for adapting any version of asyncore. I thought this way: def __init__(.... of subclass or mixin.. try: asyncore.dispatcher.__init__(self, sock, map) except socket.error, why: if why[0] != ENOTCONN: raise socket.error, why but, this can be reasonable only if sock.getpeername() is on last line of __init__. So, subclass can't use dispatch.__init__ clearly on this condition. Anyway, thanks for your help and commit. ;) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-14 07:21 Message: Logged In: YES user_id=31392 The dispatcher constructor sets connected to 1 when you pass it a socket. This suggests to me that the contract is that you only pass a connected socket to dispatcher. Is this what you're doing? If not, perhaps you need to create a subclass of dispatcher that behaves appropriately for non-connected sockets. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-14 07:14 Message: Logged In: YES user_id=31392 I see. It was hard to tell what was bug and what was feature. It does sound like you've identified a bug introduced during 2.2 development. I'll see if it's not too late. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-13 20:39 Message: Logged In: YES user_id=55188 But, failure of sock.getpeername() is fatal for me. It interrupts initializing dispatcher class on programs which runs perfectly on all of past versions of Python. Without this patch, difference between 1.19 and 1.20 of asyncore.py must be rollbacked. (It is not important feature but fancy for __repr__) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-13 11:09 Message: Logged In: YES user_id=31392 I'm not comfortable making changes like this with only the release candidate for testing. I think we should postpone until 2.3. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-04 21:09 Message: Logged In: YES user_id=55188 Oops! sorry. It was a mistake. changed to corrected patch. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-03 20:14 Message: Logged In: YES user_id=55188 On the ENOTCONN error: the error will be raised only if 'sock' was bound outside. (even if self.accepting get set) but using out-bound socket is unavoidable for some server models. and I and some co-workers are using it. How about this way instead of previous patch? if not self.accepting: self.addr = sock.getpeername() On passing maps: some part of asyncore supports using own socket map. (__init__, add_channel, del_channel), but when __init__ registers socket into map which passed by argument, asyncore can't del_channel from own map and it will raises KeyError because asyncore.socket_map doesn't have such fileno. And, current version of asynchat doesn't support to use another maps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 03:03 Message: Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Mon Dec 17 02:15:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 18:15:10 -0800 Subject: [Patches] [ python-Patches-494045 ] patches errno and stat to cope on plan9 Message-ID: Patches item #494045, was opened at 2001-12-16 18:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494045&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: Nobody/Anonymous (nobody) Summary: patches errno and stat to cope on plan9 Initial Comment: Small #ifdefed patches to handle differences between the Plan 9 API and the traditional Posix API. The patch to bltinmodule.c also attempts to make the #ifdefs a little more readable. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494045&group_id=5470 From noreply@sourceforge.net Mon Dec 17 02:18:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 18:18:33 -0800 Subject: [Patches] [ python-Patches-494047 ] removes 64-bit ?: to cope on plan9 Message-ID: Patches item #494047, was opened at 2001-12-16 18:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494047&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: Nobody/Anonymous (nobody) Summary: removes 64-bit ?: to cope on plan9 Initial Comment: The Plan 9 C compiler can't handle 64-bit numbers as the branches of a ternary operation. Rewrite a ? b : c into if (a) then b else c in two places. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494047&group_id=5470 From noreply@sourceforge.net Mon Dec 17 02:21:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 18:21:27 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: Nobody/Anonymous (nobody) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 02:49:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 18:49:38 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) >Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 02:54:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 18:54:14 -0800 Subject: [Patches] [ python-Patches-493452 ] docstrings for staticmethod/classmethod Message-ID: Patches item #493452, was opened at 2001-12-14 12:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493452&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Skip Montanaro (montanaro) Assigned to: Guido van Rossum (gvanrossum) Summary: docstrings for staticmethod/classmethod Initial Comment: Attached is a context diff for funcobject.c that adds docstrings to staticmethod & classmethod. I simply adapted comments in the source code. Skip ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:54 Message: Logged In: YES user_id=6380 Applied with minor variation. Thanks, Skip! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=493452&group_id=5470 From noreply@sourceforge.net Mon Dec 17 02:55:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 18:55:32 -0800 Subject: [Patches] [ python-Patches-494047 ] removes 64-bit ?: to cope on plan9 Message-ID: Patches item #494047, was opened at 2001-12-16 18:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494047&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: Nobody/Anonymous (nobody) Summary: removes 64-bit ?: to cope on plan9 Initial Comment: The Plan 9 C compiler can't handle 64-bit numbers as the branches of a ternary operation. Rewrite a ? b : c into if (a) then b else c in two places. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:55 Message: Logged In: YES user_id=6380 Thanks. We'll do this in 2.2.1 or 2.3, since (IMO) it's too close to the release date of 2.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494047&group_id=5470 From noreply@sourceforge.net Mon Dec 17 02:57:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 18:57:06 -0800 Subject: [Patches] [ python-Patches-494045 ] patches errno and stat to cope on plan9 Message-ID: Patches item #494045, was opened at 2001-12-16 18:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494045&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: Nobody/Anonymous (nobody) Summary: patches errno and stat to cope on plan9 Initial Comment: Small #ifdefed patches to handle differences between the Plan 9 API and the traditional Posix API. The patch to bltinmodule.c also attempts to make the #ifdefs a little more readable. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:57 Message: Logged In: YES user_id=6380 There seems to be a bug in this patch. Why does it delete the RISCOS #ifdefs? Perhaps you diffed current CVS or 2.2c1 against a modified copy of an older Python version? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494045&group_id=5470 From noreply@sourceforge.net Mon Dec 17 03:05:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 19:05:09 -0800 Subject: [Patches] [ python-Patches-494045 ] patches errno and stat to cope on plan9 Message-ID: Patches item #494045, was opened at 2001-12-16 18:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494045&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: Nobody/Anonymous (nobody) Summary: patches errno and stat to cope on plan9 Initial Comment: Small #ifdefed patches to handle differences between the Plan 9 API and the traditional Posix API. The patch to bltinmodule.c also attempts to make the #ifdefs a little more readable. ---------------------------------------------------------------------- >Comment By: Russ Cox (rsc) Date: 2001-12-16 19:05 Message: Logged In: YES user_id=403803 It doesn't actually delete the RISCOS patches; the context diff turns out to be hard to read. I've attached the raw source code for the affected area. You may not want to expand things like I did, but all the #ifdefs were getting hard to follow. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:57 Message: Logged In: YES user_id=6380 There seems to be a bug in this patch. Why does it delete the RISCOS #ifdefs? Perhaps you diffed current CVS or 2.2c1 against a modified copy of an older Python version? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494045&group_id=5470 From noreply@sourceforge.net Mon Dec 17 03:46:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 19:46:53 -0800 Subject: [Patches] [ python-Patches-494065 ] access to st_rdev,st_blocks,st_blksize Message-ID: Patches item #494065, was opened at 2001-12-16 19:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494065&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chuck Blake (cblake) Assigned to: Nobody/Anonymous (nobody) Summary: access to st_rdev,st_blocks,st_blksize Initial Comment: posixmodule.c and configure have several provisions to make st_rdev, st_blocks, and st_blksize accessible if the host system supports them. Unfortunately, the length of the returned stat tuple does not reflect this. The fix is trivial -- replace a literal "10" with 1 + the highest index macro. That fix makes all detectable fields accessible, but it may be that configure only discovers support for some of the fields in which case it is impossible to decide which of the last couple elements refer to which fields. E.g if configure only finds st_rdev there is no way for a running program to easily know that. In any event we surely want ST_RDEV fields, etc. as for the rest of the stat fields (for consistency, if nothing else). The simplest fix is to have the posix module itself define the ST_RDEV and friends slot name variables. Then the stat module can simply try to take them from the "os" module. I'm submitting a patch which does all these things. In particular I have a very nice categorical, colorizing "ls" written purely in 500 lines of Python, but it cannot do long listings for device files since the st_rdev just isn't there. Also "du" in Python would fail in the presence of sparse files since st_blocks is missing. These fields have been around forever. It's about time we actually get the support working. Long term it would probably be best if the "os/posix" module defined the variables that the stat module currently does. This would simplify any portability issues since the C code can just use the configure macros. For backward compatibility a stat module could remain that just imported all the correct names from the os module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494065&group_id=5470 From noreply@sourceforge.net Mon Dec 17 04:04:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 20:04:22 -0800 Subject: [Patches] [ python-Patches-494066 ] Access to readline history elements Message-ID: Patches item #494066, was opened at 2001-12-16 20:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chuck Blake (cblake) Assigned to: Nobody/Anonymous (nobody) Summary: Access to readline history elements Initial Comment: The current readlinemodule.c has a relatively minimal wrapper around the functionality of the GNU readline and history libraries. That may be fine, and since some try to use libeditline instead it may be the best. However the current module does not enable any access from within Python to the libreadline maintained list of input lines. The ideal thing would be to actually export that dynamically maintained C list as a Python object. In lieu of that more complex change, my patch simply adds very simple history_get() and history_len() methods. This is the least one needs to access the list. I'm pretty sure the library functions go waaaay back, probably to the merger of the history and readline libraries. This patch also adds one final little ingredient which is rl_redisplay() in the wrapper for rl_insert_text(). Without this the user cannot see the inserted text until they type another character, which seems pretty undesirable. Together these two updates allow the regular Unix readline-enabled shell to perform "auto indentation". I.e., inserting into the edit buffer the leading whitespace from the preceding non-result producing line. Since it can be editted, one can just backspace a couple times to reverse the autoindent. This makes the basic readline-enabled read-eval-print loop substantially more pleasant. I can provide an example PYTHONSTARTUP file that shows how to use it. Only a tiny 8 line or so pre_input_hook is needed and a slightly smart sys.ps1 or sys.ps2 object that communicates via a variable to our hook function whether or not the parser is expecting more input. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470 From noreply@sourceforge.net Mon Dec 17 04:29:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 20:29:15 -0800 Subject: [Patches] [ python-Patches-494065 ] access to st_rdev,st_blocks,st_blksize Message-ID: Patches item #494065, was opened at 2001-12-16 19:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494065&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Chuck Blake (cblake) Assigned to: Nobody/Anonymous (nobody) Summary: access to st_rdev,st_blocks,st_blksize Initial Comment: posixmodule.c and configure have several provisions to make st_rdev, st_blocks, and st_blksize accessible if the host system supports them. Unfortunately, the length of the returned stat tuple does not reflect this. The fix is trivial -- replace a literal "10" with 1 + the highest index macro. That fix makes all detectable fields accessible, but it may be that configure only discovers support for some of the fields in which case it is impossible to decide which of the last couple elements refer to which fields. E.g if configure only finds st_rdev there is no way for a running program to easily know that. In any event we surely want ST_RDEV fields, etc. as for the rest of the stat fields (for consistency, if nothing else). The simplest fix is to have the posix module itself define the ST_RDEV and friends slot name variables. Then the stat module can simply try to take them from the "os" module. I'm submitting a patch which does all these things. In particular I have a very nice categorical, colorizing "ls" written purely in 500 lines of Python, but it cannot do long listings for device files since the st_rdev just isn't there. Also "du" in Python would fail in the presence of sparse files since st_blocks is missing. These fields have been around forever. It's about time we actually get the support working. Long term it would probably be best if the "os/posix" module defined the variables that the stat module currently does. This would simplify any portability issues since the C code can just use the configure macros. For backward compatibility a stat module could remain that just imported all the correct names from the os module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:29 Message: Logged In: YES user_id=6380 Sorry, you have misunderstood the stat interface. For historic reasons, the tuple size can't vary depending on whether the platform supports certain fields -- there is too much code out there that unpacks the tuple into exactly 10 local variables. Instead, in Python 2.2 and later, you can access the fields by name, and then you get access to all fields that exist. We well be deprecating the tuple style access, and the ST_XXX constants will go away (in Python 3.0 :-). Example: >>> import os >>> x = os.stat("/") >>> x.st_rdev 775 >>> x.st_blocks 8 >>> x.st_blksize 4096 >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494065&group_id=5470 From noreply@sourceforge.net Mon Dec 17 07:23:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 23:23:22 -0800 Subject: [Patches] [ python-Patches-494098 ] trivial typo in Lib/site.py Message-ID: Patches item #494098, was opened at 2001-12-16 23:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494098&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry Warsaw (bwarsaw) Summary: trivial typo in Lib/site.py Initial Comment: Line 17 of Lib/site.py begins with \(and sys.exec_prefix, I believe the \ is superfluous. (If CVS wasn't at RC1 I would just have checked in the change...) Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494098&group_id=5470 From noreply@sourceforge.net Mon Dec 17 07:29:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 23:29:43 -0800 Subject: [Patches] [ python-Patches-494100 ] warn about $(CONFINCLUDEPY)/config.h Message-ID: Patches item #494100, was opened at 2001-12-16 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494100&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: warn about $(CONFINCLUDEPY)/config.h Initial Comment: During install, the user should probably be warned if $(CONFINCLUDEPY)/config.h is found, as it's likely to be out-of- date. Here's a simple patch for Makefile.pre.in. S ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494100&group_id=5470 From noreply@sourceforge.net Mon Dec 17 09:53:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 01:53:06 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 14:02:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 06:02:21 -0800 Subject: [Patches] [ python-Patches-494098 ] trivial typo in Lib/site.py Message-ID: Patches item #494098, was opened at 2001-12-16 23:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494098&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry Warsaw (bwarsaw) Summary: trivial typo in Lib/site.py Initial Comment: Line 17 of Lib/site.py begins with \(and sys.exec_prefix, I believe the \ is superfluous. (If CVS wasn't at RC1 I would just have checked in the change...) Skip ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:02 Message: Logged In: YES user_id=6380 Good thing you assigned it to Barry -- I believe it's there to avoid an Emacs issue; a line in a docstring should never begin with '('. But since \( isn't a Python escape, if you print the doc string, it will contain the \(. Also, there are a few bits of latex in the doc string... Strange. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494098&group_id=5470 From noreply@sourceforge.net Mon Dec 17 14:04:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 06:04:19 -0800 Subject: [Patches] [ python-Patches-494100 ] warn about $(CONFINCLUDEPY)/config.h Message-ID: Patches item #494100, was opened at 2001-12-16 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494100&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: warn about $(CONFINCLUDEPY)/config.h Initial Comment: During install, the user should probably be warned if $(CONFINCLUDEPY)/config.h is found, as it's likely to be out-of- date. Here's a simple patch for Makefile.pre.in. S ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:04 Message: Logged In: YES user_id=6380 Good idea. I have no problem with you checking this in, but I doubt it will be effective: "make install" prints so much output that it will be ignored when it's most important. Maybe you can just delete the config.h??? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494100&group_id=5470 From noreply@sourceforge.net Mon Dec 17 15:40:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 07:40:49 -0800 Subject: [Patches] [ python-Patches-494098 ] trivial typo in Lib/site.py Message-ID: Patches item #494098, was opened at 2001-12-16 23:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494098&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry Warsaw (bwarsaw) Summary: trivial typo in Lib/site.py Initial Comment: Line 17 of Lib/site.py begins with \(and sys.exec_prefix, I believe the \ is superfluous. (If CVS wasn't at RC1 I would just have checked in the change...) Skip ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-17 07:40 Message: Logged In: YES user_id=12800 Yes, it was there to workaround an annoying XEmacs bug. I've tried some simple edits with XEmacs 21.4.5 (downloading and compiling 21.4.6 now...) and I can't trigger any broken fontlocking, so perhaps this has been fixed (wishful thinking?). I'll get rid of the backslash and close this bug report. If the problem resurfaces, I'll push on the XEmacs crowd to fix their editor. Note that I haven't tested FSF Emacs at all. It's stupid for us to have to continue to worm around editor bugs. :( Fixed in site.py 1.38 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:02 Message: Logged In: YES user_id=6380 Good thing you assigned it to Barry -- I believe it's there to avoid an Emacs issue; a line in a docstring should never begin with '('. But since \( isn't a Python escape, if you print the doc string, it will contain the \(. Also, there are a few bits of latex in the doc string... Strange. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494098&group_id=5470 From noreply@sourceforge.net Mon Dec 17 16:55:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 08:55:54 -0800 Subject: [Patches] [ python-Patches-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Patches item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-12-17 08:55 Message: Logged In: YES user_id=11105 Tarn, good work! I can now reproduce your problem here: It only appears when _no_ external zip.exe program is found somewhere on the PATH. In this case Python's zipfile.py is used, and this indeed creates an entry foo-1.0.win32.zip, leading to the crash. This entry is not present when an zip.exe is used. I will work on this. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-10 07:37 Message: Logged In: YES user_id=21784 This fails on the first file lookup. I agree that it shouldn't but you can see the file that it is failing on by looking in the Python root. In the case of a installer called "foo-1.0.win32-py2.2.exe" the first file appears to be "foo-1.0.win32.zip" which looks like the archive name. An empty file of this name also gets created by the installer. I don't know if this is a normal part of a zip file. If it is then adding if (n==0) continue; before line 228 which is pcomp = &data[pcdir->ofs_local_header will fix it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-10 02:29 Message: Logged In: YES user_id=11105 Tarn, this is really a problem. Thanks for finding it. I still wonder how this bug lead to a crash. Usually the for-loop doesn't run up to beyond the end of the list, because the prefix *should* always be found. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-08 18:42 Message: Logged In: YES user_id=21784 Looks like I've found the problem: line 244 in misc/extract.c is currently this: for (i = 0; *scheme[i].name; ++i) { The scheme list is terminated by a NULL, so *NULL causes an exception at the end of the list. Instead this should be: for (i = 0; scheme[i].name; ++i) { ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 12:55 Message: Logged In: YES user_id=11375 Reassigning to Thomas Heller; I know nothing about bdist_wininst. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 From noreply@sourceforge.net Mon Dec 17 17:27:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 09:27:14 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:27 Message: Logged In: YES user_id=31435 wchar.h and wctype.h were added to the C89 std by Amendment 1, published in 1995. Since they've been standardized for more than 6 years, I don't think we should try to cater to non-standard implementations. So I'd rather see a config test for HAVE_USABLE_WCHAR_T check that checks for the presence of wchar.h too. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 17:31:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 09:31:00 -0800 Subject: [Patches] [ python-Patches-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Patches item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-12-17 09:31 Message: Logged In: YES user_id=11105 Raised priority to 7 because this MUST be fixed before release (see PEP3). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 08:55 Message: Logged In: YES user_id=11105 Tarn, good work! I can now reproduce your problem here: It only appears when _no_ external zip.exe program is found somewhere on the PATH. In this case Python's zipfile.py is used, and this indeed creates an entry foo-1.0.win32.zip, leading to the crash. This entry is not present when an zip.exe is used. I will work on this. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-10 07:37 Message: Logged In: YES user_id=21784 This fails on the first file lookup. I agree that it shouldn't but you can see the file that it is failing on by looking in the Python root. In the case of a installer called "foo-1.0.win32-py2.2.exe" the first file appears to be "foo-1.0.win32.zip" which looks like the archive name. An empty file of this name also gets created by the installer. I don't know if this is a normal part of a zip file. If it is then adding if (n==0) continue; before line 228 which is pcomp = &data[pcdir->ofs_local_header will fix it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-10 02:29 Message: Logged In: YES user_id=11105 Tarn, this is really a problem. Thanks for finding it. I still wonder how this bug lead to a crash. Usually the for-loop doesn't run up to beyond the end of the list, because the prefix *should* always be found. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-08 18:42 Message: Logged In: YES user_id=21784 Looks like I've found the problem: line 244 in misc/extract.c is currently this: for (i = 0; *scheme[i].name; ++i) { The scheme list is terminated by a NULL, so *NULL causes an exception at the end of the list. Instead this should be: for (i = 0; scheme[i].name; ++i) { ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 12:55 Message: Logged In: YES user_id=11375 Reassigning to Thomas Heller; I know nothing about bdist_wininst. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 From noreply@sourceforge.net Mon Dec 17 18:29:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 10:29:47 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Russ Cox (rsc) Date: 2001-12-17 10:29 Message: Logged In: YES user_id=403803 Plan 9 has a single include file that provides everything you'd think of as the C library, except stdio. Also, Plan 9 calls the Unicode character type Rune instead of wchar_t, so I typedefed one in Plan 9's pyconfig.h and set HAVE_USABLE_WCHAR_T (Runes are 16-bit unsigned integers) but not HAVE_WCHAR_H. Rereading the various things that are excluded if you don't HAVE_WCHAR_H, it's clear that in my case I should just create an empty wchar.h and defined HAVE_WCHAR_H. So I'd be happy to drop this. However, I do think that the code is at least misleading. If configure is doing a bad job then, as Tim suggests, configure should be fixed. Perhaps a better replacement would be: #if defined(HAVE_USABLE_WCHAR_T) && !defined(HAVE_WCHAR_H) #error "HAVE_USABLE_WCHAR_T requires HAVE_WCHAR_H." #endif Sorry for the hassle. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:27 Message: Logged In: YES user_id=31435 wchar.h and wctype.h were added to the C89 std by Amendment 1, published in 1995. Since they've been standardized for more than 6 years, I don't think we should try to cater to non-standard implementations. So I'd rather see a config test for HAVE_USABLE_WCHAR_T check that checks for the presence of wchar.h too. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 18:37:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 10:37:58 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 10:37 Message: Logged In: YES user_id=6380 Sigh. Why does Plan 9 want to fight the C standard? ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 10:29 Message: Logged In: YES user_id=403803 Plan 9 has a single include file that provides everything you'd think of as the C library, except stdio. Also, Plan 9 calls the Unicode character type Rune instead of wchar_t, so I typedefed one in Plan 9's pyconfig.h and set HAVE_USABLE_WCHAR_T (Runes are 16-bit unsigned integers) but not HAVE_WCHAR_H. Rereading the various things that are excluded if you don't HAVE_WCHAR_H, it's clear that in my case I should just create an empty wchar.h and defined HAVE_WCHAR_H. So I'd be happy to drop this. However, I do think that the code is at least misleading. If configure is doing a bad job then, as Tim suggests, configure should be fixed. Perhaps a better replacement would be: #if defined(HAVE_USABLE_WCHAR_T) && !defined(HAVE_WCHAR_H) #error "HAVE_USABLE_WCHAR_T requires HAVE_WCHAR_H." #endif Sorry for the hassle. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:27 Message: Logged In: YES user_id=31435 wchar.h and wctype.h were added to the C89 std by Amendment 1, published in 1995. Since they've been standardized for more than 6 years, I don't think we should try to cater to non-standard implementations. So I'd rather see a config test for HAVE_USABLE_WCHAR_T check that checks for the presence of wchar.h too. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 18:59:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 10:59:24 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-17 10:59 Message: Logged In: YES user_id=31435 Guido, I expect it's because the C standard sucks -- Plan 9 seems more of a researchy thing, looking into how things could have been done better. An interesting read about their C mutant: http://www.lysator.liu.se/c/plan9c.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 10:37 Message: Logged In: YES user_id=6380 Sigh. Why does Plan 9 want to fight the C standard? ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 10:29 Message: Logged In: YES user_id=403803 Plan 9 has a single include file that provides everything you'd think of as the C library, except stdio. Also, Plan 9 calls the Unicode character type Rune instead of wchar_t, so I typedefed one in Plan 9's pyconfig.h and set HAVE_USABLE_WCHAR_T (Runes are 16-bit unsigned integers) but not HAVE_WCHAR_H. Rereading the various things that are excluded if you don't HAVE_WCHAR_H, it's clear that in my case I should just create an empty wchar.h and defined HAVE_WCHAR_H. So I'd be happy to drop this. However, I do think that the code is at least misleading. If configure is doing a bad job then, as Tim suggests, configure should be fixed. Perhaps a better replacement would be: #if defined(HAVE_USABLE_WCHAR_T) && !defined(HAVE_WCHAR_H) #error "HAVE_USABLE_WCHAR_T requires HAVE_WCHAR_H." #endif Sorry for the hassle. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:27 Message: Logged In: YES user_id=31435 wchar.h and wctype.h were added to the C89 std by Amendment 1, published in 1995. Since they've been standardized for more than 6 years, I don't think we should try to cater to non-standard implementations. So I'd rather see a config test for HAVE_USABLE_WCHAR_T check that checks for the presence of wchar.h too. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 19:05:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 11:05:51 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:05 Message: Logged In: YES user_id=6380 I don't understand how asking robust portable 3rd party software to change is "doing things better". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 10:59 Message: Logged In: YES user_id=31435 Guido, I expect it's because the C standard sucks -- Plan 9 seems more of a researchy thing, looking into how things could have been done better. An interesting read about their C mutant: http://www.lysator.liu.se/c/plan9c.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 10:37 Message: Logged In: YES user_id=6380 Sigh. Why does Plan 9 want to fight the C standard? ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 10:29 Message: Logged In: YES user_id=403803 Plan 9 has a single include file that provides everything you'd think of as the C library, except stdio. Also, Plan 9 calls the Unicode character type Rune instead of wchar_t, so I typedefed one in Plan 9's pyconfig.h and set HAVE_USABLE_WCHAR_T (Runes are 16-bit unsigned integers) but not HAVE_WCHAR_H. Rereading the various things that are excluded if you don't HAVE_WCHAR_H, it's clear that in my case I should just create an empty wchar.h and defined HAVE_WCHAR_H. So I'd be happy to drop this. However, I do think that the code is at least misleading. If configure is doing a bad job then, as Tim suggests, configure should be fixed. Perhaps a better replacement would be: #if defined(HAVE_USABLE_WCHAR_T) && !defined(HAVE_WCHAR_H) #error "HAVE_USABLE_WCHAR_T requires HAVE_WCHAR_H." #endif Sorry for the hassle. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:27 Message: Logged In: YES user_id=31435 wchar.h and wctype.h were added to the C89 std by Amendment 1, published in 1995. Since they've been standardized for more than 6 years, I don't think we should try to cater to non-standard implementations. So I'd rather see a config test for HAVE_USABLE_WCHAR_T check that checks for the presence of wchar.h too. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 19:07:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 11:07:36 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Russ Cox (rsc) Date: 2001-12-17 11:07 Message: Logged In: YES user_id=403803 Plan 9 predates the C standard, both of them. It has a completely separate ANSI/POSIX environment that at one point was used to compile all of X Windows, but it's for POSIX1 and doesn't mix well with the rest of the system. (Explaining what that means would take more text than you probably care to read.) I port a lot of software to Plan 9. If I had a month free to spend on such things I'd like to write an updated version that adhered to the C99 standard but still mixed well with the rest of the system. Until that happens, I have to make do with what I have. Think about it this way. The native Windows libraries don't adhere to the C standard: when you write native Windows programs you #include and use their APIs and their type definitions. Windows also happens to provide a set of header files that provides the C99- mandated interface, but it's a bag on the side. In the same vein, Plan 9 provides its own library interface for native programs. Unlike Windows, Plan 9 doesn't have an up-to-date bag on the side for C99 (or even the C89 addons like wide characters). But it's close enough that I can port large software packages like Python, Ghostscript, and CVS without much trouble. I agree that it would be better if there was a standard C interface that could be used. It just isn't there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:05 Message: Logged In: YES user_id=6380 I don't understand how asking robust portable 3rd party software to change is "doing things better". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 10:59 Message: Logged In: YES user_id=31435 Guido, I expect it's because the C standard sucks -- Plan 9 seems more of a researchy thing, looking into how things could have been done better. An interesting read about their C mutant: http://www.lysator.liu.se/c/plan9c.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 10:37 Message: Logged In: YES user_id=6380 Sigh. Why does Plan 9 want to fight the C standard? ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 10:29 Message: Logged In: YES user_id=403803 Plan 9 has a single include file that provides everything you'd think of as the C library, except stdio. Also, Plan 9 calls the Unicode character type Rune instead of wchar_t, so I typedefed one in Plan 9's pyconfig.h and set HAVE_USABLE_WCHAR_T (Runes are 16-bit unsigned integers) but not HAVE_WCHAR_H. Rereading the various things that are excluded if you don't HAVE_WCHAR_H, it's clear that in my case I should just create an empty wchar.h and defined HAVE_WCHAR_H. So I'd be happy to drop this. However, I do think that the code is at least misleading. If configure is doing a bad job then, as Tim suggests, configure should be fixed. Perhaps a better replacement would be: #if defined(HAVE_USABLE_WCHAR_T) && !defined(HAVE_WCHAR_H) #error "HAVE_USABLE_WCHAR_T requires HAVE_WCHAR_H." #endif Sorry for the hassle. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:27 Message: Logged In: YES user_id=31435 wchar.h and wctype.h were added to the C89 std by Amendment 1, published in 1995. Since they've been standardized for more than 6 years, I don't think we should try to cater to non-standard implementations. So I'd rather see a config test for HAVE_USABLE_WCHAR_T check that checks for the presence of wchar.h too. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 19:11:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 11:11:38 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Wont Fix Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:11 Message: Logged In: YES user_id=6380 The difference is that Windows has the marketing clout to convince me that it's worth the effort to make Python work better on Windows. ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 11:07 Message: Logged In: YES user_id=403803 Plan 9 predates the C standard, both of them. It has a completely separate ANSI/POSIX environment that at one point was used to compile all of X Windows, but it's for POSIX1 and doesn't mix well with the rest of the system. (Explaining what that means would take more text than you probably care to read.) I port a lot of software to Plan 9. If I had a month free to spend on such things I'd like to write an updated version that adhered to the C99 standard but still mixed well with the rest of the system. Until that happens, I have to make do with what I have. Think about it this way. The native Windows libraries don't adhere to the C standard: when you write native Windows programs you #include and use their APIs and their type definitions. Windows also happens to provide a set of header files that provides the C99- mandated interface, but it's a bag on the side. In the same vein, Plan 9 provides its own library interface for native programs. Unlike Windows, Plan 9 doesn't have an up-to-date bag on the side for C99 (or even the C89 addons like wide characters). But it's close enough that I can port large software packages like Python, Ghostscript, and CVS without much trouble. I agree that it would be better if there was a standard C interface that could be used. It just isn't there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:05 Message: Logged In: YES user_id=6380 I don't understand how asking robust portable 3rd party software to change is "doing things better". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 10:59 Message: Logged In: YES user_id=31435 Guido, I expect it's because the C standard sucks -- Plan 9 seems more of a researchy thing, looking into how things could have been done better. An interesting read about their C mutant: http://www.lysator.liu.se/c/plan9c.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 10:37 Message: Logged In: YES user_id=6380 Sigh. Why does Plan 9 want to fight the C standard? ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 10:29 Message: Logged In: YES user_id=403803 Plan 9 has a single include file that provides everything you'd think of as the C library, except stdio. Also, Plan 9 calls the Unicode character type Rune instead of wchar_t, so I typedefed one in Plan 9's pyconfig.h and set HAVE_USABLE_WCHAR_T (Runes are 16-bit unsigned integers) but not HAVE_WCHAR_H. Rereading the various things that are excluded if you don't HAVE_WCHAR_H, it's clear that in my case I should just create an empty wchar.h and defined HAVE_WCHAR_H. So I'd be happy to drop this. However, I do think that the code is at least misleading. If configure is doing a bad job then, as Tim suggests, configure should be fixed. Perhaps a better replacement would be: #if defined(HAVE_USABLE_WCHAR_T) && !defined(HAVE_WCHAR_H) #error "HAVE_USABLE_WCHAR_T requires HAVE_WCHAR_H." #endif Sorry for the hassle. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:27 Message: Logged In: YES user_id=31435 wchar.h and wctype.h were added to the C89 std by Amendment 1, published in 1995. Since they've been standardized for more than 6 years, I don't think we should try to cater to non-standard implementations. So I'd rather see a config test for HAVE_USABLE_WCHAR_T check that checks for the presence of wchar.h too. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 19:18:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 11:18:24 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-17 11:18 Message: Logged In: YES user_id=31435 Looks like simultaneous edits caused Guido's Close action to get lost -- just restoring it here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:11 Message: Logged In: YES user_id=6380 The difference is that Windows has the marketing clout to convince me that it's worth the effort to make Python work better on Windows. ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 11:07 Message: Logged In: YES user_id=403803 Plan 9 predates the C standard, both of them. It has a completely separate ANSI/POSIX environment that at one point was used to compile all of X Windows, but it's for POSIX1 and doesn't mix well with the rest of the system. (Explaining what that means would take more text than you probably care to read.) I port a lot of software to Plan 9. If I had a month free to spend on such things I'd like to write an updated version that adhered to the C99 standard but still mixed well with the rest of the system. Until that happens, I have to make do with what I have. Think about it this way. The native Windows libraries don't adhere to the C standard: when you write native Windows programs you #include and use their APIs and their type definitions. Windows also happens to provide a set of header files that provides the C99- mandated interface, but it's a bag on the side. In the same vein, Plan 9 provides its own library interface for native programs. Unlike Windows, Plan 9 doesn't have an up-to-date bag on the side for C99 (or even the C89 addons like wide characters). But it's close enough that I can port large software packages like Python, Ghostscript, and CVS without much trouble. I agree that it would be better if there was a standard C interface that could be used. It just isn't there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:05 Message: Logged In: YES user_id=6380 I don't understand how asking robust portable 3rd party software to change is "doing things better". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 10:59 Message: Logged In: YES user_id=31435 Guido, I expect it's because the C standard sucks -- Plan 9 seems more of a researchy thing, looking into how things could have been done better. An interesting read about their C mutant: http://www.lysator.liu.se/c/plan9c.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 10:37 Message: Logged In: YES user_id=6380 Sigh. Why does Plan 9 want to fight the C standard? ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 10:29 Message: Logged In: YES user_id=403803 Plan 9 has a single include file that provides everything you'd think of as the C library, except stdio. Also, Plan 9 calls the Unicode character type Rune instead of wchar_t, so I typedefed one in Plan 9's pyconfig.h and set HAVE_USABLE_WCHAR_T (Runes are 16-bit unsigned integers) but not HAVE_WCHAR_H. Rereading the various things that are excluded if you don't HAVE_WCHAR_H, it's clear that in my case I should just create an empty wchar.h and defined HAVE_WCHAR_H. So I'd be happy to drop this. However, I do think that the code is at least misleading. If configure is doing a bad job then, as Tim suggests, configure should be fixed. Perhaps a better replacement would be: #if defined(HAVE_USABLE_WCHAR_T) && !defined(HAVE_WCHAR_H) #error "HAVE_USABLE_WCHAR_T requires HAVE_WCHAR_H." #endif Sorry for the hassle. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:27 Message: Logged In: YES user_id=31435 wchar.h and wctype.h were added to the C89 std by Amendment 1, published in 1995. Since they've been standardized for more than 6 years, I don't think we should try to cater to non-standard implementations. So I'd rather see a config test for HAVE_USABLE_WCHAR_T check that checks for the presence of wchar.h too. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 19:22:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 11:22:04 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Russ Cox (rsc) Date: 2001-12-17 11:22 Message: Logged In: YES user_id=403803 It's really not much effort -- it's taken me a couple days to get Python working very well on Plan 9, and much of that was probably learning my way around. The way the Python sources are structured, almost all the needed code to support Plan 9 stays in my Plan9 build directory. There were two instances where I couldn't avoid changing source files in the portable directories (the 64-bit ?: and the stat changes), each involving trivial changes. The WCHAR thing just seemed inconsistent to me, so I pointed it out. This has turned into a much bigger deal than I ever intended. Maybe I should have just left it alone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 11:18 Message: Logged In: YES user_id=31435 Looks like simultaneous edits caused Guido's Close action to get lost -- just restoring it here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:11 Message: Logged In: YES user_id=6380 The difference is that Windows has the marketing clout to convince me that it's worth the effort to make Python work better on Windows. ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 11:07 Message: Logged In: YES user_id=403803 Plan 9 predates the C standard, both of them. It has a completely separate ANSI/POSIX environment that at one point was used to compile all of X Windows, but it's for POSIX1 and doesn't mix well with the rest of the system. (Explaining what that means would take more text than you probably care to read.) I port a lot of software to Plan 9. If I had a month free to spend on such things I'd like to write an updated version that adhered to the C99 standard but still mixed well with the rest of the system. Until that happens, I have to make do with what I have. Think about it this way. The native Windows libraries don't adhere to the C standard: when you write native Windows programs you #include and use their APIs and their type definitions. Windows also happens to provide a set of header files that provides the C99- mandated interface, but it's a bag on the side. In the same vein, Plan 9 provides its own library interface for native programs. Unlike Windows, Plan 9 doesn't have an up-to-date bag on the side for C99 (or even the C89 addons like wide characters). But it's close enough that I can port large software packages like Python, Ghostscript, and CVS without much trouble. I agree that it would be better if there was a standard C interface that could be used. It just isn't there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:05 Message: Logged In: YES user_id=6380 I don't understand how asking robust portable 3rd party software to change is "doing things better". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 10:59 Message: Logged In: YES user_id=31435 Guido, I expect it's because the C standard sucks -- Plan 9 seems more of a researchy thing, looking into how things could have been done better. An interesting read about their C mutant: http://www.lysator.liu.se/c/plan9c.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 10:37 Message: Logged In: YES user_id=6380 Sigh. Why does Plan 9 want to fight the C standard? ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 10:29 Message: Logged In: YES user_id=403803 Plan 9 has a single include file that provides everything you'd think of as the C library, except stdio. Also, Plan 9 calls the Unicode character type Rune instead of wchar_t, so I typedefed one in Plan 9's pyconfig.h and set HAVE_USABLE_WCHAR_T (Runes are 16-bit unsigned integers) but not HAVE_WCHAR_H. Rereading the various things that are excluded if you don't HAVE_WCHAR_H, it's clear that in my case I should just create an empty wchar.h and defined HAVE_WCHAR_H. So I'd be happy to drop this. However, I do think that the code is at least misleading. If configure is doing a bad job then, as Tim suggests, configure should be fixed. Perhaps a better replacement would be: #if defined(HAVE_USABLE_WCHAR_T) && !defined(HAVE_WCHAR_H) #error "HAVE_USABLE_WCHAR_T requires HAVE_WCHAR_H." #endif Sorry for the hassle. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:27 Message: Logged In: YES user_id=31435 wchar.h and wctype.h were added to the C89 std by Amendment 1, published in 1995. Since they've been standardized for more than 6 years, I don't think we should try to cater to non-standard implementations. So I'd rather see a config test for HAVE_USABLE_WCHAR_T check that checks for the presence of wchar.h too. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 19:22:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 11:22:50 -0800 Subject: [Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header Message-ID: Patches item #494048, was opened at 2001-12-16 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: M.-A. Lemburg (lemburg) Summary: removes def of HAVE_WCHAR_H in header Initial Comment: Include/unicodeobject.h #defines HAVE_WCHAR_H if HAVE_USABLE_WCHAR_T is #defined. This is bogus: if the configuration claims to have a usable wchar_t without having , it should be respected. The patch removes this conditional. ---------------------------------------------------------------------- >Comment By: Russ Cox (rsc) Date: 2001-12-17 11:22 Message: Logged In: YES user_id=403803 Sorry, stomped the close again. This time for sure. ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 11:22 Message: Logged In: YES user_id=403803 It's really not much effort -- it's taken me a couple days to get Python working very well on Plan 9, and much of that was probably learning my way around. The way the Python sources are structured, almost all the needed code to support Plan 9 stays in my Plan9 build directory. There were two instances where I couldn't avoid changing source files in the portable directories (the 64-bit ?: and the stat changes), each involving trivial changes. The WCHAR thing just seemed inconsistent to me, so I pointed it out. This has turned into a much bigger deal than I ever intended. Maybe I should have just left it alone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 11:18 Message: Logged In: YES user_id=31435 Looks like simultaneous edits caused Guido's Close action to get lost -- just restoring it here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:11 Message: Logged In: YES user_id=6380 The difference is that Windows has the marketing clout to convince me that it's worth the effort to make Python work better on Windows. ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 11:07 Message: Logged In: YES user_id=403803 Plan 9 predates the C standard, both of them. It has a completely separate ANSI/POSIX environment that at one point was used to compile all of X Windows, but it's for POSIX1 and doesn't mix well with the rest of the system. (Explaining what that means would take more text than you probably care to read.) I port a lot of software to Plan 9. If I had a month free to spend on such things I'd like to write an updated version that adhered to the C99 standard but still mixed well with the rest of the system. Until that happens, I have to make do with what I have. Think about it this way. The native Windows libraries don't adhere to the C standard: when you write native Windows programs you #include and use their APIs and their type definitions. Windows also happens to provide a set of header files that provides the C99- mandated interface, but it's a bag on the side. In the same vein, Plan 9 provides its own library interface for native programs. Unlike Windows, Plan 9 doesn't have an up-to-date bag on the side for C99 (or even the C89 addons like wide characters). But it's close enough that I can port large software packages like Python, Ghostscript, and CVS without much trouble. I agree that it would be better if there was a standard C interface that could be used. It just isn't there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:05 Message: Logged In: YES user_id=6380 I don't understand how asking robust portable 3rd party software to change is "doing things better". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 10:59 Message: Logged In: YES user_id=31435 Guido, I expect it's because the C standard sucks -- Plan 9 seems more of a researchy thing, looking into how things could have been done better. An interesting read about their C mutant: http://www.lysator.liu.se/c/plan9c.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 10:37 Message: Logged In: YES user_id=6380 Sigh. Why does Plan 9 want to fight the C standard? ---------------------------------------------------------------------- Comment By: Russ Cox (rsc) Date: 2001-12-17 10:29 Message: Logged In: YES user_id=403803 Plan 9 has a single include file that provides everything you'd think of as the C library, except stdio. Also, Plan 9 calls the Unicode character type Rune instead of wchar_t, so I typedefed one in Plan 9's pyconfig.h and set HAVE_USABLE_WCHAR_T (Runes are 16-bit unsigned integers) but not HAVE_WCHAR_H. Rereading the various things that are excluded if you don't HAVE_WCHAR_H, it's clear that in my case I should just create an empty wchar.h and defined HAVE_WCHAR_H. So I'd be happy to drop this. However, I do think that the code is at least misleading. If configure is doing a bad job then, as Tim suggests, configure should be fixed. Perhaps a better replacement would be: #if defined(HAVE_USABLE_WCHAR_T) && !defined(HAVE_WCHAR_H) #error "HAVE_USABLE_WCHAR_T requires HAVE_WCHAR_H." #endif Sorry for the hassle. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:27 Message: Logged In: YES user_id=31435 wchar.h and wctype.h were added to the C89 std by Amendment 1, published in 1995. Since they've been standardized for more than 6 years, I don't think we should try to cater to non-standard implementations. So I'd rather see a config test for HAVE_USABLE_WCHAR_T check that checks for the presence of wchar.h too. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:53 Message: Logged In: YES user_id=38388 Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available. Russ, perhaps you could explain why you feel this patch is necessary ?! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 18:49 Message: Logged In: YES user_id=6380 Assigned to MAL -- Marc-Andre, do you recall why this was done this way? Do you think the patch is safe? (Not to be applied in 2.2, but considering for 2.3 or even 2.2.1.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470 From noreply@sourceforge.net Mon Dec 17 19:40:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 11:40:53 -0800 Subject: [Patches] [ python-Patches-494066 ] Access to readline history elements Message-ID: Patches item #494066, was opened at 2001-12-16 20:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chuck Blake (cblake) Assigned to: Nobody/Anonymous (nobody) Summary: Access to readline history elements Initial Comment: The current readlinemodule.c has a relatively minimal wrapper around the functionality of the GNU readline and history libraries. That may be fine, and since some try to use libeditline instead it may be the best. However the current module does not enable any access from within Python to the libreadline maintained list of input lines. The ideal thing would be to actually export that dynamically maintained C list as a Python object. In lieu of that more complex change, my patch simply adds very simple history_get() and history_len() methods. This is the least one needs to access the list. I'm pretty sure the library functions go waaaay back, probably to the merger of the history and readline libraries. This patch also adds one final little ingredient which is rl_redisplay() in the wrapper for rl_insert_text(). Without this the user cannot see the inserted text until they type another character, which seems pretty undesirable. Together these two updates allow the regular Unix readline-enabled shell to perform "auto indentation". I.e., inserting into the edit buffer the leading whitespace from the preceding non-result producing line. Since it can be editted, one can just backspace a couple times to reverse the autoindent. This makes the basic readline-enabled read-eval-print loop substantially more pleasant. I can provide an example PYTHONSTARTUP file that shows how to use it. Only a tiny 8 line or so pre_input_hook is needed and a slightly smart sys.ps1 or sys.ps2 object that communicates via a variable to our hook function whether or not the parser is expecting more input. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:40 Message: Logged In: YES user_id=6380 Hm, I was going to see if the insert_text fix was a simple enough fix to apply to 2.2, but I don't have an example of where this is needed. If I call it from the startup hook the text I insert is already being displayed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470 From noreply@sourceforge.net Mon Dec 17 20:00:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 12:00:38 -0800 Subject: [Patches] [ python-Patches-494066 ] Access to readline history elements Message-ID: Patches item #494066, was opened at 2001-12-16 20:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chuck Blake (cblake) Assigned to: Nobody/Anonymous (nobody) Summary: Access to readline history elements Initial Comment: The current readlinemodule.c has a relatively minimal wrapper around the functionality of the GNU readline and history libraries. That may be fine, and since some try to use libeditline instead it may be the best. However the current module does not enable any access from within Python to the libreadline maintained list of input lines. The ideal thing would be to actually export that dynamically maintained C list as a Python object. In lieu of that more complex change, my patch simply adds very simple history_get() and history_len() methods. This is the least one needs to access the list. I'm pretty sure the library functions go waaaay back, probably to the merger of the history and readline libraries. This patch also adds one final little ingredient which is rl_redisplay() in the wrapper for rl_insert_text(). Without this the user cannot see the inserted text until they type another character, which seems pretty undesirable. Together these two updates allow the regular Unix readline-enabled shell to perform "auto indentation". I.e., inserting into the edit buffer the leading whitespace from the preceding non-result producing line. Since it can be editted, one can just backspace a couple times to reverse the autoindent. This makes the basic readline-enabled read-eval-print loop substantially more pleasant. I can provide an example PYTHONSTARTUP file that shows how to use it. Only a tiny 8 line or so pre_input_hook is needed and a slightly smart sys.ps1 or sys.ps2 object that communicates via a variable to our hook function whether or not the parser is expecting more input. ---------------------------------------------------------------------- >Comment By: Chuck Blake (cblake) Date: 2001-12-17 12:00 Message: Logged In: YES user_id=403855 I have something this in my ~/.py/rc.py (STARTUP file). The just_did_a_result var is also maintained by sys.ps1. def auto_indent(): global just_did_a_result if just_did_a_result: just_did_a_result = 0 return last = readline.history_get(readline.history_len()) spc = len(last) - len(last.lstrip()) if spc > 0: readline.insert_text(last[ : spc]) readline.set_pre_input_hook(auto_indent) I don't know if you have a system where set_pre_input_hook is available. Unless you have access to the history or at least the very last input line from within Python, then it doesn't seem very useful. That is because there is no way for your input_hook to know when/what it should stuff text into your command buffer. The redisplay() is innocuous when it happens to be unnecessary, so it shouldn't be very objecionable. It's an interactive prompt so hyper-optimization isn't very important or noticeable. Even on a slow terminal it is only a few characters in one command prompt being re-drawn. If it is really an issue, though, then an alternative to adding my redisplay() fix would be to export another function from readline to Python, namely rl_redisplay(). Anyone's Python code could then just call it as necessary. Longer term, it seems like an awful lot more libhistory and libreadline functionality could profitably be included in the readline module. That's surely a 2.3 or later change, but the exporting of rl_redisplay() might be a closer step in that direction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:40 Message: Logged In: YES user_id=6380 Hm, I was going to see if the insert_text fix was a simple enough fix to apply to 2.2, but I don't have an example of where this is needed. If I call it from the startup hook the text I insert is already being displayed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470 From noreply@sourceforge.net Mon Dec 17 20:13:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 12:13:12 -0800 Subject: [Patches] [ python-Patches-494066 ] Access to readline history elements Message-ID: Patches item #494066, was opened at 2001-12-16 20:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chuck Blake (cblake) Assigned to: Nobody/Anonymous (nobody) Summary: Access to readline history elements Initial Comment: The current readlinemodule.c has a relatively minimal wrapper around the functionality of the GNU readline and history libraries. That may be fine, and since some try to use libeditline instead it may be the best. However the current module does not enable any access from within Python to the libreadline maintained list of input lines. The ideal thing would be to actually export that dynamically maintained C list as a Python object. In lieu of that more complex change, my patch simply adds very simple history_get() and history_len() methods. This is the least one needs to access the list. I'm pretty sure the library functions go waaaay back, probably to the merger of the history and readline libraries. This patch also adds one final little ingredient which is rl_redisplay() in the wrapper for rl_insert_text(). Without this the user cannot see the inserted text until they type another character, which seems pretty undesirable. Together these two updates allow the regular Unix readline-enabled shell to perform "auto indentation". I.e., inserting into the edit buffer the leading whitespace from the preceding non-result producing line. Since it can be editted, one can just backspace a couple times to reverse the autoindent. This makes the basic readline-enabled read-eval-print loop substantially more pleasant. I can provide an example PYTHONSTARTUP file that shows how to use it. Only a tiny 8 line or so pre_input_hook is needed and a slightly smart sys.ps1 or sys.ps2 object that communicates via a variable to our hook function whether or not the parser is expecting more input. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 12:13 Message: Logged In: YES user_id=6380 OK, in the sake of stability, let's not do any of this in 2.2 then. Sounds like there are plenty of things we *could* do. I'm not against expanding the readline module -- but I don't have a use for it in mind myself. For fancy editing I much prefer IDLE's command line editor, since it lets you edit an entire multi-line command as a single unit, than on a per-line basis as readline does... ---------------------------------------------------------------------- Comment By: Chuck Blake (cblake) Date: 2001-12-17 12:00 Message: Logged In: YES user_id=403855 I have something this in my ~/.py/rc.py (STARTUP file). The just_did_a_result var is also maintained by sys.ps1. def auto_indent(): global just_did_a_result if just_did_a_result: just_did_a_result = 0 return last = readline.history_get(readline.history_len()) spc = len(last) - len(last.lstrip()) if spc > 0: readline.insert_text(last[ : spc]) readline.set_pre_input_hook(auto_indent) I don't know if you have a system where set_pre_input_hook is available. Unless you have access to the history or at least the very last input line from within Python, then it doesn't seem very useful. That is because there is no way for your input_hook to know when/what it should stuff text into your command buffer. The redisplay() is innocuous when it happens to be unnecessary, so it shouldn't be very objecionable. It's an interactive prompt so hyper-optimization isn't very important or noticeable. Even on a slow terminal it is only a few characters in one command prompt being re-drawn. If it is really an issue, though, then an alternative to adding my redisplay() fix would be to export another function from readline to Python, namely rl_redisplay(). Anyone's Python code could then just call it as necessary. Longer term, it seems like an awful lot more libhistory and libreadline functionality could profitably be included in the readline module. That's surely a 2.3 or later change, but the exporting of rl_redisplay() might be a closer step in that direction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:40 Message: Logged In: YES user_id=6380 Hm, I was going to see if the insert_text fix was a simple enough fix to apply to 2.2, but I don't have an example of where this is needed. If I call it from the startup hook the text I insert is already being displayed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470 From noreply@sourceforge.net Mon Dec 17 20:32:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 12:32:03 -0800 Subject: [Patches] [ python-Patches-494100 ] warn about $(CONFINCLUDEPY)/config.h Message-ID: Patches item #494100, was opened at 2001-12-16 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494100&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: warn about $(CONFINCLUDEPY)/config.h Initial Comment: During install, the user should probably be warned if $(CONFINCLUDEPY)/config.h is found, as it's likely to be out-of- date. Here's a simple patch for Makefile.pre.in. S ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-12-17 12:32 Message: Logged In: YES user_id=44345 I'm cool with just deleting the file. I guess it's best to simply break bad builds in an obvious way instead of the subtle way that leaving it alone would. On the other hand, will the system ever find a config.h in /usr/local/lib/python2.2? Wasn't the name changed to pyconfig.h before the 2.2 cycle began? Maybe this isn't such a useful idea. Skip ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:04 Message: Logged In: YES user_id=6380 Good idea. I have no problem with you checking this in, but I doubt it will be effective: "make install" prints so much output that it will be ignored when it's most important. Maybe you can just delete the config.h??? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494100&group_id=5470 From noreply@sourceforge.net Mon Dec 17 20:38:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 12:38:22 -0800 Subject: [Patches] [ python-Patches-494100 ] warn about $(CONFINCLUDEPY)/config.h Message-ID: Patches item #494100, was opened at 2001-12-16 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494100&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 4 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: warn about $(CONFINCLUDEPY)/config.h Initial Comment: During install, the user should probably be warned if $(CONFINCLUDEPY)/config.h is found, as it's likely to be out-of- date. Here's a simple patch for Makefile.pre.in. S ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 12:38 Message: Logged In: YES user_id=6380 It was config.h in 2.1 and before (as well as in 2.1.1 and 2.1.2). I thought this was inspired by something that had happened to you? But since the include directory's name includes the python version, I agree that it's not likely to fine a config.h there unless you downloaded early 2.2 alpha releases... Closing now. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-12-17 12:32 Message: Logged In: YES user_id=44345 I'm cool with just deleting the file. I guess it's best to simply break bad builds in an obvious way instead of the subtle way that leaving it alone would. On the other hand, will the system ever find a config.h in /usr/local/lib/python2.2? Wasn't the name changed to pyconfig.h before the 2.2 cycle began? Maybe this isn't such a useful idea. Skip ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:04 Message: Logged In: YES user_id=6380 Good idea. I have no problem with you checking this in, but I doubt it will be effective: "make install" prints so much output that it will be ignored when it's most important. Maybe you can just delete the config.h??? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494100&group_id=5470 From noreply@sourceforge.net Mon Dec 17 20:41:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 12:41:33 -0800 Subject: [Patches] [ python-Patches-494066 ] Access to readline history elements Message-ID: Patches item #494066, was opened at 2001-12-16 20:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chuck Blake (cblake) Assigned to: Nobody/Anonymous (nobody) Summary: Access to readline history elements Initial Comment: The current readlinemodule.c has a relatively minimal wrapper around the functionality of the GNU readline and history libraries. That may be fine, and since some try to use libeditline instead it may be the best. However the current module does not enable any access from within Python to the libreadline maintained list of input lines. The ideal thing would be to actually export that dynamically maintained C list as a Python object. In lieu of that more complex change, my patch simply adds very simple history_get() and history_len() methods. This is the least one needs to access the list. I'm pretty sure the library functions go waaaay back, probably to the merger of the history and readline libraries. This patch also adds one final little ingredient which is rl_redisplay() in the wrapper for rl_insert_text(). Without this the user cannot see the inserted text until they type another character, which seems pretty undesirable. Together these two updates allow the regular Unix readline-enabled shell to perform "auto indentation". I.e., inserting into the edit buffer the leading whitespace from the preceding non-result producing line. Since it can be editted, one can just backspace a couple times to reverse the autoindent. This makes the basic readline-enabled read-eval-print loop substantially more pleasant. I can provide an example PYTHONSTARTUP file that shows how to use it. Only a tiny 8 line or so pre_input_hook is needed and a slightly smart sys.ps1 or sys.ps2 object that communicates via a variable to our hook function whether or not the parser is expecting more input. ---------------------------------------------------------------------- >Comment By: Chuck Blake (cblake) Date: 2001-12-17 12:41 Message: Logged In: YES user_id=403855 Sounds quite reasonable. Having a nice readline completer and history matching interface is pretty cool when you're using the shell over a network where remote X windows would be painful. It's been a very useful interface for a while, and likely will be for the forseeable future. When I get a chance I'll work on seeing what parts of readline have been around for a very long time (e.g. since readline 2.0 or so) and try to wrap the basically available features more intelligently with Python objects, e.g. a tuple or list for command input history. Hopefully not too much will need to be conditionalized on readline versions. A lot of added functionality could be written trivially in Python if there is access to the library structures and exporting of hook/event type functions. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 12:13 Message: Logged In: YES user_id=6380 OK, in the sake of stability, let's not do any of this in 2.2 then. Sounds like there are plenty of things we *could* do. I'm not against expanding the readline module -- but I don't have a use for it in mind myself. For fancy editing I much prefer IDLE's command line editor, since it lets you edit an entire multi-line command as a single unit, than on a per-line basis as readline does... ---------------------------------------------------------------------- Comment By: Chuck Blake (cblake) Date: 2001-12-17 12:00 Message: Logged In: YES user_id=403855 I have something this in my ~/.py/rc.py (STARTUP file). The just_did_a_result var is also maintained by sys.ps1. def auto_indent(): global just_did_a_result if just_did_a_result: just_did_a_result = 0 return last = readline.history_get(readline.history_len()) spc = len(last) - len(last.lstrip()) if spc > 0: readline.insert_text(last[ : spc]) readline.set_pre_input_hook(auto_indent) I don't know if you have a system where set_pre_input_hook is available. Unless you have access to the history or at least the very last input line from within Python, then it doesn't seem very useful. That is because there is no way for your input_hook to know when/what it should stuff text into your command buffer. The redisplay() is innocuous when it happens to be unnecessary, so it shouldn't be very objecionable. It's an interactive prompt so hyper-optimization isn't very important or noticeable. Even on a slow terminal it is only a few characters in one command prompt being re-drawn. If it is really an issue, though, then an alternative to adding my redisplay() fix would be to export another function from readline to Python, namely rl_redisplay(). Anyone's Python code could then just call it as necessary. Longer term, it seems like an awful lot more libhistory and libreadline functionality could profitably be included in the readline module. That's surely a 2.3 or later change, but the exporting of rl_redisplay() might be a closer step in that direction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:40 Message: Logged In: YES user_id=6380 Hm, I was going to see if the insert_text fix was a simple enough fix to apply to 2.2, but I don't have an example of where this is needed. If I call it from the startup hook the text I insert is already being displayed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470 From noreply@sourceforge.net Mon Dec 17 23:38:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 15:38:42 -0800 Subject: [Patches] [ python-Patches-494384 ] Missing --disable-unicode patch Message-ID: Patches item #494384, was opened at 2001-12-17 15:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494384&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 8 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Missing --disable-unicode patch Initial Comment: Since ceval.c 2.290, --disable-unicode is broken; the attached patch wraps the offending code. This patch should be added for 2.2 for the feature to be useful at all. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494384&group_id=5470 From noreply@sourceforge.net Tue Dec 18 00:12:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 16:12:06 -0800 Subject: [Patches] [ python-Patches-494384 ] Missing --disable-unicode patch Message-ID: Patches item #494384, was opened at 2001-12-17 15:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494384&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Accepted Priority: 8 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: Missing --disable-unicode patch Initial Comment: Since ceval.c 2.290, --disable-unicode is broken; the attached patch wraps the offending code. This patch should be added for 2.2 for the feature to be useful at all. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-17 16:12 Message: Logged In: YES user_id=31435 Accepted and back to Martin for checkin. Or did you want me to check it in? If so, assign it back to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494384&group_id=5470 From noreply@sourceforge.net Tue Dec 18 12:02:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 04:02:49 -0800 Subject: [Patches] [ python-Patches-494553 ] Simple CarbonEvt.GetEventParameter implementation Message-ID: Patches item #494553, was opened at 2001-12-18 04:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494553&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Donovan Preston (dsposx) Assigned to: Jack Jansen (jackjansen) Summary: Simple CarbonEvt.GetEventParameter implementation Initial Comment: Here's my first stab at an implementation of GetEventParameter. Pretty important, since if you are catching 'cmds' events (Command events) you need to get the event parameter to find out which command it was. Just, I reran CarbonEvtscan.py after applying this patch but my generated CarbonEvtmodule.c was missing many of the functions that yours seemed to pick up -- which version of the universal headers are you using? I know you are also running on OS 9 (right?) and I am running on OS X. I'd like to get it so we can both run the *scan file and get the same .c file. (I might have messed up something on my end this time, though...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494553&group_id=5470 From noreply@sourceforge.net Tue Dec 18 12:13:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 04:13:11 -0800 Subject: [Patches] [ python-Patches-494553 ] Simple CarbonEvt.GetEventParameter implementation Message-ID: Patches item #494553, was opened at 2001-12-18 04:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494553&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Donovan Preston (dsposx) >Assigned to: Just van Rossum (jvr) Summary: Simple CarbonEvt.GetEventParameter implementation Initial Comment: Here's my first stab at an implementation of GetEventParameter. Pretty important, since if you are catching 'cmds' events (Command events) you need to get the event parameter to find out which command it was. Just, I reran CarbonEvtscan.py after applying this patch but my generated CarbonEvtmodule.c was missing many of the functions that yours seemed to pick up -- which version of the universal headers are you using? I know you are also running on OS 9 (right?) and I am running on OS X. I'd like to get it so we can both run the *scan file and get the same .c file. (I might have messed up something on my end this time, though...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494553&group_id=5470 From noreply@sourceforge.net Tue Dec 18 12:33:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 04:33:53 -0800 Subject: [Patches] [ python-Patches-494553 ] Simple CarbonEvt.GetEventParameter implementation Message-ID: Patches item #494553, was opened at 2001-12-18 04:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494553&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Donovan Preston (dsposx) Assigned to: Just van Rossum (jvr) Summary: Simple CarbonEvt.GetEventParameter implementation Initial Comment: Here's my first stab at an implementation of GetEventParameter. Pretty important, since if you are catching 'cmds' events (Command events) you need to get the event parameter to find out which command it was. Just, I reran CarbonEvtscan.py after applying this patch but my generated CarbonEvtmodule.c was missing many of the functions that yours seemed to pick up -- which version of the universal headers are you using? I know you are also running on OS 9 (right?) and I am running on OS X. I'd like to get it so we can both run the *scan file and get the same .c file. (I might have messed up something on my end this time, though...) ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2001-12-18 04:33 Message: Logged In: YES user_id=92689 Jack has some ideas to do this properly, but this looks good for a start, so I'll just check it in. I'm using Universal Headers 3.4, in CW6 on OSX. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494553&group_id=5470 From Multiactive Software Tue Dec 18 13:05:35 2001 From: Multiactive Software (Multiactive Software) Date: Tue, 18 Dec 2001 05:05:35 -0800 Subject: [Patches] Revolutionize your sales operations in 25 days - Guaranteed Message-ID: <200112181304.FAA10321@mail.multiactive.com> Multiactive CRM Success Guarantee
 
 
 


 Increase Profitability an= d 
Improve Customer Loyalty in 25 Days or Less.

Guaranteed.

 
Dear Business Professional,

Implementing a Customer Relationship Management solution c= an seem daunting. But increasing revenues and improving sales force efficiency is still a prio= rity for you. So Multiactive Software is taking the risk out of im= plementing a CRM solution for your sales, marketing, and customer service opera= tions with the new CRM Success Guarantee that guarantees rapid implement= ation and results at a fixed price. 

How are we so confident that we can help your business? Multiactive has been a leader in CRM solutions= since 1987, and our software has already helped over a million user= s worldwide.

Click here to find out how you can take advantage of this offer now.

WE GUARANTEE:

  • Implem= entation in 14 days or less

  • Return= on Investment (ROI) beginning in 25 days

  • Fixed = Price for the consultation, software, training, and support<= /b>

  • Succes= sful Results

YOU GET:

  • Professional Services: CRM consultation for your bus= iness
  • Software Licenses, Installation, and Configuration
  • On-site Training for administrators and end-users
  • Technical Support 
PLUS the flexibility and scalability to grow as your b= usiness grows.

Click here to get an instant quote based on your sales, marketing, and cust= omer service goals for a CRM solution.=20

What can Multiactive's CRM Solutions do for your business?

Whatever your business, Multiactive's CRM Solutions - Maxi= mizer Enterprise and Entice! - have the strength and flexibility yo= u need to exceed your customers' expectations.  And we are comm= itted to helping you reach your CRM goals  - without spend= ing millions of dollars, and without waiting months to see results. 

Maximizer Enterprise and Entice! are ide= al CRM solutions for small and medium-sized businesses that want to = get up and running right away so you can:

  • Increase revenue<= /b>
    Shorten your sales cycle and close more deals by efficiently managing every sales opportunity.

  • Improve customer satisfaction
    Cultivate long-lasting relationships and provide exceptional service by tracking every interaction.<= /li>

  • Increase retentio= n and loyalty
    Segment your customers and keep in contact with the= m regularly with Marketing Automation features.

PLUS:

  • Use the web to gener= ate and track your leads 

  • Easily track and pro= cess sales orders in real-time

  • Access and update in= formation from anywhere, anytime

  • Generate custom sale= s reports

  • Customize and integr= ate with your other systems

All at an affordable fixed price, implemented in 14 days= or less, so you can see a Return on your Investment starting in und= er 25 days. Guaranteed.

DON'= T WAIT.

This unprecedented offer is available only = for a LIMITED TIME. Don't let this guarantee for immediate ROI= on a CRM Solution pass you by.

If you're ready to see rapid results= with a CRM Solution, contact us today to speak to a CRM representative: = 1-888-535-4012.  Or click here for further details on this offer, or request more information by email.

CRM Success - Guaranteed.

=09

Multiactive Software, the CRM= Company, a leading provider of innovative customer relationship manageme= nt (CRM) and eBusiness solutions, is the maker of Maximizer, Maximizer En= terprise, Entice!, ecBuilder, and Personal PageBuilder. Established in 19= 88, Multiactive's offices in the U.S., Canada, Hong Kong, Australia, the = U.K., and Singapore support over 1 million customers. Copyright =A92001 Multiactive Software Inc. All rights reserved. Give us your feedback. Max= imizer product information: 1-888-535-4012. General information about Mul= tiactive Software Inc.: www.multiactive.com or info@multiactive.com

If you do not want to receive future emails from Multiactive Software, simply click on the following link:=09 Remove

 

 

 

 

 

 

 

 

 

 



 

<= font color=3D"#FFFFFF" size=3D"1">
Maximizer Enterprise or Entice!
Which one is right for you?
Find out more...
<= br> "Maximizer Enterprise is fantastic - it has direct= ly contributed to the success of our company! It enables u= s to better manage our data and synchronize information betw= een our account executives across the country, while also integ= rating with our other software. We rely heavily on its outstan= ding capabilities." 

- Signy Freysen, National Speakers Bureau

 
<= font size=3D"1" color=3D"#FFFFFF">
"Entice! is a lifesaver for tracking multiple sale= s cycles and assisting in client relationship management.= The features are easy to use, and our staff can access them= from home or the office. The Campaign Manager enables us to = reach out to hundreds of prospects and clients on a continuin= g basis to improve customer retention and loyalty." <= br>
- Cindy Preger, VP Marketing, MindBlaze.com

 
From noreply@sourceforge.net Tue Dec 18 13:59:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 05:59:58 -0800 Subject: [Patches] [ python-Patches-494582 ] cgitb docs and consistency fix Message-ID: Patches item #494582, was opened at 2001-12-18 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494582&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: cgitb docs and consistency fix Initial Comment: This updates the library documentation for cgitb. It also changes the name of a function in cgitb.py that was inconsistent with the documentation (handler -> handle). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494582&group_id=5470 From noreply@sourceforge.net Tue Dec 18 15:33:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 07:33:11 -0800 Subject: [Patches] [ python-Patches-494620 ] pydoc library documentation Message-ID: Patches item #494620, was opened at 2001-12-18 07:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494620&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pydoc library documentation Initial Comment: This patch adds libpydoc.tex and an entry for "help()" in libfuncs.tex. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494620&group_id=5470 From noreply@sourceforge.net Tue Dec 18 15:33:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 07:33:14 -0800 Subject: [Patches] [ python-Patches-494622 ] pydoc library documentation Message-ID: Patches item #494622, was opened at 2001-12-18 07:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494622&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pydoc library documentation Initial Comment: This patch adds libpydoc.tex and an entry for "help()" in libfuncs.tex. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494622&group_id=5470 From noreply@sourceforge.net Tue Dec 18 15:33:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 07:33:38 -0800 Subject: [Patches] [ python-Patches-494620 ] pydoc library documentation Message-ID: Patches item #494620, was opened at 2001-12-18 07:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494620&group_id=5470 Category: Documentation Group: None >Status: Deleted >Resolution: Duplicate Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pydoc library documentation Initial Comment: This patch adds libpydoc.tex and an entry for "help()" in libfuncs.tex. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494620&group_id=5470 From noreply@sourceforge.net Tue Dec 18 15:35:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 07:35:28 -0800 Subject: [Patches] [ python-Patches-494622 ] pydoc library documentation Message-ID: Patches item #494622, was opened at 2001-12-18 07:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494622&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pydoc library documentation Initial Comment: This patch adds libpydoc.tex and an entry for "help()" in libfuncs.tex. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2001-12-18 07:35 Message: Logged In: YES user_id=45338 This is pretty basic documentation, but it's a start. It just explains how to use help() and pydoc, but doesn't describe all of the functions in the module yet. You will need to add an \input{} line to lib.tex somewhere -- perhaps the Miscellaneous Services section? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494622&group_id=5470 From noreply@sourceforge.net Tue Dec 18 15:55:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 07:55:10 -0800 Subject: [Patches] [ python-Patches-494582 ] cgitb docs and consistency fix Message-ID: Patches item #494582, was opened at 2001-12-18 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494582&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: cgitb docs and consistency fix Initial Comment: This updates the library documentation for cgitb. It also changes the name of a function in cgitb.py that was inconsistent with the documentation (handler -> handle). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-18 07:55 Message: Logged In: YES user_id=3066 Checked in with a couple of small changes as Doc/lib/libcgitb.tex revision 1.2. Rejected the name change (handler->handle) as it's after the release candidate. I'm not convinced handle() is actually a better name; it seems about the same to me. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494582&group_id=5470 From noreply@sourceforge.net Tue Dec 18 16:34:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 08:34:42 -0800 Subject: [Patches] [ python-Patches-494622 ] pydoc library documentation Message-ID: Patches item #494622, was opened at 2001-12-18 07:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494622&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pydoc library documentation Initial Comment: This patch adds libpydoc.tex and an entry for "help()" in libfuncs.tex. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-18 08:34 Message: Logged In: YES user_id=3066 Added Doc/lib/libpydoc.tex; added help() description as Doc/lib/libfuncs.tex 1.100. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-12-18 07:35 Message: Logged In: YES user_id=45338 This is pretty basic documentation, but it's a start. It just explains how to use help() and pydoc, but doesn't describe all of the functions in the module yet. You will need to add an \input{} line to lib.tex somewhere -- perhaps the Miscellaneous Services section? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494622&group_id=5470 From noreply@sourceforge.net Tue Dec 18 22:39:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 14:39:54 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Wed Dec 19 00:36:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 16:36:50 -0800 Subject: [Patches] [ python-Patches-494845 ] Improvements for pygettext Message-ID: Patches item #494845, was opened at 2001-12-18 16:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494845&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jürgen Hermann (jhermann) Assigned to: Nobody/Anonymous (nobody) Summary: Improvements for pygettext Initial Comment: Added checks that _() only contains string literals, and command line args are resolved to module lists, i.e. you can now pass a filename, a module or package name, or a directory (including globbing chars, important for Win32). Made docstring fit in 80 chars wide displays using pydoc. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494845&group_id=5470 From mailer@mailer.ru Mon Dec 17 12:39:21 2001 From: mailer@mailer.ru (mailer) Date: Mon, 17 Dec 2001 18:39:21 +0600 Subject: [Patches] =?windows-1251?B?zvIg5O7x8u7p7e7pIP3q7u3u7OjoIC0g6iDk7vHy8+/t7ukg8O7x6g==?= =?windows-1251?B?7vjoIS4u?= Message-ID: <000901c186f7$da1a8620$32c8a8c0@webmaster> This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C1872A.24A42D40 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable =CF=EE=EB=F3=F7=E8=F2=E5 =E2=E0=F8=E5=E3=EE = =AB=E2=E5=F0=ED=EE=E3=EE=BB =F1=E5=EC=E5=E9=ED=EE=E3=EE = =F2=F3=F0=E0=E3=E5=ED=F2=E0, =F1=EF=EE=F1=EE=E1=ED=EE=E3=EE =EF=EE = =EF=E5=F0=E2=EE=EC=F3 =E6=E5 =C2=E0=F8=E5=EC=F3 =E7=E2=EE=ED=EA=F3 = =E2=E7=FF=F2=FC =ED=E0 =F1=E5=E1=FF =E2=F1=E5 =E7=E0=E1=EE=F2=FB =EE=E1 = =EE=F2=E4=FB=F5=E5 =E8 =EF=EE=E5=E7=E4=EA=E0=F5:=20 - =E4=EB=FF =C2=E0=F1, =C2=E0=F8=E5=E9 =F1=E5=EC=FC=E8, = =E4=F0=F3=E7=E5=E9, =EA=EE=EB=EB=E5=E3 =E8 =E7=ED=E0=EA=EE=EC=FB=F5. - =C7=E0=EF=EE=EB=ED=E8=F2=E5 =E1=EB=E0=ED=EA =E7=E0=FF=E2=EA=E8 =EF=EE = =E0=E4=F0=E5=F1=F3.=20 -------------------------------------------------------------------------= ------- =C5=F1=EB=E8 =C2=E0=F1 =ED=E5 =E7=E0=E8=ED=F2=E5=F0=E5=F1=EE=E2=E0=EB=EE = =ED=E0=F8=E5 =EF=F0=E5=E4=EB=EE=E6=E5=ED=E8=E5 =E8 =C2=FB = =E1=EE=EB=FC=F8=E5 =ED=E5 =F5=EE=F2=E8=F2=E5 =EF=EE=EB=F3=F7=E0=F2=FC = =FD=F2=F3 =F0=E0=F1=F1=FB=EB=EA=F3 - =EF=F0=E8=ED=EE=F1=E8=EC = =ED=E0=F8=E8 =E3=EB=F3=E1=EE=EA=E8=E5 =E8=E7=E2=E8=ED=E5=ED=E8=FF. = =CF=F0=EE=F1=F2=EE =EF=EE=F8=EB=E8=F2=E5 =EF=F3=F1=F2=EE=E5 = =EF=E8=F1=FC=EC=EE =F1 =E2=E0=F8=E8=EC E-Mail =ED=E0 =E0=E4=F0=E5=F1 = major-pain@yandex.ru =E8 =C2=FB =E1=F3=E4=E5=F2=E5 = =EE=F2=EA=EB=FE=F7=E5=ED=FB =EE=F2 =E4=E0=ED=ED=EE=E3=EE = =E8=ED=F4=EE=F0=EC=E0=F6=E8=EE=ED=ED=EE=E3=EE =F1=E5=F0=E2=E8=F1=E0 = =ED=E5=EC=E5=E4=EB=E5=ED=ED=EE. ------=_NextPart_000_0006_01C1872A.24A42D40 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
 
    = =CF=EE=EB=F3=F7=E8=F2=E5 =E2=E0=F8=E5=E3=EE=20 =AB=E2=E5=F0=ED=EE=E3=EE=BB =F1=E5=EC=E5=E9=ED=EE=E3=EE = =F2=F3=F0=E0=E3=E5=ED=F2=E0, =F1=EF=EE=F1=EE=E1=ED=EE=E3=EE =EF=EE=20 =EF=E5=F0=E2=EE=EC=F3 =E6=E5 =C2=E0=F8=E5=EC=F3 =E7=E2=EE=ED=EA=F3 = =E2=E7=FF=F2=FC =ED=E0 =F1=E5=E1=FF =E2=F1=E5 =E7=E0=E1=EE=F2=FB =EE=E1 = =EE=F2=E4=FB=F5=E5 =E8 =EF=EE=E5=E7=E4=EA=E0=F5:=20
 
 - =E4=EB=FF = =C2=E0=F1, =C2=E0=F8=E5=E9 =F1=E5=EC=FC=E8, =E4=F0=F3=E7=E5=E9, = =EA=EE=EB=EB=E5=E3 =E8 =E7=ED=E0=EA=EE=EC=FB=F5.
 
 - = =C7=E0=EF=EE=EB=ED=E8=F2=E5 =E1=EB=E0=ED=EA =E7=E0=FF=E2=EA=E8 =EF=EE=20 =E0=E4=F0=E5=F1=F3= . 
 
=C5=F1=EB=E8 =C2=E0=F1 = =ED=E5 =E7=E0=E8=ED=F2=E5=F0=E5=F1=EE=E2=E0=EB=EE =ED=E0=F8=E5=20 =EF=F0=E5=E4=EB=EE=E6=E5=ED=E8=E5 =E8 =C2=FB =E1=EE=EB=FC=F8=E5 =ED=E5 = =F5=EE=F2=E8=F2=E5 =EF=EE=EB=F3=F7=E0=F2=FC =FD=F2=F3=20 =F0=E0=F1=F1=FB=EB=EA=F3 - =EF=F0=E8=ED=EE=F1=E8=EC =ED=E0=F8=E8 = =E3=EB=F3=E1=EE=EA=E8=E5 =E8=E7=E2=E8=ED=E5=ED=E8=FF. =CF=F0=EE=F1=F2=EE = =EF=EE=F8=EB=E8=F2=E5 =EF=F3=F1=F2=EE=E5 = =EF=E8=F1=FC=EC=EE =F1 =E2=E0=F8=E8=EC E-Mail =ED=E0 =E0=E4=F0=E5=F1 major-pain@yandex.ru = =E8 =C2=FB =E1=F3=E4=E5=F2=E5 =EE=F2=EA=EB=FE=F7=E5=ED=FB =EE=F2 = =E4=E0=ED=ED=EE=E3=EE=20 =E8=ED=F4=EE=F0=EC=E0=F6=E8=EE=ED=ED=EE=E3=EE =F1=E5=F0=E2=E8=F1=E0 = =ED=E5=EC=E5=E4=EB=E5=ED=ED=EE.
 
------=_NextPart_000_0006_01C1872A.24A42D40-- From noreply@sourceforge.net Wed Dec 19 01:58:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 17:58:42 -0800 Subject: [Patches] [ python-Patches-494863 ] file.xreadlines() should raise exception Message-ID: Patches item #494863, was opened at 2001-12-18 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: file.xreadlines() should raise exception Initial Comment: file.xreadlines() should raise a ValueError when the file is closed All other file methods raise ValueError except close() there's another patch that tests this feature and other file methods ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470 From noreply@sourceforge.net Wed Dec 19 02:04:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 18:04:47 -0800 Subject: [Patches] [ python-Patches-494867 ] updated test_file.py Message-ID: Patches item #494867, was opened at 2001-12-18 18:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494867&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: updated test_file.py Initial Comment: test that file methods raise ValueError when called after the file has been closed also test isatty() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494867&group_id=5470 From noreply@sourceforge.net Wed Dec 19 02:16:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 18:16:26 -0800 Subject: [Patches] [ python-Patches-494871 ] test exceptions in various types/methods Message-ID: Patches item #494871, was opened at 2001-12-18 18:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494871&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test exceptions in various types/methods Initial Comment: Add a bunch of tests for various methods, including numeric stuff like: float('') float('5\0') 5.0 / 0.0 5.0 // 0.0 5.0 % 0.0 5 << -5 sequence stuff like: ()[0] x += () [].pop() [].extend(None) {}.values() {}.items() not sure if buffer stuff should go here. if so, need to update X.X.X to be a real number, not sure if there is any correlation of the numbers or should the next available be used (6.7) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494871&group_id=5470 From noreply@sourceforge.net Wed Dec 19 02:18:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 18:18:07 -0800 Subject: [Patches] [ python-Patches-494872 ] test repr() of a built-in module Message-ID: Patches item #494872, was opened at 2001-12-18 18:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494872&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test repr() of a built-in module Initial Comment: repr(sys) just to get test coverage of calling repr() on a built-in module ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494872&group_id=5470 From noreply@sourceforge.net Wed Dec 19 02:19:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 18:19:45 -0800 Subject: [Patches] [ python-Patches-494873 ] add tests for complex numbers Message-ID: Patches item #494873, was opened at 2001-12-18 18:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494873&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: add tests for complex numbers Initial Comment: add various tests for complex numbers to improve test coverage ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494873&group_id=5470 From noreply@sourceforge.net Wed Dec 19 02:21:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 18:21:21 -0800 Subject: [Patches] [ python-Patches-494874 ] add tests for int()/long() Message-ID: Patches item #494874, was opened at 2001-12-18 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494874&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: add tests for int()/long() Initial Comment: test invalid params to int() & long (ie, they should raise exceptions) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494874&group_id=5470 From noreply@sourceforge.net Wed Dec 19 02:22:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 18:22:21 -0800 Subject: [Patches] [ python-Patches-494876 ] test invalid params to pow() Message-ID: Patches item #494876, was opened at 2001-12-18 18:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494876&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test invalid params to pow() Initial Comment: tests invalid parameter values to pow() to verify exceptions are raised and improve test coverage ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494876&group_id=5470 From noreply@sourceforge.net Wed Dec 19 03:20:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 19:20:44 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 19:20 Message: Logged In: YES user_id=6380 That looks like a fine context diff to me. Please be sure to use the current CVS if you can! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Wed Dec 19 15:39:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 07:39:27 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- >Comment By: Brad Clements (bkc) Date: 2001-12-19 07:39 Message: Logged In: YES user_id=4631 I used the win CVS "update" command on the entire source tree yesterday. I have not specified a particular tag. Are you saying that opcode.h rev 2.37 is not current, or is "please use the current cvs" a standard cautionary note? Sorry to be anal, I want this to be seamless for you so I feel I have botched it up already. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 19:20 Message: Logged In: YES user_id=6380 That looks like a fine context diff to me. Please be sure to use the current CVS if you can! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Wed Dec 19 16:05:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 08:05:40 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-19 08:05 Message: Logged In: YES user_id=6380 Standard cautionary note. Sorry. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-19 07:39 Message: Logged In: YES user_id=4631 I used the win CVS "update" command on the entire source tree yesterday. I have not specified a particular tag. Are you saying that opcode.h rev 2.37 is not current, or is "please use the current cvs" a standard cautionary note? Sorry to be anal, I want this to be seamless for you so I feel I have botched it up already. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 19:20 Message: Logged In: YES user_id=6380 That looks like a fine context diff to me. Please be sure to use the current CVS if you can! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Wed Dec 19 20:29:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 12:29:30 -0800 Subject: [Patches] [ python-Patches-494384 ] Missing --disable-unicode patch Message-ID: Patches item #494384, was opened at 2001-12-17 15:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494384&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 8 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Missing --disable-unicode patch Initial Comment: Since ceval.c 2.290, --disable-unicode is broken; the attached patch wraps the offending code. This patch should be added for 2.2 for the feature to be useful at all. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:29 Message: Logged In: YES user_id=21627 Committed as ceval.c 2.300. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 16:12 Message: Logged In: YES user_id=31435 Accepted and back to Martin for checkin. Or did you want me to check it in? If so, assign it back to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494384&group_id=5470 From noreply@sourceforge.net Thu Dec 20 17:14:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 09:14:48 -0800 Subject: [Patches] [ python-Patches-494582 ] cgitb docs and consistency fix Message-ID: Patches item #494582, was opened at 2001-12-18 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494582&group_id=5470 Category: Documentation Group: None Status: Closed Resolution: Accepted Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: cgitb docs and consistency fix Initial Comment: This updates the library documentation for cgitb. It also changes the name of a function in cgitb.py that was inconsistent with the documentation (handler -> handle). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-20 09:14 Message: Logged In: YES user_id=3066 Re-applied the patch, using the right version this time. Checked in as Doc/lib/libcgi.tex revision 1.35 and Doc/lib/libcgitb.tex revision 1.3. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-18 07:55 Message: Logged In: YES user_id=3066 Checked in with a couple of small changes as Doc/lib/libcgitb.tex revision 1.2. Rejected the name change (handler->handle) as it's after the release candidate. I'm not convinced handle() is actually a better name; it seems about the same to me. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494582&group_id=5470 From noreply@sourceforge.net Thu Dec 20 20:42:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 12:42:32 -0800 Subject: [Patches] [ python-Patches-495598 ] add an -q (quiet) option to pycompile Message-ID: Patches item #495598, was opened at 2001-12-20 12:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=495598&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: add an -q (quiet) option to pycompile Initial Comment: this patch is applied to Debian's python packages for more than two years allowing quiet batch compilations. --- python2.2-2.2.orig/Lib/compileall.py Wed Apr 18 03:20:21 2001 +++ python2.2-2.2/Lib/compileall.py Sun Sep 30 22:30:32 2001 @@ -4,6 +4,8 @@ given as arguments recursively; the -l option prevents it from recursing into directories. +DEBIAN adds an -q option for more quiet operation. + Without arguments, if compiles all modules on sys.path, without recursing into subdirectories. (Even though it should do so for packages -- for now, you'll have to deal with packages separately.) @@ -19,7 +21,7 @@ __all__ = ["compile_dir","compile_path"] -def compile_dir(dir, maxlevels=10, ddir=None, force=0, rx=None): +def compile_dir(dir, maxlevels=10, ddir=None, force=0, rx=None, quiet=0): """Byte-compile all modules in the given directory tree. Arguments (only dir is required): @@ -29,9 +31,10 @@ ddir: if given, purported directory name (this is the directory name that will show up in error messages) force: if 1, force compilation, even if timestamps are up-to-date + quiet: if 1, be quiet during compilation """ - print 'Listing', dir, '...' + if not quiet: print 'Listing', dir, '...' try: names = os.listdir(dir) except os.error: @@ -57,7 +60,7 @@ try: ctime = os.stat(cfile) [stat.ST_MTIME] except os.error: ctime = 0 if (ctime > ftime) and not force: continue - print 'Compiling', fullname, '...' + if not quiet: print 'Compiling', fullname, '...' try: ok = py_compile.compile(fullname, None, dfile) except KeyboardInterrupt: @@ -77,11 +80,11 @@ name != os.curdir and name != os.pardir and \ os.path.isdir(fullname) and \ not os.path.islink(fullname): - if not compile_dir(fullname, maxlevels - 1, dfile, force, rx): + if not compile_dir(fullname, maxlevels - 1, dfile, force, rx, quiet): success = 0 return success -def compile_path(skip_curdir=1, maxlevels=0, force=0): +def compile_path(skip_curdir=1, maxlevels=0, force=0, quiet=0): """Byte-compile all module on sys.path. Arguments (all optional): @@ -89,6 +92,7 @@ skip_curdir: if true, skip current directory (default true) maxlevels: max recursion level (default 0) force: as for compile_dir() (default 0) + quiet: as for compile_dir() (default 0) """ success = 1 @@ -96,20 +100,21 @@ if (not dir or dir == os.curdir) and skip_curdir: print 'Skipping current directory' else: - success = success and compile_dir(dir, maxlevels, None, force) + success = success and compile_dir(dir, maxlevels, None, force, quiet) return success def main(): """Script main program.""" import getopt try: - opts, args = getopt.getopt(sys.argv [1:], 'lfd:x:') + opts, args = getopt.getopt(sys.argv [1:], 'lfqd:x:') except getopt.error, msg: print msg - print "usage: python compileall.py [-l] [-f] [-d destdir] " \ + print "usage: python compileall.py [-l] [-f] [-q] [-d destdir] " \ "[-s regexp] [directory ...]" print "-l: don't recurse down" print "-f: force rebuild even if timestamps are up-to-date" + print "-q: quiet operation" print "-d destdir: purported directory name for error messages" print " if no directory arguments, -l sys.path is assumed" print "-x regexp: skip files matching the regular expression regexp" @@ -118,11 +123,13 @@ maxlevels = 10 ddir = None force = 0 + quiet = 0 rx = None for o, a in opts: if o == '-l': maxlevels = 0 if o == '-d': ddir = a if o == '-f': force = 1 + if o == '-q': quiet = 1 if o == '-x': import re rx = re.compile(a) @@ -134,7 +141,7 @@ try: if args: for dir in args: - if not compile_dir(dir, maxlevels, ddir, force, rx): + if not compile_dir(dir, maxlevels, ddir, force, rx, quiet): success = 0 else: success = compile_path() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=495598&group_id=5470 From noreply@sourceforge.net Fri Dec 21 00:37:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 16:37:19 -0800 Subject: [Patches] [ python-Patches-495688 ] Make site.py more friendly to PDAs Message-ID: Patches item #495688, was opened at 2001-12-20 16:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=495688&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phil Thompson (philthompson) Assigned to: Nobody/Anonymous (nobody) Summary: Make site.py more friendly to PDAs Initial Comment: site.py requires distutils and pydoc which are both unfriendly to devices with little memory like PDAs. This patch makes site.py cope with distutils and pydoc not being installed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=495688&group_id=5470 From noreply@sourceforge.net Fri Dec 21 14:56:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 06:56:45 -0800 Subject: [Patches] [ python-Patches-494845 ] Improvements for pygettext Message-ID: Patches item #494845, was opened at 2001-12-18 16:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494845&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jürgen Hermann (jhermann) >Assigned to: Barry Warsaw (bwarsaw) Summary: Improvements for pygettext Initial Comment: Added checks that _() only contains string literals, and command line args are resolved to module lists, i.e. you can now pass a filename, a module or package name, or a directory (including globbing chars, important for Win32). Made docstring fit in 80 chars wide displays using pydoc. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494845&group_id=5470 From noreply@sourceforge.net Fri Dec 21 15:03:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 07:03:29 -0800 Subject: [Patches] [ python-Patches-490456 ] Unicode support in email.Utils.encode Message-ID: Patches item #490456, was opened at 2001-12-07 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490456&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Zabaluev (mzabaluev) >Assigned to: Barry Warsaw (bwarsaw) Summary: Unicode support in email.Utils.encode Initial Comment: It's essentially an updated patch 486375, this time making a distinction of type for the passed string; if it's Unicode, the function encodes it to the character set specified as the charset parameter. The reasons: 1. The function in its current version doesn't support Unicode, throwing an exception if any non-ASCII characters are found within it. 2. With this patch, we reach a sort of operational symmetry on email.Utils.encode vs email.Utils.decode, as it can be seen in the tests. ---------------------------------------------------------------------- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2001-12-11 14:52 Message: Logged In: YES user_id=313104 2loewis: In a typical email application, it'd be better to display partially encoded text than to face a hard stop when trying to process a message, hence 'replace'. Actually, the encoding mode could be an optional parameter, but I don't feel like deciding on parameters for a function not developed by me. Barry? The isinstance part seems to be valid, I'm updating the patch here accordingly. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 10:28 Message: Logged In: YES user_id=21627 The patch looks good, except that I cannot really see the value in using "replace" for .encode. Wouldn't it be better to get an exception if the Unicode string contains an un-encodable character? Also, the Python 2.2 way to spell the type test is if isinstance(s, unicode) This makes use of the fact that the unicode builtin is a type now, and it supports unicode subtypes. This is a minor change, of course. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490456&group_id=5470 From noreply@sourceforge.net Sat Dec 22 13:41:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 05:41:13 -0800 Subject: [Patches] [ python-Patches-496096 ] Mach-O MacPython IDE! Message-ID: Patches item #496096, was opened at 2001-12-22 05:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496096&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Donovan Preston (dsposx) Assigned to: Jack Jansen (jackjansen) Summary: Mach-O MacPython IDE! Initial Comment: Here it is... the moment we've all been waiting for... the MacPython IDE running in a bundle under Unix Python! It's a beautiful thing. Most everything works flawlessly. One major point though... it's always asking you to convert UNIX line endings to mac line endings! Heh. p.s. Jack: I took the quick route and assumed paths passed to FSSpec_New were slash- delimited. It works at least, and the ability to specify the delimiter can be added later. I wanted to get this in CVS ASAP. Donovan ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496096&group_id=5470 From alc20020@mailcity.com Sat Dec 22 15:37:31 2001 From: alc20020@mailcity.com (ALC) Date: Sat, 22 Dec 2001 07:37:31 PST Subject: [Patches] American Language Center- 156-0000 Merry Christmas! Message-ID: <22120100003$999219783670864$1303146628$0@exploder4.em5000.net> --------------100898622119526 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------100898622119526 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ALC

Merry Christmas / Поздравляем с Рождеством
Центр Американского Английского
Call Now! Звоните Cейчас. Visit Today! Приходите Сегодня.
156-00-00, 159-57-34
Английский разговорный с преподавателями из США

МЫШЛЕНИЕ, ПРОИЗНОШЕНИЕ, СТИЛЬ РЕЧИ
Эксклюзивная авторская методика
Все стадии обучения : от нуля до высшего

ПРИЕМЛЕМЫЕ ЦЕНЫ плюс ВЫСШЕЕ КАЧЕСТВО

LOWEST CHARGES plus HIGHEST GRATIFICATION

Moscow, Russia
Aдрес: М. Кропоткинская, Гоголевский бульвар, д.14, конгресс-зал Консультации Понедельник -Субботa ежедневно 12-13 / 18-19

GEE!! ELECTRIFY YOUR LIFE- УКРАСЬТЕ ЖИЗНЬ. НАУЧИТЕCЬ ПОНИМАТЬ ПЕСНИ И ФИЛЬМЫ!
Said I loved you but I lied. Cause this is more then love I feel inside. COMPLIMENT HER
Said I loved you but I was wrong Cause love could never ever feel so strong. CUDDLE HER
Need you forever, I need you to stay. You are the one. You are the one........ Michael Bolton
Unbreak my heart. Say you'll love me again Undo this hurt you caused KISS HER STROKE HER TEASE HER
When you walked out the door And walked outta my life COMFORT HER PROTECT HER CARESS HER LOVE HER
Uncry these tears I cried so many nights Unbreak my heart, my heart . .....Toni Braxton HOLD HER
Английский разговорный с преподавателями из США   Could I hold you for a lifetime
Could I could I have this kiss forever, forever Enrique Iglesias / Whitney Houston   Could I look into your eyes
МЫШЛЕНИЕ, ПРОИЗНОШЕНИЕ, СТИЛЬ РЕЧИ Could I have this night to share this night together
ВСЕ СТАДИИ ОБУЧЕНИЯ : ОТ НУЛЯ ДО ВЫСШЕГО! Could I hold you close beside me..
ЛЕГКО, ВЕСЕЛО, ГИБКИЙ ГРАФИК, КОМФОРТНЫЕ ЗАНЯТИЯ, НОВЫЕ ЗНАКОМСТВА Could I hold you for all times
АССОЦИАТИВНО-ОБРАЗНАЯ ЭКСКЛЮЗИВНАЯ МЕТОДИКА. Could I could I have this kiss forever?...
 "To be irreplaceable one must always be different." -- Gabrielle “Coco” Chanel ВАШ ВОЗРАСТ ТОЛЬКО ПОМОЖЕТ ВАМ.
BREATHTAKING CAPTIVATION               EXHILARATING ENTRAPMENT              AWESOME ADORATION
Как нас найти Расписание и оплата
Для записи в группы наши американцы проводят консультации ежедневно с 12 до 13 или с 18 до 19 по адресу: Москва, Россия, М. Кропоткинская, Гоголевский бульвар, д.14, конгресс-зал Очень легко найти. Центральный Дом Шахматиста. 1 минута от метро.
Выход к Гоголевскому бульвару. Воскресение - выходной.		 5 уровней обучения. три раза в неделю.
График: Понедельник-Среда-Пятница или Вторник-Четверг-Суббота. Время разговорного тренинга по вашему выбору будет с 9 до 11 или 11 до 13 или 16 до 18 или 19 до 21. Стоимость 100 у.е. за 1 уровень/ 1 месяц в рублях по курсу продажи доллара на день оплаты.
ENIGMATIC INFATUATION                     MESMERIZING INSPIRATION                  BAFFLING ATTRACTION
НАЧИНАЕТСЯ СЕЗОН СКИДОК. СПЕШИТЕ ИЗМЕНИТЬ СВОЕ БУДУЩЕЕ. CHARISMATIC MUSE
THRILLING WORSHIP      AROUSING LOVE           MAGNETIC OBSESSION          ALLURING PASSION
Your warmth makes me cosy during biting chill of the winter ENCHANTING FASCINATION
Your joy doubles mine in the blight and fresh spring MIND - BOGGLING TEMPTATION
Your love shelters me in the scorching heat of the summer MYSTERIOUS ENTICEMENT
Your cheer sweeps away the pain in the unfavourable autumn CAPTIVATING CHARM

To really love a woman. To understand her –you need to know her deep inside SPEND MONEY ON HER
Hear every thought-see every dream And give her wings when she wants to fly…. Bryan Adams

What do I do to make you want me What have I got to do to be heard WINE & DINE HER
What do I say when it's all over And sorry seems to be the hardest word….. Joe Cocker LISTEN TO HER

I watched the sound of the shore - I'd give you the world if it was mine
Feels like you're mine feels right so fine I'm yours your mine like paradise…DANCE WITH HER
oooh what a life,           oooh what a life …..      like paradise……      Sade   STAND BY HER

PERFECT YOUR GRAMMAR, PREPOSITIONS , GENERAL AND BUSINESS VOCABULARY, CONVERSATION.
УСОВЕРШЕНСТВУЙТЕ ВАШУ ГРАММАТИКУ, ПРЕДЛОГИ, ОБШЕУПОТРЕБИМУЮ И ДЕЛОВУЮ ЛЕКСИКУ,
CТИЛЬ РЕЧИ. The boss really threw a bash last night! “How does that sound?”
НАИБОЛЕЕ ПОЛНАЯ И ПРОСТАЯ МЕТОДИКА АНГЛИЙСКОГО РАЗГОВОРНОГО ЯЗЫКА
Learn how to speak & understand slang. Give me a break! I can’t stand her. Let’s wrap it up.
НАУЧИТЕСЬ, КАК ГОВОРИТЬ И ПОНИМАТЬ СЛЕНГ. I’ll get totally plastered. Beats me!
American business slang & jargon   Be nice to him. He’s backing the show! I live in the Big Apple.
at school/ at the party/ at the movies/ at the mall/ the new car On second thought, I’ll go to France.
at the gym/the house guest/ at work/at the market/ at the restaurant/ Jennifer is a hot-looking chick.
at the nightclub/at the record store/ sport terms used in business Dan doesn’t have the guts to do it.
slang used in TV comedies/ TV dramas / TV news /TV sports news/ She’s stacked. What a knock out.
general office / computer/ meeting/ negotiation slangs I’m breaking out in a cold sweat!
business travel/ marketing/ advertising/office party jargons Her company is going to go belly up!
finance slang& jargon/ sport terms used in business.  I didn’t know her old dude was loaded.
Best of the idioms. I am a history. Tomorrow I am getting hitched. I am getting cold feet.
In a word, all сonversational english is at your fingertips. I always play second banana to her.
ОДНИМ СЛОВОМ, ВЕСЬ РАЗГОВОРНЫЙ АНГЛИЙСКИЙ В ВАШЕМ РАСПОРЯЖЕНИИИ

Если вы хотите удалить свой адрес из списка рассылки, пошлите это же письмо на адрес отправителя со словом "remove" в поле "Тема"
For unsubscribe information, please reply to this message with the word "remove" in the subject line.

-------------------------------------

To unsubscribe, please click or copy and paste the following address into your browser:
http://em5000.com/unsub.php?client=twisted_solo&listname=solo_46&email=patches@python.org




em5000.com
--------------100898622119526-- From noreply@sourceforge.net Sun Dec 23 22:02:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Dec 2001 14:02:53 -0800 Subject: [Patches] [ python-Patches-420565 ] makes setup.py search sys.prefix Message-ID: Patches item #420565, was opened at 2001-05-01 14:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470 Category: Distutils and setup.py Group: None >Status: Open Resolution: Later Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Michael Hudson (mwh) Summary: makes setup.py search sys.prefix Initial Comment: It's useful to have setup.py search the lib and include directories in sys.prefix before it checks /usr/local. That way, if you are building Python into a custom location and want it to use the the libraries installed there rather than the system defaults, you can give the --prefix option to configure and setup.py will search that path first. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-23 14:02 Message: Logged In: YES user_id=6656 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 08:10 Message: Logged In: YES user_id=6656 Umm, yeah sure. I think I'd rather use sysconfig.get_config_var("LIBDIR") than sys.prefix+"/lib", though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:59 Message: Logged In: YES user_id=6380 Michael, can you have a look at this for Python 2.3 (or 2.2.1)? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-01 08:19 Message: Logged In: NO I totally agree. I'm building for hard hat linux on a debian host, and the implicit search in /usr/lib is totally the wrong thing to do in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470 From noreply@sourceforge.net Tue Dec 25 19:09:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 25 Dec 2001 11:09:38 -0800 Subject: [Patches] [ python-Patches-486438 ] makes doctest.testmod() to work Message-ID: Patches item #486438, was opened at 2001-11-28 04:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486438&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Postponed Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Tim Peters (tim_one) Summary: makes doctest.testmod() to work Initial Comment: testmod() can now be called with no arguments, in which case it works on the current module. This is a big convenience for self-testing modules. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-25 11:09 Message: Logged In: YES user_id=31435 Now that 2.2 is out, changed the Postponed status back to None (although I fear it may remain Postponed anyway -- SF doesn't seem to like resetting a Resolution to None). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-28 09:34 Message: Logged In: YES user_id=31435 Assigned to me, and Postponed (2.2 is in feature freeze). When resurrected, will try to find Skip's old patch (email'ed?) for this and combine them. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486438&group_id=5470 From noreply@sourceforge.net Tue Dec 25 19:10:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 25 Dec 2001 11:10:21 -0800 Subject: [Patches] [ python-Patches-486438 ] makes doctest.testmod() to work Message-ID: Patches item #486438, was opened at 2001-11-28 04:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486438&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Postponed Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Tim Peters (tim_one) Summary: makes doctest.testmod() to work Initial Comment: testmod() can now be called with no arguments, in which case it works on the current module. This is a big convenience for self-testing modules. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-25 11:10 Message: Logged In: YES user_id=31435 Yup, it's stuck at Postponed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-25 11:09 Message: Logged In: YES user_id=31435 Now that 2.2 is out, changed the Postponed status back to None (although I fear it may remain Postponed anyway -- SF doesn't seem to like resetting a Resolution to None). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-28 09:34 Message: Logged In: YES user_id=31435 Assigned to me, and Postponed (2.2 is in feature freeze). When resurrected, will try to find Skip's old patch (email'ed?) for this and combine them. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486438&group_id=5470 From noreply@sourceforge.net Wed Dec 26 02:19:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 25 Dec 2001 18:19:11 -0800 Subject: [Patches] [ python-Patches-496705 ] Additions & corrections to libmacui.tex Message-ID: Patches item #496705, was opened at 2001-12-25 18:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496705&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dean Draayer (draayer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Additions & corrections to libmacui.tex Initial Comment: Includes a thorough description of the relatively new GetArgv function. Greatly expanded the description of the ProgressBar class, as well as updating the description to reflect recent changes to this class. Numerous minor changes - mostly grammatical - made throughout the document. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496705&group_id=5470 From noreply@sourceforge.net Wed Dec 26 16:00:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 08:00:09 -0800 Subject: [Patches] [ python-Patches-496796 ] update modulator to use re, gen ansi c Message-ID: Patches item #496796, was opened at 2001-12-26 08:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496796&group_id=5470 Category: Demos and tools Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Jens B. Jorgensen (jensbjorgensen) Assigned to: Nobody/Anonymous (nobody) Summary: update modulator to use re, gen ansi c Initial Comment: I found that the modulator utility in the Tools wouldn't work any more, apparently only because it was using regex rather than re. I fixed that and also changed the template files to generate ANSI C function definitions rather than K&R C style. I'm running presently: ActivePython 2.1, build 211 (ActiveState) based on Python 2.1 (#15, Jun 18 2001, 21:42:28) [MSC 32 bit (Intel)] on win32 I don't think the changes should have any problems running with the current version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496796&group_id=5470 From noreply@sourceforge.net Wed Dec 26 16:01:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 08:01:42 -0800 Subject: [Patches] [ python-Patches-496796 ] update modulator to use re, gen ansi c Message-ID: Patches item #496796, was opened at 2001-12-26 08:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496796&group_id=5470 Category: Demos and tools Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Jens B. Jorgensen (jensbjorgensen) >Assigned to: Jack Jansen (jackjansen) Summary: update modulator to use re, gen ansi c Initial Comment: I found that the modulator utility in the Tools wouldn't work any more, apparently only because it was using regex rather than re. I fixed that and also changed the template files to generate ANSI C function definitions rather than K&R C style. I'm running presently: ActivePython 2.1, build 211 (ActiveState) based on Python 2.1 (#15, Jun 18 2001, 21:42:28) [MSC 32 bit (Intel)] on win32 I don't think the changes should have any problems running with the current version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496796&group_id=5470 From noreply@sourceforge.net Wed Dec 26 21:59:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 13:59:31 -0800 Subject: [Patches] [ python-Patches-496882 ] Echo readline() reply to stdout Message-ID: Patches item #496882, was opened at 2001-12-26 13:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496882&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dean Draayer (draayer) Assigned to: Jack Jansen (jackjansen) Summary: Echo readline() reply to stdout Initial Comment: The readline() method in SimpleStdin gets its input from an AskString() dialog box. Although the prompt from a raw_input() call gets printed to stdout, the user's reply (obtained via the dialog box from readline()) is not echoed back. This patch rectifies this problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496882&group_id=5470 From noreply@sourceforge.net Wed Dec 26 22:31:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 14:31:25 -0800 Subject: [Patches] [ python-Patches-496882 ] Echo readline() reply to stdout Message-ID: Patches item #496882, was opened at 2001-12-26 13:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496882&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dean Draayer (draayer) >Assigned to: Just van Rossum (jvr) Summary: Echo readline() reply to stdout Initial Comment: The readline() method in SimpleStdin gets its input from an AskString() dialog box. Although the prompt from a raw_input() call gets printed to stdout, the user's reply (obtained via the dialog box from readline()) is not echoed back. This patch rectifies this problem. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-26 14:31 Message: Logged In: YES user_id=45365 This is an IDE patch, so I'm assigning it to Just. Also, I remember that we discussed a similar patch at some point in the past, and I vaguely remember that there were some reasons not to do this, or something (can I get more vague? :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496882&group_id=5470 From noreply@sourceforge.net Wed Dec 26 22:46:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 14:46:55 -0800 Subject: [Patches] [ python-Patches-496905 ] Don't build curses on MacOSX Message-ID: Patches item #496905, was opened at 2001-12-26 14:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496905&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: Don't build curses on MacOSX Initial Comment: Curses doesn't build on MacOSX, but the test used for this in setup.py only works up until 10.1.0, from 10.1.1 onwards the release numbering scheme has changed. This patch addresses that. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496905&group_id=5470 From noreply@sourceforge.net Thu Dec 27 10:32:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 02:32:24 -0800 Subject: [Patches] [ python-Patches-496882 ] Echo readline() reply to stdout Message-ID: Patches item #496882, was opened at 2001-12-26 13:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496882&group_id=5470 Category: Macintosh Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Dean Draayer (draayer) Assigned to: Just van Rossum (jvr) Summary: Echo readline() reply to stdout Initial Comment: The readline() method in SimpleStdin gets its input from an AskString() dialog box. Although the prompt from a raw_input() call gets printed to stdout, the user's reply (obtained via the dialog box from readline()) is not echoed back. This patch rectifies this problem. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2001-12-27 02:32 Message: Logged In: YES user_id=92689 I've checked in a modified version of this patch. (Dean: while the other mods you made do make sense, they distracted from the *real* patch...) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-26 14:31 Message: Logged In: YES user_id=45365 This is an IDE patch, so I'm assigning it to Just. Also, I remember that we discussed a similar patch at some point in the past, and I vaguely remember that there were some reasons not to do this, or something (can I get more vague? :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496882&group_id=5470 From noreply@sourceforge.net Thu Dec 27 18:15:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 10:15:09 -0800 Subject: [Patches] [ python-Patches-497097 ] location of mbox Message-ID: Patches item #497097, was opened at 2001-12-27 10:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497097&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: location of mbox Initial Comment: Most mail spools now are under /var, so this seems to be a better default. --- python2.1-2.1.1.orig/Lib/mailbox.py +++ python2.1-2.1.1/Lib/mailbox.py @@ -267,7 +267,7 @@ if mbox[:1] == '+': mbox = os.environ['HOME'] + '/Mail/' + mbox [1:] elif not '/' in mbox: - mbox = '/usr/mail/' + mbox + mbox = '/var/mail/' + mbox if os.path.isdir(mbox): if os.path.isdir(os.path.join(mbox, 'cur')): mb = Maildir(mbox) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497097&group_id=5470 From noreply@sourceforge.net Thu Dec 27 18:39:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 10:39:12 -0800 Subject: [Patches] [ python-Patches-497098 ] build support for GNU/Hurd Message-ID: Patches item #497098, was opened at 2001-12-27 10:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: build support for GNU/Hurd Initial Comment: Attached is a patch to build python 2.2 on GNU/Hurd. The patch was originally submitted by James A Morrison to the Debian BTS. If wanted, a patch for 2.1.1 can be provided as well. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 From noreply@sourceforge.net Thu Dec 27 18:42:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 10:42:52 -0800 Subject: [Patches] [ python-Patches-497099 ] GNU/Hurd doesn't have large file support Message-ID: Patches item #497099, was opened at 2001-12-27 10:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497099&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: GNU/Hurd doesn't have large file support Initial Comment: [extracted from http://bugs.debian.org/118189, submitted by James A Morrison ] The configure script thinks GNU/Hurd has large file support but it doesn't. Instead the check for Large File support should be checking to see if a program compiles with the symbol _LFS_LARGEFILE. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497099&group_id=5470 From noreply@sourceforge.net Thu Dec 27 18:51:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 10:51:43 -0800 Subject: [Patches] [ python-Patches-497102 ] building a shared python library Message-ID: Patches item #497102, was opened at 2001-12-27 10:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497102&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: building a shared python library Initial Comment: This patch allows builing of libpython.so in addition to build libpython.a. The patch currently is used for building the python package on Debian GNU/Linux, so it needs to be cleaned up for other architectures. However python already has support for building shared libs, so this should not be a major problem. Feedback for a cleanup of the patch is appreciated. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497102&group_id=5470 From noreply@sourceforge.net Thu Dec 27 21:51:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 13:51:37 -0800 Subject: [Patches] [ python-Patches-496905 ] Don't build curses on MacOSX Message-ID: Patches item #496905, was opened at 2001-12-26 14:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496905&group_id=5470 Category: Build Group: Python 2.1.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: Don't build curses on MacOSX Initial Comment: Curses doesn't build on MacOSX, but the test used for this in setup.py only works up until 10.1.0, from 10.1.1 onwards the release numbering scheme has changed. This patch addresses that. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-27 13:51 Message: Logged In: YES user_id=45365 Checked in as setup.py 1.38.2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496905&group_id=5470 From noreply@sourceforge.net Thu Dec 27 21:52:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 13:52:43 -0800 Subject: [Patches] [ python-Patches-496905 ] Don't build curses on MacOSX Message-ID: Patches item #496905, was opened at 2001-12-26 14:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496905&group_id=5470 Category: Build Group: Python 2.1.2 Status: Closed Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: Don't build curses on MacOSX Initial Comment: Curses doesn't build on MacOSX, but the test used for this in setup.py only works up until 10.1.0, from 10.1.1 onwards the release numbering scheme has changed. This patch addresses that. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-27 13:52 Message: Logged In: YES user_id=45365 Checked in as setup.py 1.38.2.3. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-27 13:51 Message: Logged In: YES user_id=45365 Checked in as setup.py 1.38.2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496905&group_id=5470 From noreply@sourceforge.net Thu Dec 27 21:57:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 13:57:17 -0800 Subject: [Patches] [ python-Patches-489388 ] configure.in patch for OSX Message-ID: Patches item #489388, was opened at 2001-12-05 06:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489388&group_id=5470 Category: Macintosh Group: Python 2.1.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: configure.in patch for OSX Initial Comment: Anthony, this patch is a sort-of backport of checkins 1.255 (make Python build on OSX 10.1) and 1.281 (reverse order of test for old OSX and new OSX releases). With this patch Python builds on 10.1 and 10.1.1, and I have pretty good confidence it will also build on 10.0. On 10.1.1 you will get an error because it tries to build curses, this will be fixed on the main branch shortly and I'll flag the patch (to setup.py). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-27 13:57 Message: Logged In: YES user_id=45365 configure.in 1.215.2.7 and the corresponding configure checkin have a different version of this patch that should be equivalent. The curses problem has been addressed in a separate patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-07 04:22 Message: Logged In: YES user_id=45365 It turns out the fix I did for the curses build in the tree trunk is not suitable for 2.1.2 (I've chaned the sys.platform value). I'll submit a 2.1.2-specific patch shortly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=489388&group_id=5470 From noreply@sourceforge.net Thu Dec 27 23:39:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 15:39:28 -0800 Subject: [Patches] [ python-Patches-496796 ] update modulator to use re, gen ansi c Message-ID: Patches item #496796, was opened at 2001-12-26 08:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496796&group_id=5470 Category: Demos and tools Group: Python 2.1.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Jens B. Jorgensen (jensbjorgensen) Assigned to: Jack Jansen (jackjansen) Summary: update modulator to use re, gen ansi c Initial Comment: I found that the modulator utility in the Tools wouldn't work any more, apparently only because it was using regex rather than re. I fixed that and also changed the template files to generate ANSI C function definitions rather than K&R C style. I'm running presently: ActivePython 2.1, build 211 (ActiveState) based on Python 2.1 (#15, Jun 18 2001, 21:42:28) [MSC 32 bit (Intel)] on win32 I don't think the changes should have any problems running with the current version. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-27 15:39 Message: Logged In: YES user_id=45365 Checked in with minor mods: ommitting formal parameters isn't allowed by my C compiler, and there was a typo in one of the other function headers. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496796&group_id=5470 From noreply@sourceforge.net Thu Dec 27 23:43:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 15:43:48 -0800 Subject: [Patches] [ python-Patches-481075 ] Makefile patches for Mac OS X for Python 2.1.2... Message-ID: Patches item #481075, was opened at 2001-11-12 14:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481075&group_id=5470 Category: Macintosh Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Jack Jansen (jackjansen) Summary: Makefile patches for Mac OS X for Python 2.1.2... Initial Comment: I'm not a config god, so I'll leave it to someone else to figure out how configuration needs to be changed to incorporate the following changes for Mac OS X 10.1: 1) Assume: ./configure --with-dyld --with-suffix=.x 2) handle BSD header problems by changing Makefile lines OPT= -g -O3 -Wall -Wstrict-prototypes to OPT= -g -O3 -Wall -Wstrict-prototypes -no- cpp-precomp 3) handle two level name spaces for 10.x and 10.0.x - and use bundle loader option vs flat name spaces. LDSHARED= $(CC) $(LDFLAGS) -bundle - undefined suppress BLDSHARED= $(CC) $(LDFLAGS) -bundle - undefined suppress to LDSHARED= $(CC) $(LDFLAGS) -bundle - undefined error -bundle_loader ./python.x BLDSHARED= $(CC) $(LDFLAGS) -bundle - undefined error -bundle_loader ./python.x NOTE: the '.x' in python.x is the suffix entered in the configure command. Also, I've been told the bundle_loader is only used to resolve undefined symbols and there is no likage between the resulting binary and the bundle_loader. Hence, we can rename python.x to python after installation. with the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-27 15:43 Message: Logged In: YES user_id=45365 The effects of this patch have been attained, albeit by different patches (mainly things I backported from the trunk). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 06:44 Message: Logged In: YES user_id=45365 Purely by accident I came across this patch. I've usurped it. (Dan: assigning a patch to no-one is a pretty sure way of making it go unnoticed, better assign it to a random person, who'll quickly pass it on to someone else:-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481075&group_id=5470 From noreply@sourceforge.net Thu Dec 27 23:45:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 15:45:38 -0800 Subject: [Patches] [ python-Patches-481060 ] dylib & ncurses patches for Mac OS X for Python 2.1.2 Message-ID: Patches item #481060, was opened at 2001-11-12 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 Category: Macintosh Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Jack Jansen (jackjansen) Summary: dylib & ncurses patches for Mac OS X for Python 2.1.2 Initial Comment: The following existing 2.2 CVS patches need to be picked up by Python 2.1.2 for Mac OS X v. 10.1: Support for dylib - allow zlib included in OS to be used rather than have to compile and install in / usr/local: /cvsroot/python/python/dist/src/Lib/distutils/ unixccompiler.py,v retrieving revision 1.35 retrieving revision 1.36 diff -c -r1.35 -r1.36 /cvsroot/python/python/dist/src/Lib/distutils/ ccompiler.py,v retrieving revision 1.39 retrieving revision 1.40 diff -c -r1.39 -r1.40 Prevent ncurses from building on OS X: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.52 retrieving revision 1.53 diff -c -r1.52 -r1.53 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-27 15:45 Message: Logged In: YES user_id=45365 Everything builds correctly now, so I assume these patches work:-) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 22:58 Message: Logged In: YES user_id=29957 Darn. clicked submit too fast. Assigning back to Jack for testing. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 22:57 Message: Logged In: YES user_id=29957 These have now been checked in on the branch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 05:00 Message: Logged In: YES user_id=45365 Anthony (you _are_ doing 2.1.2, or am I gravely mistaken? Assign back to me if I am:-), these patch suggestions look good to me. If you decide to apply them let me know when you've done so and I'll see whether I can build a 2.1.2 on OSX 10.1. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:54 Message: Logged In: YES user_id=45365 Dan, ignore that note about the missing patches. I thought there was one that didn't come from the repository, but on looking again I saw all of them come from the repository, so no need to upload something. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:46 Message: Logged In: YES user_id=45365 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 From noreply@sourceforge.net Fri Dec 28 20:30:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 12:30:38 -0800 Subject: [Patches] [ python-Patches-497420 ] ftplib: ftp anonymous password Message-ID: Patches item #497420, was opened at 2001-12-28 12:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497420&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eduardo Pérez (eperez) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib: ftp anonymous password Initial Comment: I've seen that ftplib sends the user name when doing ANONYMOUS ftp gets. I see a lot of problems: - Sending the user name if the user doesn't know that it's sent doesn't protect the user state of ANONYMOUS - Spyware is not a good idea, most users don't like it. - Sending the user name helps SPAM instead of stopping it. Many ftp sites use this information to send you unsolicited email. - Sending the user name doesn't help ftp sites to know who the cracker is, crackers are not stupid to send their email address. - Sending the user name can be used to discriminate the user. By all of these reasons I argue that ftplib to don't send the user email by default. Some time ago two very important ftp clients wget and lftp stopped sending the user name as password based on my input. As more and more ftp clients are moving to this anonymous@ password (for example the kde kio ftp, qt3, gnome-xml, Net::FTP) I recommend you to apply the patch. I send you the bugfix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497420&group_id=5470 From noreply@sourceforge.net Fri Dec 28 20:55:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 12:55:42 -0800 Subject: [Patches] [ python-Patches-497420 ] ftplib: ftp anonymous password Message-ID: Patches item #497420, was opened at 2001-12-28 12:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497420&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Eduardo Pérez (eperez) >Assigned to: Guido van Rossum (gvanrossum) Summary: ftplib: ftp anonymous password Initial Comment: I've seen that ftplib sends the user name when doing ANONYMOUS ftp gets. I see a lot of problems: - Sending the user name if the user doesn't know that it's sent doesn't protect the user state of ANONYMOUS - Spyware is not a good idea, most users don't like it. - Sending the user name helps SPAM instead of stopping it. Many ftp sites use this information to send you unsolicited email. - Sending the user name doesn't help ftp sites to know who the cracker is, crackers are not stupid to send their email address. - Sending the user name can be used to discriminate the user. By all of these reasons I argue that ftplib to don't send the user email by default. Some time ago two very important ftp clients wget and lftp stopped sending the user name as password based on my input. As more and more ftp clients are moving to this anonymous@ password (for example the kde kio ftp, qt3, gnome-xml, Net::FTP) I recommend you to apply the patch. I send you the bugfix. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 12:55 Message: Logged In: YES user_id=6380 Thanks! You're right. Checked in as ftplib.py 1.63. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497420&group_id=5470 From noreply@sourceforge.net Fri Dec 28 21:43:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 13:43:15 -0800 Subject: [Patches] [ python-Patches-497102 ] building a shared python library Message-ID: Patches item #497102, was opened at 2001-12-27 10:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497102&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: building a shared python library Initial Comment: This patch allows builing of libpython.so in addition to build libpython.a. The patch currently is used for building the python package on Debian GNU/Linux, so it needs to be cleaned up for other architectures. However python already has support for building shared libs, so this should not be a major problem. Feedback for a cleanup of the patch is appreciated. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 13:43 Message: Logged In: YES user_id=21627 The patch looks good (it is the third or so of its kind, but I'm optimistic that it can be integrated this time). Would you like to take another round of cleanup? Specifically: - Building libpython as a shared library MUST be a configuration-time option, this is not negotiable. On many systems, building libpython as a shared library will cause problems, since the directory containing libpython won't be in the standard search path of the dynamic linker (e.g. in /usr/local/lib on Solaris). Adding -R options helps, but not much, since the binaries won't be relocatable with such options. The options should default to "off" (static linking); this is negotiable. - It seems that the patch has a few unrelated changes. What system is GNU* (I assume the Hurd?) Those should come in a separate patch. - Library versioning needs discussion. It seems that this patch will give the library a name of libpython2.2.so.0.0. Under which conditions should the SONAME be changed? If 2.2.1 comes along, how should the SOVERSION change? To 0.1? Or to 1.0? I'd prefer to start with 1.0, anyway - procedures to bump the SOVERSION still need to be discussed (I assume bumping the minor version for Python micro releases should be ok). - If the option for building as a shared library is activated, assume, by default, that the procedure on all systems is identical, i.e. don't try to write Linux-specific code. We can test it on many systems, and on others, users simply can't activate the option. Please put assignments to LDLIBRARY all in one place (there is already a section that does so for dgux/beos/cygwin). - What is the value of building both PIC and non-PIC objects? If libpython is a shared library, I'd suggest to put PIC objects into libpython.a, anyway. That would allow to get rid of the pic_o objects. If some Debian policy says a .a library must not contain PIC objects, I could live with two compilations per source file. - Put the computation of system-dependent options all in configure.in. In particular, passing -soname should be done in configure.in; that should probably be the same on all systems building a shared libpython using GCC. - Please don't use LD_PRELOAD. Using LD_LIBRARY_PATH seems more sensible, IMO. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497102&group_id=5470 From noreply@sourceforge.net Fri Dec 28 21:48:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 13:48:00 -0800 Subject: [Patches] [ python-Patches-497099 ] GNU/Hurd doesn't have large file support Message-ID: Patches item #497099, was opened at 2001-12-27 10:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497099&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: GNU/Hurd doesn't have large file support Initial Comment: [extracted from http://bugs.debian.org/118189, submitted by James A Morrison ] The configure script thinks GNU/Hurd has large file support but it doesn't. Instead the check for Large File support should be checking to see if a program compiles with the symbol _LFS_LARGEFILE. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 13:48 Message: Logged In: YES user_id=21627 Is there a patch associated with this report? The Debian report only has patches for threading, and I can't make sense of the statement "compile with the symbol _LFS_LARGEFILE". What is the actual problem of Python thinking that the Hurd has LFS support? Does something not work? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497099&group_id=5470 From noreply@sourceforge.net Fri Dec 28 21:53:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 13:53:39 -0800 Subject: [Patches] [ python-Patches-497098 ] build support for GNU/Hurd Message-ID: Patches item #497098, was opened at 2001-12-27 10:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: build support for GNU/Hurd Initial Comment: Attached is a patch to build python 2.2 on GNU/Hurd. The patch was originally submitted by James A Morrison to the Debian BTS. If wanted, a patch for 2.1.1 can be provided as well. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 13:53 Message: Logged In: YES user_id=21627 The patch looks fine to me. There is zero chance, though, that it will be incorporated into any 2.1 release, and little chance that it will be incorporated into 2.2 (unless you insist). The patch looks harmless, but it does add a new feature, strictly speaking (support for the Hurd). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:04:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:04:43 -0800 Subject: [Patches] [ python-Patches-494874 ] add tests for int()/long() Message-ID: Patches item #494874, was opened at 2001-12-18 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494874&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: add tests for int()/long() Initial Comment: test invalid params to int() & long (ie, they should raise exceptions) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:04 Message: Logged In: YES user_id=21627 The patch looks fine to me, please apply (to the mainline only, if you think it should go into 2.2.1 as well, assign to group 2.2.1 afterwards). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494874&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:10:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:10:03 -0800 Subject: [Patches] [ python-Patches-494873 ] add tests for complex numbers Message-ID: Patches item #494873, was opened at 2001-12-18 18:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494873&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: add tests for complex numbers Initial Comment: add various tests for complex numbers to improve test coverage ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:10 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. Two comments: - You may want to use test_support.verify and .vereq where appropriate. - Comparing floating-point numbers for equality is a tricky thing. It may be necessary to extend test_support.fcmp to complex numbers, and use that instead. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494873&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:10:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:10:31 -0800 Subject: [Patches] [ python-Patches-494873 ] add tests for complex numbers Message-ID: Patches item #494873, was opened at 2001-12-18 18:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494873&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: add tests for complex numbers Initial Comment: add various tests for complex numbers to improve test coverage ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:10 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. Two comments: - You may want to use test_support.verify and .vereq where appropriate. - Comparing floating-point numbers for equality is a tricky thing. It may be necessary to extend test_support.fcmp to complex numbers, and use that instead. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494873&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:11:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:11:37 -0800 Subject: [Patches] [ python-Patches-494872 ] test repr() of a built-in module Message-ID: Patches item #494872, was opened at 2001-12-18 18:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494872&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: test repr() of a built-in module Initial Comment: repr(sys) just to get test coverage of calling repr() on a built-in module ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:11 Message: Logged In: YES user_id=21627 Patch looks fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494872&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:19:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:19:00 -0800 Subject: [Patches] [ python-Patches-494871 ] test exceptions in various types/methods Message-ID: Patches item #494871, was opened at 2001-12-18 18:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494871&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test exceptions in various types/methods Initial Comment: Add a bunch of tests for various methods, including numeric stuff like: float('') float('5\0') 5.0 / 0.0 5.0 // 0.0 5.0 % 0.0 5 << -5 sequence stuff like: ()[0] x += () [].pop() [].extend(None) {}.values() {}.items() not sure if buffer stuff should go here. if so, need to update X.X.X to be a real number, not sure if there is any correlation of the numbers or should the next available be used (6.7) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:19 Message: Logged In: YES user_id=21627 The numbers are the section numbers of the documentation, of what is now section 2.2 (dunno in what release and document this was section 6). I also don't know how useful it is to keep the numbering, however, if you easily can, please re-organize your tests to fit into the most appropriate sections. Optionally, you a) may want to check that the things you are testing are really mentioned in the section, and b) may want to update the tests to the current section numbers. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494871&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:23:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:23:04 -0800 Subject: [Patches] [ python-Patches-494867 ] updated test_file.py Message-ID: Patches item #494867, was opened at 2001-12-18 18:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494867&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: updated test_file.py Initial Comment: test that file methods raise ValueError when called after the file has been closed also test isatty() ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:23 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494867&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:24:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:24:16 -0800 Subject: [Patches] [ python-Patches-494876 ] test invalid params to pow() Message-ID: Patches item #494876, was opened at 2001-12-18 18:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494876&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: test invalid params to pow() Initial Comment: tests invalid parameter values to pow() to verify exceptions are raised and improve test coverage ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:24 Message: Logged In: YES user_id=21627 The test looks fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494876&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:27:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:27:13 -0800 Subject: [Patches] [ python-Patches-494863 ] file.xreadlines() should raise exception Message-ID: Patches item #494863, was opened at 2001-12-18 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: file.xreadlines() should raise exception Initial Comment: file.xreadlines() should raise a ValueError when the file is closed All other file methods raise ValueError except close() there's another patch that tests this feature and other file methods ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:27 Message: Logged In: YES user_id=21627 I'd say the patch is correct. Notice that this is a change in semantics; please add an entry to Misc/NEWS as well (at the moment, you get back an xreadlines object on which calling .next() will raise a ValueError). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:27:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:27:40 -0800 Subject: [Patches] [ python-Patches-494863 ] file.xreadlines() should raise exception Message-ID: Patches item #494863, was opened at 2001-12-18 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: file.xreadlines() should raise exception Initial Comment: file.xreadlines() should raise a ValueError when the file is closed All other file methods raise ValueError except close() there's another patch that tests this feature and other file methods ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:27 Message: Logged In: YES user_id=21627 I'd say the patch is correct. Notice that this is a change in semantics; please add an entry to Misc/NEWS as well (at the moment, you get back an xreadlines object on which calling .next() will raise a ValueError). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:40:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:40:16 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:40 Message: Logged In: YES user_id=21627 The patch looks fine to me. I wonder whether Python should stop using these constant names, though, and replace them with, say, a PyCmp_ prefix, throughout. If there is a backwards compatibility concern (which I wouldn't expect), it should be possible to add #defines to the old names when there is no conflict. Would you be willing to rewrite this patch to do so? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-19 08:05 Message: Logged In: YES user_id=6380 Standard cautionary note. Sorry. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-19 07:39 Message: Logged In: YES user_id=4631 I used the win CVS "update" command on the entire source tree yesterday. I have not specified a particular tag. Are you saying that opcode.h rev 2.37 is not current, or is "please use the current cvs" a standard cautionary note? Sorry to be anal, I want this to be seamless for you so I feel I have botched it up already. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 19:20 Message: Logged In: YES user_id=6380 That looks like a fine context diff to me. Please be sure to use the current CVS if you can! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:47:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:47:53 -0800 Subject: [Patches] [ python-Patches-450265 ] OS/2 + EMX port - PC directory files Message-ID: Patches item #450265, was opened at 2001-08-12 04:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: OS/2 + EMX port - PC directory files Initial Comment: The attached patch contains all the changes to the PC directory in the source tree between Python 2.1.1 and the 010812 release of the OS/2+EMX port. This comprises changes to PC/getpathp.c and a new subdirectory, PC/os2emx, which contains the Makefile, config.[ch], dlfcn.[ch], dllentry.c, python DLL .DEF file and a copy of the port's README.os2emx. At the moment, building dynamic modules is still handled by the supplied Makefile, rather than a DistUtils setup.py script. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:47 Message: Logged In: YES user_id=21627 Andrew, are you still interested in updating this patch? Otherwise, I recommend to reject it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-01 15:41 Message: Logged In: YES user_id=21627 What kind of action would you like to see on this code? In the areas where it changes existing code, there are some questionable chunks, which I would not like to see in Python: - removal of comments - change of control logic without giving a rationale. E.g. there was an explicit comment /* If we have no values, we dont need a ';' */ Your patch changes this to give a ; in all cases. Why? Why is the addition of a terminating null in wprogpath removed? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-12 07:45 Message: Logged In: YES user_id=6380 Andrew, your patch attachment didn't work. Please try again, making sure you check the "file upload checkbox". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470 From noreply@sourceforge.net Fri Dec 28 23:21:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 15:21:47 -0800 Subject: [Patches] [ python-Patches-494863 ] file.xreadlines() should raise exception Message-ID: Patches item #494863, was opened at 2001-12-18 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: file.xreadlines() should raise exception Initial Comment: file.xreadlines() should raise a ValueError when the file is closed All other file methods raise ValueError except close() there's another patch that tests this feature and other file methods ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-28 15:21 Message: Logged In: YES user_id=33168 Martin, did you mean to close this or assign it to me? Should this be a 2.2.1 candidate? I don't think it's too important, other than that it will change behaviour, although for an obscure condition. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:27 Message: Logged In: YES user_id=21627 I'd say the patch is correct. Notice that this is a change in semantics; please add an entry to Misc/NEWS as well (at the moment, you get back an xreadlines object on which calling .next() will raise a ValueError). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470 From noreply@sourceforge.net Fri Dec 28 23:27:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 15:27:26 -0800 Subject: [Patches] [ python-Patches-494871 ] test exceptions in various types/methods Message-ID: Patches item #494871, was opened at 2001-12-18 18:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494871&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test exceptions in various types/methods Initial Comment: Add a bunch of tests for various methods, including numeric stuff like: float('') float('5\0') 5.0 / 0.0 5.0 // 0.0 5.0 % 0.0 5 << -5 sequence stuff like: ()[0] x += () [].pop() [].extend(None) {}.values() {}.items() not sure if buffer stuff should go here. if so, need to update X.X.X to be a real number, not sure if there is any correlation of the numbers or should the next available be used (6.7) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-28 15:27 Message: Logged In: YES user_id=33168 I didn't see buffers mentioned in section 2.2 at all. The buffer() function is mentioned in 2.1. Perhaps the buffer tests should be moved into a test of their own? There appear to be very few uses of buffer throughout the tests. Also, I saw in test_StringIO.py that jython doesn't have buffers, so the whole test should be skipped/pass for jython it seems (see lines 79-80). Other than the buffer change in the patch, the other tests should be in the appropriate location. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:19 Message: Logged In: YES user_id=21627 The numbers are the section numbers of the documentation, of what is now section 2.2 (dunno in what release and document this was section 6). I also don't know how useful it is to keep the numbering, however, if you easily can, please re-organize your tests to fit into the most appropriate sections. Optionally, you a) may want to check that the things you are testing are really mentioned in the section, and b) may want to update the tests to the current section numbers. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494871&group_id=5470 From noreply@sourceforge.net Fri Dec 28 23:42:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 15:42:45 -0800 Subject: [Patches] [ python-Patches-494863 ] file.xreadlines() should raise exception Message-ID: Patches item #494863, was opened at 2001-12-18 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: file.xreadlines() should raise exception Initial Comment: file.xreadlines() should raise a ValueError when the file is closed All other file methods raise ValueError except close() there's another patch that tests this feature and other file methods ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 15:42 Message: Logged In: YES user_id=21627 Oops, I meant to assign it to you for check-in, not to close it. I don't think it is a 2.2.1 candidate, since there is no serious bug involved. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-28 15:21 Message: Logged In: YES user_id=33168 Martin, did you mean to close this or assign it to me? Should this be a 2.2.1 candidate? I don't think it's too important, other than that it will change behaviour, although for an obscure condition. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:27 Message: Logged In: YES user_id=21627 I'd say the patch is correct. Notice that this is a change in semantics; please add an entry to Misc/NEWS as well (at the moment, you get back an xreadlines object on which calling .next() will raise a ValueError). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470 From noreply@sourceforge.net Sat Dec 29 00:20:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 16:20:49 -0800 Subject: [Patches] [ python-Patches-494876 ] test invalid params to pow() Message-ID: Patches item #494876, was opened at 2001-12-18 18:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494876&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: test invalid params to pow() Initial Comment: tests invalid parameter values to pow() to verify exceptions are raised and improve test coverage ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-28 16:20 Message: Logged In: YES user_id=33168 Checked in as 1.30 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:24 Message: Logged In: YES user_id=21627 The test looks fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494876&group_id=5470 From noreply@sourceforge.net Sat Dec 29 00:25:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 16:25:56 -0800 Subject: [Patches] [ python-Patches-494872 ] test repr() of a built-in module Message-ID: Patches item #494872, was opened at 2001-12-18 18:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494872&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: test repr() of a built-in module Initial Comment: repr(sys) just to get test coverage of calling repr() on a built-in module ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-28 16:25 Message: Logged In: YES user_id=33168 Checked in as 1.11 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:11 Message: Logged In: YES user_id=21627 Patch looks fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494872&group_id=5470 From noreply@sourceforge.net Sat Dec 29 00:35:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 16:35:30 -0800 Subject: [Patches] [ python-Patches-494874 ] add tests for int()/long() Message-ID: Patches item #494874, was opened at 2001-12-18 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494874&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add tests for int()/long() Initial Comment: test invalid params to int() & long (ie, they should raise exceptions) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-28 16:35 Message: Logged In: YES user_id=33168 Checked in as 1.43 I don't think it needs to go into 2.2.1. This just improves test coverage. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:04 Message: Logged In: YES user_id=21627 The patch looks fine to me, please apply (to the mainline only, if you think it should go into 2.2.1 as well, assign to group 2.2.1 afterwards). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494874&group_id=5470 From noreply@sourceforge.net Sat Dec 29 01:02:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 17:02:35 -0800 Subject: [Patches] [ python-Patches-494873 ] add tests for complex numbers Message-ID: Patches item #494873, was opened at 2001-12-18 18:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494873&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add tests for complex numbers Initial Comment: add various tests for complex numbers to improve test coverage ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-28 17:02 Message: Logged In: YES user_id=33168 I checked in the parts that don't require comparison of complex numbers. Checked in as 1.6 I will open a new patch to address the comparison of complex numbers. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:10 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. Two comments: - You may want to use test_support.verify and .vereq where appropriate. - Comparing floating-point numbers for equality is a tricky thing. It may be necessary to extend test_support.fcmp to complex numbers, and use that instead. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494873&group_id=5470 From noreply@sourceforge.net Sat Dec 29 01:09:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 17:09:36 -0800 Subject: [Patches] [ python-Patches-497487 ] support comparison of complex #s in fcmp Message-ID: Patches item #497487, was opened at 2001-12-28 17:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497487&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: support comparison of complex #s in fcmp Initial Comment: >From #494872, there was a suggestion to use test_support.fcmp() to compare complex numbers. This patch adds a comparison test for complex numbers to test_complex and the support to compare complex numbers in test_support.fcmp(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497487&group_id=5470 From noreply@sourceforge.net Sat Dec 29 02:25:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 18:25:33 -0800 Subject: [Patches] [ python-Patches-497487 ] support comparison of complex #s in fcmp Message-ID: Patches item #497487, was opened at 2001-12-28 17:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497487&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: support comparison of complex #s in fcmp Initial Comment: >From #494872, there was a suggestion to use test_support.fcmp() to compare complex numbers. This patch adds a comparison test for complex numbers to test_complex and the support to compare complex numbers in test_support.fcmp(). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-28 18:25 Message: Logged In: YES user_id=31435 test_complex.py already contains check_close() for fuzzy comparison of complex numbers. The algorithm fcmp() uses isn't good enough for the comparison needs test_complex already has (I tried using it before, and it caused bogus test failures on Pentium + gcc under Linux -- long story, which I'll skip here). So just use check_close, and skip the test_support part of this patch (people reading the general-purpose test_support shouldn't have to worry about the vagaries of complex numbers). Or skip fuzzy comparison altogether! You have an exact result here, and it would be fine to just do test_support.vereq(complex(5.3, 9.8).conjugate(), 5.3-9.8j) The folklore about never comparing floats for equality is nonsense (although good advice in most cases ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497487&group_id=5470 From noreply@sourceforge.net Sat Dec 29 14:35:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 06:35:16 -0800 Subject: [Patches] [ python-Patches-497487 ] support comparison of complex #s in fcmp Message-ID: Patches item #497487, was opened at 2001-12-28 17:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497487&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: support comparison of complex #s in fcmp Initial Comment: >From #494872, there was a suggestion to use test_support.fcmp() to compare complex numbers. This patch adds a comparison test for complex numbers to test_complex and the support to compare complex numbers in test_support.fcmp(). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-29 06:35 Message: Logged In: YES user_id=33168 Checked in as 1.7 to test_complex. I did what Tim suggested and did a vereq(). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-28 18:25 Message: Logged In: YES user_id=31435 test_complex.py already contains check_close() for fuzzy comparison of complex numbers. The algorithm fcmp() uses isn't good enough for the comparison needs test_complex already has (I tried using it before, and it caused bogus test failures on Pentium + gcc under Linux -- long story, which I'll skip here). So just use check_close, and skip the test_support part of this patch (people reading the general-purpose test_support shouldn't have to worry about the vagaries of complex numbers). Or skip fuzzy comparison altogether! You have an exact result here, and it would be fine to just do test_support.vereq(complex(5.3, 9.8).conjugate(), 5.3-9.8j) The folklore about never comparing floats for equality is nonsense (although good advice in most cases ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497487&group_id=5470 From noreply@sourceforge.net Sat Dec 29 18:14:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 10:14:37 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-29 10:14 Message: Logged In: YES user_id=4631 Yes, I will change the enum and all uses of it that I can find to use a unique prefix as you suggested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:40 Message: Logged In: YES user_id=21627 The patch looks fine to me. I wonder whether Python should stop using these constant names, though, and replace them with, say, a PyCmp_ prefix, throughout. If there is a backwards compatibility concern (which I wouldn't expect), it should be possible to add #defines to the old names when there is no conflict. Would you be willing to rewrite this patch to do so? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-19 08:05 Message: Logged In: YES user_id=6380 Standard cautionary note. Sorry. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-19 07:39 Message: Logged In: YES user_id=4631 I used the win CVS "update" command on the entire source tree yesterday. I have not specified a particular tag. Are you saying that opcode.h rev 2.37 is not current, or is "please use the current cvs" a standard cautionary note? Sorry to be anal, I want this to be seamless for you so I feel I have botched it up already. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 19:20 Message: Logged In: YES user_id=6380 That looks like a fine context diff to me. Please be sure to use the current CVS if you can! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Sat Dec 29 20:10:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 12:10:30 -0800 Subject: [Patches] [ python-Patches-497098 ] build support for GNU/Hurd Message-ID: Patches item #497098, was opened at 2001-12-27 10:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: build support for GNU/Hurd Initial Comment: Attached is a patch to build python 2.2 on GNU/Hurd. The patch was originally submitted by James A Morrison to the Debian BTS. If wanted, a patch for 2.1.1 can be provided as well. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2001-12-29 12:10 Message: Logged In: YES user_id=60903 I don't insist. However looking at other projects like gcc, ports to other platforms are considered for inclusion in maintainance releases. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 13:53 Message: Logged In: YES user_id=21627 The patch looks fine to me. There is zero chance, though, that it will be incorporated into any 2.1 release, and little chance that it will be incorporated into 2.2 (unless you insist). The patch looks harmless, but it does add a new feature, strictly speaking (support for the Hurd). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 From noreply@sourceforge.net Sat Dec 29 20:30:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 12:30:40 -0800 Subject: [Patches] [ python-Patches-497098 ] build support for GNU/Hurd Message-ID: Patches item #497098, was opened at 2001-12-27 10:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: build support for GNU/Hurd Initial Comment: Attached is a patch to build python 2.2 on GNU/Hurd. The patch was originally submitted by James A Morrison to the Debian BTS. If wanted, a patch for 2.1.1 can be provided as well. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2001-12-29 12:30 Message: Logged In: YES user_id=60903 I don't insist. However looking at other projects like gcc, ports to other platforms are considered for inclusion in maintainance releases. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2001-12-29 12:10 Message: Logged In: YES user_id=60903 I don't insist. However looking at other projects like gcc, ports to other platforms are considered for inclusion in maintainance releases. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 13:53 Message: Logged In: YES user_id=21627 The patch looks fine to me. There is zero chance, though, that it will be incorporated into any 2.1 release, and little chance that it will be incorporated into 2.2 (unless you insist). The patch looks harmless, but it does add a new feature, strictly speaking (support for the Hurd). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 From noreply@sourceforge.net Sun Dec 30 01:20:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 17:20:08 -0800 Subject: [Patches] [ python-Patches-497736 ] smtplib.py SMTP EHLO/HELO correct Message-ID: Patches item #497736, was opened at 2001-12-29 17:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497736&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eduardo Pérez (eperez) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.py SMTP EHLO/HELO correct Initial Comment: If the machine from you are sending mail doesn't have a FQDN and the mail server requires a FQDN in HELO the current code will fail. Resolving the name it's a very bad idea: - It's something from other layer (DNS/IP) not from SMTP - It breaks when the name of the computer is not FQDN (as many dial-ins do) and the SMTP server does strict EHLO/HELO checking as stated before. - It breaks computers with a TCP tunnel to another host from the connection is originated if the relay does strict EHLO/HELO checking. - It breaks computers using NAT, the host that sees the server is not the one that sends the message if the relay does strict EHLO/HELO checking. - It's considered spyware as you are sending information some companies or people don't want to say: the internal structure of the network. No important mail client resolves the name. Look at netscape messenger or kmail. In fact kmail and perl's Net::SMTP does exactly what my patch does. Please don't resolve the names, as this approach works and the most used email clients do this. I send you the bugfix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497736&group_id=5470 From noreply@sourceforge.net Sun Dec 30 02:24:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 18:24:25 -0800 Subject: [Patches] [ python-Patches-497736 ] smtplib.py SMTP EHLO/HELO correct Message-ID: Patches item #497736, was opened at 2001-12-29 17:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497736&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eduardo Pérez (eperez) >Assigned to: Barry Warsaw (bwarsaw) Summary: smtplib.py SMTP EHLO/HELO correct Initial Comment: If the machine from you are sending mail doesn't have a FQDN and the mail server requires a FQDN in HELO the current code will fail. Resolving the name it's a very bad idea: - It's something from other layer (DNS/IP) not from SMTP - It breaks when the name of the computer is not FQDN (as many dial-ins do) and the SMTP server does strict EHLO/HELO checking as stated before. - It breaks computers with a TCP tunnel to another host from the connection is originated if the relay does strict EHLO/HELO checking. - It breaks computers using NAT, the host that sees the server is not the one that sends the message if the relay does strict EHLO/HELO checking. - It's considered spyware as you are sending information some companies or people don't want to say: the internal structure of the network. No important mail client resolves the name. Look at netscape messenger or kmail. In fact kmail and perl's Net::SMTP does exactly what my patch does. Please don't resolve the names, as this approach works and the most used email clients do this. I send you the bugfix. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 18:24 Message: Logged In: YES user_id=6380 Seems reasonable to me, but I lack the SMTP knowledge to understand all the issues. Assigned to Barry Warsaw for review. (Barry: Eduardo found a similar privacy violation in ftplib, which I fixed. You might also ask Thomas Wouters for a review of the underlying idea.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497736&group_id=5470 From noreply@sourceforge.net Sun Dec 30 03:01:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 19:01:11 -0800 Subject: [Patches] [ python-Patches-497098 ] build support for GNU/Hurd Message-ID: Patches item #497098, was opened at 2001-12-27 10:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: build support for GNU/Hurd Initial Comment: Attached is a patch to build python 2.2 on GNU/Hurd. The patch was originally submitted by James A Morrison to the Debian BTS. If wanted, a patch for 2.1.1 can be provided as well. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-29 19:01 Message: Logged In: YES user_id=31435 Python doesn't have "maintenance" releases, it has "bugfix" releases. They're solely to fix bugs. Because Unixish config is such a friggin' mess, there's a long history of putatively harmless tweaks for new platforms breaking the build on established obscure platforms. So Martin was just giving the Party Line here . We'll be delighted to incorporate GNU/Hurd support for 2.3, though. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2001-12-29 12:30 Message: Logged In: YES user_id=60903 I don't insist. However looking at other projects like gcc, ports to other platforms are considered for inclusion in maintainance releases. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2001-12-29 12:10 Message: Logged In: YES user_id=60903 I don't insist. However looking at other projects like gcc, ports to other platforms are considered for inclusion in maintainance releases. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 13:53 Message: Logged In: YES user_id=21627 The patch looks fine to me. There is zero chance, though, that it will be incorporated into any 2.1 release, and little chance that it will be incorporated into 2.2 (unless you insist). The patch looks harmless, but it does add a new feature, strictly speaking (support for the Hurd). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 From noreply@sourceforge.net Sun Dec 30 13:04:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 05:04:47 -0800 Subject: [Patches] [ python-Patches-497098 ] build support for GNU/Hurd Message-ID: Patches item #497098, was opened at 2001-12-27 10:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Martin v. Löwis (loewis) Summary: build support for GNU/Hurd Initial Comment: Attached is a patch to build python 2.2 on GNU/Hurd. The patch was originally submitted by James A Morrison to the Debian BTS. If wanted, a patch for 2.1.1 can be provided as well. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 19:01 Message: Logged In: YES user_id=31435 Python doesn't have "maintenance" releases, it has "bugfix" releases. They're solely to fix bugs. Because Unixish config is such a friggin' mess, there's a long history of putatively harmless tweaks for new platforms breaking the build on established obscure platforms. So Martin was just giving the Party Line here . We'll be delighted to incorporate GNU/Hurd support for 2.3, though. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2001-12-29 12:30 Message: Logged In: YES user_id=60903 I don't insist. However looking at other projects like gcc, ports to other platforms are considered for inclusion in maintainance releases. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2001-12-29 12:10 Message: Logged In: YES user_id=60903 I don't insist. However looking at other projects like gcc, ports to other platforms are considered for inclusion in maintainance releases. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 13:53 Message: Logged In: YES user_id=21627 The patch looks fine to me. There is zero chance, though, that it will be incorporated into any 2.1 release, and little chance that it will be incorporated into 2.2 (unless you insist). The patch looks harmless, but it does add a new feature, strictly speaking (support for the Hurd). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470 From noreply@sourceforge.net Sun Dec 30 13:13:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 05:13:47 -0800 Subject: [Patches] [ python-Patches-462754 ] no '_d' ending for mingw32 Message-ID: Patches item #462754, was opened at 2001-09-18 20:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: no '_d' ending for mingw32 Initial Comment: This patch prevents distutils from naming the extension modules _d.pyd when compiled with mingw32 on Windows in debug mode. Instead, the extension modules will get the normal name .pyd. Technically, the patch doesn't prevent the behaviour for mingw32, but only adds the _d for MS Visual C++ and Borland compilers (though I don't know about the Borland case). The reason for this? Adding "_d" doesn't make any sense for GNU compilers. I think it's just a MS Visual C++ madness. If you want to debug an extension module that was compiled with gcc, you have to use gdb anyway, because the debugging symbols of MSVC++ and gcc are incompatible. So you normally use a release Python version (from the python.org binary download) and compile your extensions with mingw32. To put it shortly: The current state is that you do a "setup.py build --compiler=mingw32 --debug" and then rename the extension modules, removing the _d. Then fire up gdb to debug your module. With this patch, the renaming isn't necessary anymore. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-30 05:13 Message: Logged In: YES user_id=21627 How does the mingw port interact with the debugging libraries? With MSVC, the debug build will link to the debug versions of the CRT. What C library will mingw link with (I hope it won't use crtdll.dll)? ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2001-09-28 14:28 Message: Logged In: YES user_id=163326 Yes. But mingw32 isn't emulating Unix under Windows (that would be Cygwin). It's just a version of gcc and friends that targets native win32. It links against msvcrt (not a Posix emulation library like Cygwin does). This is a bit hypothetical because I didn't yet hack the autoconf build process for native win32 with mingw32. Currently, you cannot build a complete Python with mingw32, but you *can* build extension modules against an existing Python (compiled with M$ VC++). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-28 13:43 Message: Logged In: YES user_id=31435 All else being equal, a system emulating Unix under Windows should strive to make life comfortable for Unix folks. The question is thus whether all else is in fact equal . ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2001-09-28 11:37 Message: Logged In: YES user_id=163326 Hmm. I don't like the _d endings at all. But if the policy on win32 is that debug executables and libraries get a "_d" ending, then I'm unsure wether this patch should be applied. I have plans to hack the autoconf madness to build a native win32 Python with mingw32. But that won't be ready by tomorror. And I don't think that I'll add "_d" endings there for debugging, because that would be inconsistent with the normal autoconf builds on Unix. I'm glad that *I* don't have to decide wether this patch is a Good Thing. Being consistent with Python win32 build or with GNU (gcc/autoconf). Take your pick :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-18 20:46 Message: Logged In: YES user_id=31435 FYI, MSVC never adds _d on its own -- Mark Hammond and/or Guido forced it to do that. I don't remember why, but one of them explained it to me long ago and it made good sense at the time . MSCV normally compiles debug and release builds into distinct subdirectories, and uses the same names in both. But *our* MSVC setup forces it to compile both flavors of build directly into the PCbuild directory, so has to give the resulting DLLs and executables different names (else the second build would overwrite the results of the first build). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470 From noreply@sourceforge.net Sun Dec 30 16:51:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 08:51:01 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- >Comment By: Brad Clements (bkc) Date: 2001-12-30 08:51 Message: Logged In: YES user_id=4631 I have made the suggested changes to the enum, and the necessary changes to compile.c and ceval.c Should I append those three diffs to this patch entry, or create a new entry, one for each of those diffs? compile.c has some other unrelated changes, and some of those changes are dependent on diffs to another include. IE, rather than #ifdef'ing all references to errno, I know that NetWare doesn't have errno either. So I've created macros GetErrno(), ClearErrno() and SetErrno(). Hope that's going to work out. Also, lots of modules have statements like : goto finally; which Metrowerks and EVT don't like because "finally" is a reserved word, even when compiling .c modules. So I've had to change all of those as well. When I get regrtests all working, and recompile my code on Win32 and Linux, then I'll post all my diffs. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-29 10:14 Message: Logged In: YES user_id=4631 Yes, I will change the enum and all uses of it that I can find to use a unique prefix as you suggested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:40 Message: Logged In: YES user_id=21627 The patch looks fine to me. I wonder whether Python should stop using these constant names, though, and replace them with, say, a PyCmp_ prefix, throughout. If there is a backwards compatibility concern (which I wouldn't expect), it should be possible to add #defines to the old names when there is no conflict. Would you be willing to rewrite this patch to do so? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-19 08:05 Message: Logged In: YES user_id=6380 Standard cautionary note. Sorry. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-19 07:39 Message: Logged In: YES user_id=4631 I used the win CVS "update" command on the entire source tree yesterday. I have not specified a particular tag. Are you saying that opcode.h rev 2.37 is not current, or is "please use the current cvs" a standard cautionary note? Sorry to be anal, I want this to be seamless for you so I feel I have botched it up already. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 19:20 Message: Logged In: YES user_id=6380 That looks like a fine context diff to me. Please be sure to use the current CVS if you can! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Sun Dec 30 16:51:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 08:51:19 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- >Comment By: Brad Clements (bkc) Date: 2001-12-30 08:51 Message: Logged In: YES user_id=4631 I have made the suggested changes to the enum, and the necessary changes to compile.c and ceval.c Should I append those three diffs to this patch entry, or create a new entry, one for each of those diffs? compile.c has some other unrelated changes, and some of those changes are dependent on diffs to another include. IE, rather than #ifdef'ing all references to errno, I know that NetWare doesn't have errno either. So I've created macros GetErrno(), ClearErrno() and SetErrno(). Hope that's going to work out. Also, lots of modules have statements like : goto finally; which Metrowerks and EVT don't like because "finally" is a reserved word, even when compiling .c modules. So I've had to change all of those as well. When I get regrtests all working, and recompile my code on Win32 and Linux, then I'll post all my diffs. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-30 08:51 Message: Logged In: YES user_id=4631 I have made the suggested changes to the enum, and the necessary changes to compile.c and ceval.c Should I append those three diffs to this patch entry, or create a new entry, one for each of those diffs? compile.c has some other unrelated changes, and some of those changes are dependent on diffs to another include. IE, rather than #ifdef'ing all references to errno, I know that NetWare doesn't have errno either. So I've created macros GetErrno(), ClearErrno() and SetErrno(). Hope that's going to work out. Also, lots of modules have statements like : goto finally; which Metrowerks and EVT don't like because "finally" is a reserved word, even when compiling .c modules. So I've had to change all of those as well. When I get regrtests all working, and recompile my code on Win32 and Linux, then I'll post all my diffs. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-29 10:14 Message: Logged In: YES user_id=4631 Yes, I will change the enum and all uses of it that I can find to use a unique prefix as you suggested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:40 Message: Logged In: YES user_id=21627 The patch looks fine to me. I wonder whether Python should stop using these constant names, though, and replace them with, say, a PyCmp_ prefix, throughout. If there is a backwards compatibility concern (which I wouldn't expect), it should be possible to add #defines to the old names when there is no conflict. Would you be willing to rewrite this patch to do so? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-19 08:05 Message: Logged In: YES user_id=6380 Standard cautionary note. Sorry. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-19 07:39 Message: Logged In: YES user_id=4631 I used the win CVS "update" command on the entire source tree yesterday. I have not specified a particular tag. Are you saying that opcode.h rev 2.37 is not current, or is "please use the current cvs" a standard cautionary note? Sorry to be anal, I want this to be seamless for you so I feel I have botched it up already. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 19:20 Message: Logged In: YES user_id=6380 That looks like a fine context diff to me. Please be sure to use the current CVS if you can! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Sun Dec 30 22:46:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 14:46:20 -0800 Subject: [Patches] [ python-Patches-497951 ] Typo in rfc822 library docs. Message-ID: Patches item #497951, was opened at 2001-12-30 14:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497951&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Typo in rfc822 library docs. Initial Comment: There's a typo in the rfc822: >timestamp. It the timezone item in the tuple is \code{None}, assume "It" should be "If"? Anyway, here's a patch against the latest CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497951&group_id=5470 From noreply@sourceforge.net Mon Dec 31 00:16:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 16:16:48 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-30 16:16 Message: Logged In: YES user_id=21627 Attaching the opcode changes to this report is fine, also including any other renaming problems into the same patch is fine. I'd appreciate if you could separate any errno patches you may have, since I'd expect some discussion on these, which shouldn't stop integration of the renamings. To do this, you could try to edit the universal or context diffs (whatever you are more familiar with) by hand. Notice that this works only as long as you are deleting entire hunks; don't try to modify a hunk (this will normally mess up the line numbers). If overlapping changes are in a single hunk, you may include them in the patch as well - I'll have to unedit them out, then (by applying the patch to a clean copy, and manually taking out the unrelated changes). You may wonder about the insistence on separate patches, but it is really a prerequisite for understanding the rationale of a change in the coming years. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-30 08:51 Message: Logged In: YES user_id=4631 I have made the suggested changes to the enum, and the necessary changes to compile.c and ceval.c Should I append those three diffs to this patch entry, or create a new entry, one for each of those diffs? compile.c has some other unrelated changes, and some of those changes are dependent on diffs to another include. IE, rather than #ifdef'ing all references to errno, I know that NetWare doesn't have errno either. So I've created macros GetErrno(), ClearErrno() and SetErrno(). Hope that's going to work out. Also, lots of modules have statements like : goto finally; which Metrowerks and EVT don't like because "finally" is a reserved word, even when compiling .c modules. So I've had to change all of those as well. When I get regrtests all working, and recompile my code on Win32 and Linux, then I'll post all my diffs. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-30 08:51 Message: Logged In: YES user_id=4631 I have made the suggested changes to the enum, and the necessary changes to compile.c and ceval.c Should I append those three diffs to this patch entry, or create a new entry, one for each of those diffs? compile.c has some other unrelated changes, and some of those changes are dependent on diffs to another include. IE, rather than #ifdef'ing all references to errno, I know that NetWare doesn't have errno either. So I've created macros GetErrno(), ClearErrno() and SetErrno(). Hope that's going to work out. Also, lots of modules have statements like : goto finally; which Metrowerks and EVT don't like because "finally" is a reserved word, even when compiling .c modules. So I've had to change all of those as well. When I get regrtests all working, and recompile my code on Win32 and Linux, then I'll post all my diffs. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-29 10:14 Message: Logged In: YES user_id=4631 Yes, I will change the enum and all uses of it that I can find to use a unique prefix as you suggested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:40 Message: Logged In: YES user_id=21627 The patch looks fine to me. I wonder whether Python should stop using these constant names, though, and replace them with, say, a PyCmp_ prefix, throughout. If there is a backwards compatibility concern (which I wouldn't expect), it should be possible to add #defines to the old names when there is no conflict. Would you be willing to rewrite this patch to do so? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-19 08:05 Message: Logged In: YES user_id=6380 Standard cautionary note. Sorry. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-19 07:39 Message: Logged In: YES user_id=4631 I used the win CVS "update" command on the entire source tree yesterday. I have not specified a particular tag. Are you saying that opcode.h rev 2.37 is not current, or is "please use the current cvs" a standard cautionary note? Sorry to be anal, I want this to be seamless for you so I feel I have botched it up already. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 19:20 Message: Logged In: YES user_id=6380 That looks like a fine context diff to me. Please be sure to use the current CVS if you can! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Mon Dec 31 14:32:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 06:32:46 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- >Comment By: Brad Clements (bkc) Date: 2001-12-31 06:32 Message: Logged In: YES user_id=4631 Here are three updated diff's for ceval.c, compile.c and opcode.h I have removed the errno-macro components of the diff. When I go to submit the errno-diffs, will I need to remove the diffs that are included here? (lots of editing!) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-30 16:16 Message: Logged In: YES user_id=21627 Attaching the opcode changes to this report is fine, also including any other renaming problems into the same patch is fine. I'd appreciate if you could separate any errno patches you may have, since I'd expect some discussion on these, which shouldn't stop integration of the renamings. To do this, you could try to edit the universal or context diffs (whatever you are more familiar with) by hand. Notice that this works only as long as you are deleting entire hunks; don't try to modify a hunk (this will normally mess up the line numbers). If overlapping changes are in a single hunk, you may include them in the patch as well - I'll have to unedit them out, then (by applying the patch to a clean copy, and manually taking out the unrelated changes). You may wonder about the insistence on separate patches, but it is really a prerequisite for understanding the rationale of a change in the coming years. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-30 08:51 Message: Logged In: YES user_id=4631 I have made the suggested changes to the enum, and the necessary changes to compile.c and ceval.c Should I append those three diffs to this patch entry, or create a new entry, one for each of those diffs? compile.c has some other unrelated changes, and some of those changes are dependent on diffs to another include. IE, rather than #ifdef'ing all references to errno, I know that NetWare doesn't have errno either. So I've created macros GetErrno(), ClearErrno() and SetErrno(). Hope that's going to work out. Also, lots of modules have statements like : goto finally; which Metrowerks and EVT don't like because "finally" is a reserved word, even when compiling .c modules. So I've had to change all of those as well. When I get regrtests all working, and recompile my code on Win32 and Linux, then I'll post all my diffs. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-30 08:51 Message: Logged In: YES user_id=4631 I have made the suggested changes to the enum, and the necessary changes to compile.c and ceval.c Should I append those three diffs to this patch entry, or create a new entry, one for each of those diffs? compile.c has some other unrelated changes, and some of those changes are dependent on diffs to another include. IE, rather than #ifdef'ing all references to errno, I know that NetWare doesn't have errno either. So I've created macros GetErrno(), ClearErrno() and SetErrno(). Hope that's going to work out. Also, lots of modules have statements like : goto finally; which Metrowerks and EVT don't like because "finally" is a reserved word, even when compiling .c modules. So I've had to change all of those as well. When I get regrtests all working, and recompile my code on Win32 and Linux, then I'll post all my diffs. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-29 10:14 Message: Logged In: YES user_id=4631 Yes, I will change the enum and all uses of it that I can find to use a unique prefix as you suggested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:40 Message: Logged In: YES user_id=21627 The patch looks fine to me. I wonder whether Python should stop using these constant names, though, and replace them with, say, a PyCmp_ prefix, throughout. If there is a backwards compatibility concern (which I wouldn't expect), it should be possible to add #defines to the old names when there is no conflict. Would you be willing to rewrite this patch to do so? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-19 08:05 Message: Logged In: YES user_id=6380 Standard cautionary note. Sorry. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-19 07:39 Message: Logged In: YES user_id=4631 I used the win CVS "update" command on the entire source tree yesterday. I have not specified a particular tag. Are you saying that opcode.h rev 2.37 is not current, or is "please use the current cvs" a standard cautionary note? Sorry to be anal, I want this to be seamless for you so I feel I have botched it up already. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 19:20 Message: Logged In: YES user_id=6380 That looks like a fine context diff to me. Please be sure to use the current CVS if you can! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Mon Dec 31 14:36:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 06:36:11 -0800 Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h Message-ID: Patches item #494783, was opened at 2001-12-18 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: diffs for Windows CE - Include/Opcode.h Initial Comment: Attached is a diff for Include/opcode.h to allow compilation on MS Wince using EVT 3.0 I have quite a lot of little diffs like this that I would like to submit, but before generating and posting all of them, I'm sending in just this one to be sure I've done this correctly. My original edits were made against 2.2 alpha 1, so I am re-updating my local src tree and redoing all the diffs. I also will have some diffs for Novell NetWare in the future. I realize you may not be able to apply these diffs anytime soon, but could you let me know if this meets your format requirements soon so I can continue to submit diffs. Thanks ---------------------------------------------------------------------- >Comment By: Brad Clements (bkc) Date: 2001-12-31 06:36 Message: Logged In: YES user_id=4631 The opcode.diff file with the description "Include/Opcode.h context diff for Wince" should be deleted. I don't have rights to delete it. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-31 06:32 Message: Logged In: YES user_id=4631 Here are three updated diff's for ceval.c, compile.c and opcode.h I have removed the errno-macro components of the diff. When I go to submit the errno-diffs, will I need to remove the diffs that are included here? (lots of editing!) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-30 16:16 Message: Logged In: YES user_id=21627 Attaching the opcode changes to this report is fine, also including any other renaming problems into the same patch is fine. I'd appreciate if you could separate any errno patches you may have, since I'd expect some discussion on these, which shouldn't stop integration of the renamings. To do this, you could try to edit the universal or context diffs (whatever you are more familiar with) by hand. Notice that this works only as long as you are deleting entire hunks; don't try to modify a hunk (this will normally mess up the line numbers). If overlapping changes are in a single hunk, you may include them in the patch as well - I'll have to unedit them out, then (by applying the patch to a clean copy, and manually taking out the unrelated changes). You may wonder about the insistence on separate patches, but it is really a prerequisite for understanding the rationale of a change in the coming years. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-30 08:51 Message: Logged In: YES user_id=4631 I have made the suggested changes to the enum, and the necessary changes to compile.c and ceval.c Should I append those three diffs to this patch entry, or create a new entry, one for each of those diffs? compile.c has some other unrelated changes, and some of those changes are dependent on diffs to another include. IE, rather than #ifdef'ing all references to errno, I know that NetWare doesn't have errno either. So I've created macros GetErrno(), ClearErrno() and SetErrno(). Hope that's going to work out. Also, lots of modules have statements like : goto finally; which Metrowerks and EVT don't like because "finally" is a reserved word, even when compiling .c modules. So I've had to change all of those as well. When I get regrtests all working, and recompile my code on Win32 and Linux, then I'll post all my diffs. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-30 08:51 Message: Logged In: YES user_id=4631 I have made the suggested changes to the enum, and the necessary changes to compile.c and ceval.c Should I append those three diffs to this patch entry, or create a new entry, one for each of those diffs? compile.c has some other unrelated changes, and some of those changes are dependent on diffs to another include. IE, rather than #ifdef'ing all references to errno, I know that NetWare doesn't have errno either. So I've created macros GetErrno(), ClearErrno() and SetErrno(). Hope that's going to work out. Also, lots of modules have statements like : goto finally; which Metrowerks and EVT don't like because "finally" is a reserved word, even when compiling .c modules. So I've had to change all of those as well. When I get regrtests all working, and recompile my code on Win32 and Linux, then I'll post all my diffs. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-29 10:14 Message: Logged In: YES user_id=4631 Yes, I will change the enum and all uses of it that I can find to use a unique prefix as you suggested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 14:40 Message: Logged In: YES user_id=21627 The patch looks fine to me. I wonder whether Python should stop using these constant names, though, and replace them with, say, a PyCmp_ prefix, throughout. If there is a backwards compatibility concern (which I wouldn't expect), it should be possible to add #defines to the old names when there is no conflict. Would you be willing to rewrite this patch to do so? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-19 08:05 Message: Logged In: YES user_id=6380 Standard cautionary note. Sorry. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2001-12-19 07:39 Message: Logged In: YES user_id=4631 I used the win CVS "update" command on the entire source tree yesterday. I have not specified a particular tag. Are you saying that opcode.h rev 2.37 is not current, or is "please use the current cvs" a standard cautionary note? Sorry to be anal, I want this to be seamless for you so I feel I have botched it up already. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 19:20 Message: Logged In: YES user_id=6380 That looks like a fine context diff to me. Please be sure to use the current CVS if you can! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470 From noreply@sourceforge.net Mon Dec 31 16:38:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 08:38:14 -0800 Subject: [Patches] [ python-Patches-498109 ] fileobject truncate support for win32 Message-ID: Patches item #498109, was opened at 2001-12-31 08:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498109&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Strobl (strobl) Assigned to: Nobody/Anonymous (nobody) Summary: fileobject truncate support for win32 Initial Comment: python 2.2 has large file support on Windows, but f.truncate() throws an overflow exception when f.tell() >2G. I've changed file_truncate in fileobject.c to using SetEndOfFile iff truncate is called without a parameter, on Win32. Tested on W2k (Ger), see the diff to test_largfile.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498109&group_id=5470 From noreply@sourceforge.net Mon Dec 31 16:42:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 08:42:51 -0800 Subject: [Patches] [ python-Patches-498109 ] fileobject truncate support for win32 Message-ID: Patches item #498109, was opened at 2001-12-31 08:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498109&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Strobl (strobl) >Assigned to: Tim Peters (tim_one) Summary: fileobject truncate support for win32 Initial Comment: python 2.2 has large file support on Windows, but f.truncate() throws an overflow exception when f.tell() >2G. I've changed file_truncate in fileobject.c to using SetEndOfFile iff truncate is called without a parameter, on Win32. Tested on W2k (Ger), see the diff to test_largfile.py. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-31 08:42 Message: Logged In: YES user_id=6380 For Tim. I presume the chunk of the diff that removes the leading comment of the file is a mistake? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498109&group_id=5470 From noreply@sourceforge.net Mon Dec 31 19:13:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 11:13:40 -0800 Subject: [Patches] [ python-Patches-498149 ] httplib.py screws up on 100 response Message-ID: Patches item #498149, was opened at 2001-12-31 11:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498149&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jens B. Jorgensen (jensbjorgensen) Assigned to: Nobody/Anonymous (nobody) Summary: httplib.py screws up on 100 response Initial Comment: Bug 227361 details a problem where httplib.py behaves poorly when a server returns an HTTP 100 response code. This is pretty annoying since Microsoft IIS ASP pages are notorious for first returning a 100 code and then returning the "real" response. What is worse, httplib.py sets the self.__state to a value which prevents you from trying to get the next response so you can get the value. Once you get the 100 response code your object is stuck and you have no way of getting the response. I needed to solve this problem and did so. I found that a bug had been logged and that the assignee (and maintainer?) indicated a preference for a solution where the HTTPResponse object would transparently consume the 100 responses in the begin() method. My simple change adopts this philosophy and does just that. It will loop, consuming 100 responses until a non-100 response is return. For the curious, yes, servers can be observed returning more than one 100 response. All header information returned in the 100 responses is overwritten and lost. I don't think this will be much of a concern for anyone. I also concur that transparently consuming the 100 responses is the most appropriate thing to do. It's clean, doesn't seem to have any obvious gothchas (haven't thought about how it could affect proxies or the like) and will prevent everyone from having to, say, write their own loops to chew through the 100 responses on their own. I've really only added 4 lines even though the patch is bigger. I just did one quick test with the change to the CVS version since that's not the version that I'm using but the changes are really slight so I'm not too worried. And finally, I'm using: TALLAN2$ python ActivePython 2.1, build 211 (ActiveState) based on Python 2.1 (#15, Jun 18 2001, 21:42:28) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498149&group_id=5470 From noreply@sourceforge.net Mon Dec 31 19:14:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 11:14:54 -0800 Subject: [Patches] [ python-Patches-498149 ] httplib.py screws up on 100 response Message-ID: Patches item #498149, was opened at 2001-12-31 11:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498149&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jens B. Jorgensen (jensbjorgensen) >Assigned to: Greg Stein (gstein) Summary: httplib.py screws up on 100 response Initial Comment: Bug 227361 details a problem where httplib.py behaves poorly when a server returns an HTTP 100 response code. This is pretty annoying since Microsoft IIS ASP pages are notorious for first returning a 100 code and then returning the "real" response. What is worse, httplib.py sets the self.__state to a value which prevents you from trying to get the next response so you can get the value. Once you get the 100 response code your object is stuck and you have no way of getting the response. I needed to solve this problem and did so. I found that a bug had been logged and that the assignee (and maintainer?) indicated a preference for a solution where the HTTPResponse object would transparently consume the 100 responses in the begin() method. My simple change adopts this philosophy and does just that. It will loop, consuming 100 responses until a non-100 response is return. For the curious, yes, servers can be observed returning more than one 100 response. All header information returned in the 100 responses is overwritten and lost. I don't think this will be much of a concern for anyone. I also concur that transparently consuming the 100 responses is the most appropriate thing to do. It's clean, doesn't seem to have any obvious gothchas (haven't thought about how it could affect proxies or the like) and will prevent everyone from having to, say, write their own loops to chew through the 100 responses on their own. I've really only added 4 lines even though the patch is bigger. I just did one quick test with the change to the CVS version since that's not the version that I'm using but the changes are really slight so I'm not too worried. And finally, I'm using: TALLAN2$ python ActivePython 2.1, build 211 (ActiveState) based on Python 2.1 (#15, Jun 18 2001, 21:42:28) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498149&group_id=5470 From noreply@sourceforge.net Mon Dec 31 19:56:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 11:56:10 -0800 Subject: [Patches] [ python-Patches-498109 ] fileobject truncate support for win32 Message-ID: Patches item #498109, was opened at 2001-12-31 08:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498109&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Strobl (strobl) Assigned to: Tim Peters (tim_one) Summary: fileobject truncate support for win32 Initial Comment: python 2.2 has large file support on Windows, but f.truncate() throws an overflow exception when f.tell() >2G. I've changed file_truncate in fileobject.c to using SetEndOfFile iff truncate is called without a parameter, on Win32. Tested on W2k (Ger), see the diff to test_largfile.py. ---------------------------------------------------------------------- >Comment By: Wolfgang Strobl (strobl) Date: 2001-12-31 11:56 Message: Logged In: YES user_id=311771 Oops. While removing some obsolete personal notes, I accidentally removed the leading comment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-31 08:42 Message: Logged In: YES user_id=6380 For Tim. I presume the chunk of the diff that removes the leading comment of the file is a mistake? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498109&group_id=5470