From noreply@sourceforge.net Sat Jun 1 06:22:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 31 May 2002 22:22:36 -0700 Subject: [Patches] [ python-Patches-563203 ] Replace 'has_key' with 'in' Message-ID: Patches item #563203, was opened at 2002-06-01 00:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=563203&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: Replace 'has_key' with 'in' Initial Comment: The attached patch updates the library to use 'key in dict' rather than the older, slower, less readable has_key() form. Passes regression tests. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=563203&group_id=5470 From noreply@sourceforge.net Sat Jun 1 14:13:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Jun 2002 06:13:06 -0700 Subject: [Patches] [ python-Patches-563203 ] Replace 'has_key' with 'in' Message-ID: Patches item #563203, was opened at 2002-06-01 01:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=563203&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Replace 'has_key' with 'in' Initial Comment: The attached patch updates the library to use 'key in dict' rather than the older, slower, less readable has_key() form. Passes regression tests. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-01 09:13 Message: Logged In: YES user_id=6380 I have no time to review this. I suggest that you jst go for it, but ask yourself one question for each change: are you sure it's always a dict? Some other mappings don't support 'in' yet (e.g. the *dbm databases). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=563203&group_id=5470 From noreply@sourceforge.net Sat Jun 1 14:46:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Jun 2002 06:46:57 -0700 Subject: [Patches] [ python-Patches-474274 ] Pure Python strptime() (PEP 42) Message-ID: Patches item #474274, was opened at 2001-10-23 19:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Pure Python strptime() (PEP 42) Initial Comment: The attached file contains a pure Python version of strptime(). It attempts to operate as much like time.strptime() within reason. Where vagueness or obvious platform dependence existed, I tried to standardize and be reasonable. PEP 42 makes a request for a portable, consistent version of time.strptime(): - Add a portable implementation of time.strptime() that works in clearly defined ways on all platforms. This module attempts to close that feature request. The code has been tested thoroughly by myself as well as some other people who happened to have caught the post I made to c.l.p a while back and used the module. It is available at the Python Cookbook (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/56036). It has been approved by the editors there and thus is listed as approved. It is also being considered for inclusion in the book (thanks, Alex, for encouraging this submission). A PyUnit testing suite for the module is available at http://www.ocf.berkeley.edu/~bac/Askewed_Thoughts/HTML/code/index.php3#strptime along with the code for the function itself. Localization has been handled in a modular way using regexes. All of it is self-explanatory in the doc strings. It is very straight-forward to include your own localization settings or modify the two languages included in the module (English and Swedish). If the code needs to have its license changed, I am quite happy to do it (I have already given the OK to the Python Cookbook). -Brett Cannon ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-01 09:46 Message: Logged In: YES user_id=33168 Overall, the patch looks pretty good. I didn't check for completeness or consistency, though. * You don't need: from exceptions import Exception * The comment "from strptime import * will only export strptime()" is not correct. * I'm not sure what should be included for the license. * Why do you need success flag in CheckIntegrity, you raise an exception? (You don't need to return anything, raise an exception, else it's ok) * In return_time(), could you change xrange(9) to range(len(temp_time)) this removes a dependancy. * strings are sequences, so instead of if found in ('y', 'Y') you can do if found in 'yY' * daylight should use the new bools True, False (this also applies to any other flags) * The formatting doesn't follow the standard (see PEP 8) (specifically, spaces after commas, =, binary ops, comparisons, etc) * Long lines should be broken up The test looks pretty good too. I didn't check it for completeness. The URL is wrong (too high up), the test can be found here: http://www.ocf.berkeley.edu/~bac/Askewed_Thoughts/code/Python/Scripts/test_strptime.py I noticed a spelling mistake in the test: anme -> name. Also, note that PEP 42 has a comment about a python strptime. So if this gets implemented, we need to update PEP 42. Thanks. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-05-27 17:38 Message: Logged In: YES user_id=357491 Version 2 of strptime() has now been uploaded. This nearly complete rewrite includes the removal of the need to input locale-specific time info. All need locale info is gleaned from time.strftime(). This makes it able to behave exactly like time.strptime(). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-24 18:15 Message: Logged In: YES user_id=35752 Go ahead and reuse this item. I'll wait for the updated version. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-03-24 18:01 Message: Logged In: YES user_id=357491 Oops. I thought I had removed the clause. Feel free to remove it. I am going to be cleaning up the module, though, so if you would rather not bother reviewing this version and wait on the cleaned-up one, go ahead. Speaking of which, should I just reply to this bugfix when I get around to the update, or start a new patch? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-23 17:41 Message: Logged In: YES user_id=35752 I'm pretty sure this code needs a different license before it can be accepted. The current license contains the "BSD advertising clause". See http://www.gnu.org/philosophy/bsd.html. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 From noreply@sourceforge.net Sat Jun 1 15:25:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Jun 2002 07:25:22 -0700 Subject: [Patches] [ python-Patches-563203 ] Replace 'has_key' with 'in' Message-ID: Patches item #563203, was opened at 2002-06-01 00:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=563203&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Replace 'has_key' with 'in' Initial Comment: The attached patch updates the library to use 'key in dict' rather than the older, slower, less readable has_key() form. Passes regression tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-06-01 09:25 Message: Logged In: YES user_id=80475 Done. In case where has_key() was defined in the class, added __contains__ to match so that the interface would be complete. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-01 08:13 Message: Logged In: YES user_id=6380 I have no time to review this. I suggest that you jst go for it, but ask yourself one question for each change: are you sure it's always a dict? Some other mappings don't support 'in' yet (e.g. the *dbm databases). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=563203&group_id=5470 From noreply@sourceforge.net Sat Jun 1 15:42:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Jun 2002 07:42:30 -0700 Subject: [Patches] [ python-Patches-561478 ] webchecker chokes at charsets. Message-ID: Patches item #561478, was opened at 2002-05-28 13:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561478&group_id=5470 Category: Demos and tools Group: Python 2.2.x Status: Open Resolution: None Priority: 3 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: webchecker chokes at charsets. Initial Comment: This little patch allowes webchecker.py to handle Content-Type headers like 'text/html; charset=iso-8859-1'. -- Maximillian Dornseif ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-06-01 16:42 Message: Logged In: YES user_id=89016 But this means that "text/htmlfoo" will be checked too. Maybe you should use cgi.parse_header() for parsing the Content-Type header? ---------------------------------------------------------------------- Comment By: Maximillian Dornseif (mdornseif) Date: 2002-05-30 22:22 Message: Logged In: YES user_id=554460 I *had* checked "Upload & Attach File". Using this sourceforge software gives me headaces everywhere - perhaps because i use a non-mainstream browser (iCab)? Nevertheless, the Patch is available at: http://c0re.jp/c0de/misc/Python-2.2.1-webchecker-mime-charset.patch diff -ur Python-2.2.1/Tools/webchecker/webchecker.py Python-2.2.1-md/Tools/webchecker/webchecker.py --- Python-2.2.1/Tools/webchecker/webchecker.py Mon Mar 11 11:04:07 2002 +++ Python-2.2.1-md/Tools/webchecker/webchecker.py Tue May 28 12:54:00 2002 @@ -548,7 +548,7 @@ if url[-1:] == "/": return 1 ctype, encoding = mimetypes.guess_type(url) - if ctype == 'text/html': + if ctype and ctype.startswith('text/html'): return 1 else: self.note(1, " Not HTML, mime type %s", ctype) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-05-30 16:22 Message: Logged In: YES user_id=89016 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=561478&group_id=5470 From noreply@sourceforge.net Sun Jun 2 08:44:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 00:44:05 -0700 Subject: [Patches] [ python-Patches-474274 ] Pure Python strptime() (PEP 42) Message-ID: Patches item #474274, was opened at 2001-10-23 16:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Pure Python strptime() (PEP 42) Initial Comment: The attached file contains a pure Python version of strptime(). It attempts to operate as much like time.strptime() within reason. Where vagueness or obvious platform dependence existed, I tried to standardize and be reasonable. PEP 42 makes a request for a portable, consistent version of time.strptime(): - Add a portable implementation of time.strptime() that works in clearly defined ways on all platforms. This module attempts to close that feature request. The code has been tested thoroughly by myself as well as some other people who happened to have caught the post I made to c.l.p a while back and used the module. It is available at the Python Cookbook (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/56036). It has been approved by the editors there and thus is listed as approved. It is also being considered for inclusion in the book (thanks, Alex, for encouraging this submission). A PyUnit testing suite for the module is available at http://www.ocf.berkeley.edu/~bac/Askewed_Thoughts/HTML/code/index.php3#strptime along with the code for the function itself. Localization has been handled in a modular way using regexes. All of it is self-explanatory in the doc strings. It is very straight-forward to include your own localization settings or modify the two languages included in the module (English and Swedish). If the code needs to have its license changed, I am quite happy to do it (I have already given the OK to the Python Cookbook). -Brett Cannon ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2002-06-02 00:44 Message: Logged In: YES user_id=357491 I'm afraid you looked at the wrong patch! My fault since I accidentally forgot to add a description for my patch. So the file with no description is the newest one and completely supercedes the older file. I am very sorry about that. Trust me, the new version is much better. I realized the other day that since the time module is a C extension file, would getting this accepted require getting BDFL approval to add this as a separate module into the standard library? Would the time module have to have a Python interface module where this is put and all other methods in the module just pass directly to the extension file? As for the suggestions, here are my replies to the ones that still apply to the new file: * strings are sequences, so instead of if found in ('y', 'Y') you can do if found in 'yY' -> True, but I personally find it easier to read using the tuple. If it is standard practice in the standard library to do it the suggested way, I will change it. * daylight should use the new bools True, False (this also applies to any other flags) -> Oops. Since I wrote this under Python 2.2.1 I didn't think about it. I will go through the code and look for places where True and False should be used. -Brett C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-01 06:46 Message: Logged In: YES user_id=33168 Overall, the patch looks pretty good. I didn't check for completeness or consistency, though. * You don't need: from exceptions import Exception * The comment "from strptime import * will only export strptime()" is not correct. * I'm not sure what should be included for the license. * Why do you need success flag in CheckIntegrity, you raise an exception? (You don't need to return anything, raise an exception, else it's ok) * In return_time(), could you change xrange(9) to range(len(temp_time)) this removes a dependancy. * strings are sequences, so instead of if found in ('y', 'Y') you can do if found in 'yY' * daylight should use the new bools True, False (this also applies to any other flags) * The formatting doesn't follow the standard (see PEP 8) (specifically, spaces after commas, =, binary ops, comparisons, etc) * Long lines should be broken up The test looks pretty good too. I didn't check it for completeness. The URL is wrong (too high up), the test can be found here: http://www.ocf.berkeley.edu/~bac/Askewed_Thoughts/code/Python/Scripts/test_strptime.py I noticed a spelling mistake in the test: anme -> name. Also, note that PEP 42 has a comment about a python strptime. So if this gets implemented, we need to update PEP 42. Thanks. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-05-27 14:38 Message: Logged In: YES user_id=357491 Version 2 of strptime() has now been uploaded. This nearly complete rewrite includes the removal of the need to input locale-specific time info. All need locale info is gleaned from time.strftime(). This makes it able to behave exactly like time.strptime(). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-24 15:15 Message: Logged In: YES user_id=35752 Go ahead and reuse this item. I'll wait for the updated version. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-03-24 15:01 Message: Logged In: YES user_id=357491 Oops. I thought I had removed the clause. Feel free to remove it. I am going to be cleaning up the module, though, so if you would rather not bother reviewing this version and wait on the cleaned-up one, go ahead. Speaking of which, should I just reply to this bugfix when I get around to the update, or start a new patch? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-23 14:41 Message: Logged In: YES user_id=35752 I'm pretty sure this code needs a different license before it can be accepted. The current license contains the "BSD advertising clause". See http://www.gnu.org/philosophy/bsd.html. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 From noreply@sourceforge.net Sun Jun 2 13:14:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 05:14:01 -0700 Subject: [Patches] [ python-Patches-488073 ] AtheOS port of Python 2.2b2 Message-ID: Patches item #488073, was opened at 2001-12-02 14:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Octavian Cerna (tavyc) Assigned to: Martin v. Löwis (loewis) 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: 2002-06-02 14:14 Message: Logged In: YES user_id=21627 On AF_UNIX: I can see how SocketServer.py will define UnixStreamServer if AF_UNIX is available, however, I cannot see why this causes a problem unless somebody uses the UnixStreamServer. The documentation is, strictly speaking, still correct even if AF_UNIX was defined, since it only talks about the case that it isn't defined. The same holds for AF_INET6 on many systems: The C library may define it, but the kernel may be configured to not support IPv6. On statvfs, I recommend to fix the test rather than hiding the function. On fseeko: I recommend to activate LFS; perhaps the documentation should be changed to indicate that this is known to be broken on AtheOS 0.3.6. If you think any of these restrictions *must* be implemented, please implement an autoconf test to detect the restrictions automatically, rather than testing them based on the system name. Otherwise, I can carry out the proposed changes myself (removal of the restrictions); please indicate which approach you prefer. ---------------------------------------------------------------------- Comment By: Octavian Cerna (tavyc) Date: 2002-05-15 13:54 Message: Logged In: YES user_id=382173 - AF_UNIX is undefined because Doc/lib/libsocket.tex says: "If the AF_UNIX constant is not defined then this protocol is unsupported." Defining AF_UNIX breaks Lib/SocketServer.py as it doesn't handle EAFNOSUPPORT. - for statvfs I assumed the same convetion, see Lib/test/test_os.py (method StatAttributeTests.test_statvfs_attributes). - the problem is not with autoconf, but in glibc: gnu/stubs.h fails to define __stub_ macros for all unimplemented functions (statvfs for example). - fseeko/ftello don't work at all for large files. Small example: fp = fopen("2.1GB_file", "r"); /*filesize=2307915776LL*/ fseeko(fp, 0LL, 2); /* seeks to eof, returns -1, errno=0 */ ftello(fp); /* returns -1987051520LL, which is (int32)2307915776LL */ This is a sign truncation problem somewhere in libio. The lowlevel functions lseek, stat, etc are all OK: os.stat("2.1GB_file").st_size = 2307915776L So I preferred to disable largefile support for file objects. Perl which also uses stdio has the same problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-12 18:40 Message: Logged In: YES user_id=21627 A few more questions: - Why is AF_UNIX undefined? I.e. what problems would arise if it was exported from the socket module? - Likewise, what problems arise if statvfs is exported from the Posix module? Sure, calling the function might always give an exception, but what is the problem with that? - Also, are you sure this is still an issue with the current autoconf? configure specifically checks for the __stub_ symbols defined in glibc for stub functions. - What problems arise if large file support is enabled? Does seek/tell not work at all, or does it just fail for large files? ---------------------------------------------------------------------- Comment By: Octavian Cerna (tavyc) Date: 2002-05-05 20:23 Message: Logged In: YES user_id=382173 Updated to CVS 2002-05-04. I disabled from setup.py the modules which don't make sense on AtheOS (nis for example). I still used the historic sys.platform[:n] in a few places in order to be consistent with the surrounding code. This time I was more careful with the code, and made more testing. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-20 19:12 Message: Logged In: YES user_id=21627 Can you please update the patch for the current CVS? A few comments: - the plat-*/FCNTL are not generated anymore, FCNTL is deprecated. - Why does test_nis need to skip explicitly on atheos? If the nis module builds, why does the test fail? - Please use the .startswith method over the (historic) [:n] form when testing sys.platform. - I don't understand the O_LARGEFILE chunk. What is the problem with just not defining O_LARGEFILE? ---------------------------------------------------------------------- Comment By: Octavian Cerna (tavyc) Date: 2001-12-02 19: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 16: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 Jun 2 13:23:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 05:23:06 -0700 Subject: [Patches] [ python-Patches-555929 ] Cygwin AH_BOTTOM cleanup patch Message-ID: Patches item #555929, was opened at 2002-05-14 15:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin AH_BOTTOM cleanup patch Initial Comment: This patch complies with the following request found near the top of configure.in: # This is for stuff that absolutely must end up in pyconfig.h. # Please use pyport.h instead, if possible. I tested this patch under Cygwin, Win32, and Red Hat Linux. Python built and ran successfully on each of these platforms. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 14:23 Message: Logged In: YES user_id=21627 The patch is fine now (tested on Linux and Windows/MSVC), please apply it. There is a convention on assigning patches: the patch should always be assigned to whoever needs to act on it next. So after uploading the revised patch, you should have assigned it back to me - that has the effect of the patch showing up in sf.net/my. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 18:27 Message: Logged In: YES user_id=86216 Any status Martin? Or, is it one strike and you're out? :,) Did you get a chance to try the latest patch under your Linux environment? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-16 14:26 Message: Logged In: YES user_id=86216 > Can you please explain why moving pyport.h is necessary? It's not. It seemed cleaner, albeit riskier. Attached is the second version of my patch. It's identical to the first version except for the Include/Python.h hunk. The changes to Include/Python.h leave the #include "pyport.h" in its original location. Instead, I moved the DL_IMPORT stuff to after the #include "pyport.h". I tested under Cygwin, Win32, and Linux (i.e., gcc 2.96) again without any problems. Please test under your Linux environment. If successful, should we have others test on other platforms to prevent a repeat of this "fiasco?" ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 12:28 Message: Logged In: YES user_id=21627 Can you please explain why moving pyport.h is necessary? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-15 21:24 Message: Logged In: YES user_id=86216 > How did you test this patch? I tested under Red Linux 7.1 configured with "--enable-shared". Note that my version of gcc is different than yours: $ gcc --version 2.96 > which come from pyport.h being included before limits.h. I was concerned about moving where pyport.h is included. I should have made this concern explicit. > Backing the patch out; No problem -- sorry for the trouble. > try again. Should I leave the #include "pyport.h" in its original location and move the DL_IMPORT stuff after it? Or, should I just try moving #include "pyport.h" to right after the #include ? Since I can't reproduce the problem, I'm afraid that my next attempt may cause problems too. Would you be willing to retry my first patch and just move the #include "pyport.h" below the #include ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 20:25 Message: Logged In: YES user_id=21627 How did you test this patch? When I build Python on Linux, I get tons of error messages In file included from /usr/include/limits.h:152, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:117, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:11, from Include/Python.h:28, from Python/frozenmain.c:4: /usr/include/bits/xopen_lim.h:123: warning: `LONG_BIT' redefined which come from pyport.h being included before limits.h. Backing the patch out; try again. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-15 13:55 Message: Logged In: YES user_id=86216 Committed as: configure 1.306 configure.in 1.316 pyconfig.h.in 1.34 Include/Python.h 2.47 Include/pyport.h 2.48 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 00:03 Message: Logged In: YES user_id=21627 Sounds good; please install this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 From noreply@sourceforge.net Sun Jun 2 13:33:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 05:33:39 -0700 Subject: [Patches] [ python-Patches-552060 ] Fix breakage of smtplib.starttls() Message-ID: Patches item #552060, was opened at 2002-05-03 23:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552060&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Martin v. Löwis (loewis) Summary: Fix breakage of smtplib.starttls() Initial Comment: The introduction of socket.sendall in smtplib broke the STARTTLS support. This patch fixes the problem. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 14:33 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as smtplib.py 1.46.4.3 and 1.57. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552060&group_id=5470 From noreply@sourceforge.net Sun Jun 2 13:44:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 05:44:37 -0700 Subject: [Patches] [ python-Patches-558547 ] SocketServer: don't flush closed wfile Message-ID: Patches item #558547, was opened at 2002-05-21 08:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558547&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer: don't flush closed wfile Initial Comment: I've found the following patch (well, ok, subclassed, but the patch is the same) makes SocketServer more robust. If wfile is already closed (prior to the finish() method being called), don't try to flush() it. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 14:44 Message: Logged In: YES user_id=21627 Can you explain how this problem can ever occur? I.e. why would there be two calls to finish? Also, is there a guarantee that every thing returned by makefile has a .closed attribute? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-21 08:25 Message: Logged In: YES user_id=29957 mm. i typ reel gud sometimes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558547&group_id=5470 From noreply@sourceforge.net Sun Jun 2 13:45:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 05:45:30 -0700 Subject: [Patches] [ python-Patches-558544 ] cmd.py: add instance-specific stdin/out Message-ID: Patches item #558544, was opened at 2002-05-21 07:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558544&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: cmd.py: add instance-specific stdin/out Initial Comment: The following patch adds stdin, stdout as optional arguments to the cmd.Cmd constructor (defaulting to sys.stdin, sys.stdout), and changes the Cmd methods throughout to use self.stdout.write() and self.stdin.foo for output and input. This allows much greater flexibility for using cmd - for instance, hooking it into a telnet server. And if the response is YAGNI, well, actually, IAGNI, because it's in use today (and for the last year). :) If this is acceptable, I'll provide a documentation patch as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 14:45 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=558544&group_id=5470 From noreply@sourceforge.net Sun Jun 2 13:53:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 05:53:22 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 17:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 14:53 Message: Logged In: YES user_id=21627 Sorry, no - I had not downloaded the doc patch (and thought of that on my way home). This is all fine now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-27 17:11 Message: Logged In: YES user_id=6656 OK, this is checked in as: configure.in 1.318 configure 1.308 pyconfig.h.in 1.36 Modules/signalmodule.c 2.67 Lib/test/test_signal.py 1.10 Doc/whatnew/whatsnew23.tex 1.15 Misc/NEWS 1.410 Doc/lib/libsignal.tex 1.24 Not sure what you meant about copying docstrings into libsignal.tex -- did you not see my doc diff? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-27 16:24 Message: Logged In: YES user_id=21627 The patch looks good; please apply it. It would be good if you copy the doc strings into libsignal.tex. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 16:17 Message: Logged In: YES user_id=6656 And here are the docs. I've even done a section for whatsnew! The table looks a bit wierd in the html, but I don't think it warrants concern. I think I'm done now. Assigning to Martin for review, but anyone with access to unices other than linux/x86 is encouraged to test! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 16:15 Message: Logged In: YES user_id=6656 I think I'm done now. The patch I'm attaching (a) does all the stuff my last patch did. (b) uses the presence of sigprocmask to assume that all the other posix-y stuff is there. I don't know if this is safe, but I don't know what would be. (c) adds tests (d) adds a Misc/NEWS segment. The patch I'll attach in a minute has the docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 15:56 Message: Logged In: YES user_id=6656 Hmm, I don't think I'm going to bother with sigaction. Most of the options just don't make sense given when Python signal handlers get run. So, docs and autoconf hackery (spit) to go... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 15:49 Message: Logged In: YES user_id=6656 Try this instead. Definitely a good call on the interface front. Still same caveats. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 11:52 Message: Logged In: YES user_id=6656 Hmm, fair point. I just got carried away :) Patch later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 19:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Sun Jun 2 13:53:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 05:53:22 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 17:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 14:53 Message: Logged In: YES user_id=21627 Sorry, no - I had not downloaded the doc patch (and thought of that on my way home). This is all fine now. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 14:53 Message: Logged In: YES user_id=21627 Sorry, no - I had not downloaded the doc patch (and thought of that on my way home). This is all fine now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-27 17:11 Message: Logged In: YES user_id=6656 OK, this is checked in as: configure.in 1.318 configure 1.308 pyconfig.h.in 1.36 Modules/signalmodule.c 2.67 Lib/test/test_signal.py 1.10 Doc/whatnew/whatsnew23.tex 1.15 Misc/NEWS 1.410 Doc/lib/libsignal.tex 1.24 Not sure what you meant about copying docstrings into libsignal.tex -- did you not see my doc diff? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-27 16:24 Message: Logged In: YES user_id=21627 The patch looks good; please apply it. It would be good if you copy the doc strings into libsignal.tex. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 16:17 Message: Logged In: YES user_id=6656 And here are the docs. I've even done a section for whatsnew! The table looks a bit wierd in the html, but I don't think it warrants concern. I think I'm done now. Assigning to Martin for review, but anyone with access to unices other than linux/x86 is encouraged to test! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 16:15 Message: Logged In: YES user_id=6656 I think I'm done now. The patch I'm attaching (a) does all the stuff my last patch did. (b) uses the presence of sigprocmask to assume that all the other posix-y stuff is there. I don't know if this is safe, but I don't know what would be. (c) adds tests (d) adds a Misc/NEWS segment. The patch I'll attach in a minute has the docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 15:56 Message: Logged In: YES user_id=6656 Hmm, I don't think I'm going to bother with sigaction. Most of the options just don't make sense given when Python signal handlers get run. So, docs and autoconf hackery (spit) to go... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 15:49 Message: Logged In: YES user_id=6656 Try this instead. Definitely a good call on the interface front. Still same caveats. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 11:52 Message: Logged In: YES user_id=6656 Hmm, fair point. I just got carried away :) Patch later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 19:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Sun Jun 2 18:44:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 10:44:21 -0700 Subject: [Patches] [ python-Patches-550765 ] SocketServer behavior Message-ID: Patches item #550765, was opened at 2002-04-30 22:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550765&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Gilfix (mgilfix) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer behavior Initial Comment: A bug, or lack of behavior in ServerSocket.py was exposed while created a unit test for Python 2.3. As of 2.3, signals between threads propagate differently. When cancelling a server that implemented threading with a keyboard interrupt, the server would shut down but not terminate (waiting on client threads). The fit for this was to make the client threads daemon-threads with the setDaemon call. Because this was non-apparent, this patch adds a member variable which acts as a hook and makes it clear that clients need to either set or unset the variable when deriving the class to control this behavior. setDaemon is off by default, as this is thought to be the consensus behavior. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 19:44 Message: Logged In: YES user_id=21627 Could you please provide changes to the documentation as well (i.e. Doc/lib/libsocksvr.tex, and Misc/NEWS)? There is a typo: 'chanegs' -> 'changes' There is no need to attach the modified source to the patch; the context diff is enough. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550765&group_id=5470 From noreply@sourceforge.net Sun Jun 2 18:45:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 10:45:40 -0700 Subject: [Patches] [ python-Patches-551911 ] test_commands.py using . incorrectly Message-ID: Patches item #551911, was opened at 2002-05-03 18:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551911&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) >Assigned to: Martin v. Löwis (loewis) Summary: test_commands.py using . incorrectly Initial Comment: test_commands.py was revised recently to look at the root directory (/.) rather than the file (/bin/ls). A regular expression comparison against /bin/ls was also changed to refer to "/.". But that means "/" followed by anything, not "/" followed by "." It should have been changed to "/\.", as per this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551911&group_id=5470 From noreply@sourceforge.net Sun Jun 2 18:53:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 10:53:45 -0700 Subject: [Patches] [ python-Patches-551960 ] Add check for setrlimit() support Message-ID: Patches item #551960, was opened at 2002-05-03 20:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Add check for setrlimit() support Initial Comment: The new test_resource test calls resource.setrlimit() to change the file size limits. This fails on Cygwin, which supports setrlimit() and getrlimit(), just not changing that particular setting. (The same would apply to any other platforms that has those functions but not that particular feature.) Since that getrlimit() works, and setrlimit() can be used for other reasons, a check for sys.platform was added to that part of the test. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 19:53 Message: Logged In: YES user_id=21627 I'm not sure I understand the logic in the modified setrlimit(FSIZE) case. If setting the limit fails, it seems that the entire test should be skipped. Raising TestSkipped might be appropriate, to indicate that the result of the test is not trustworthy. ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-06 15:11 Message: Logged In: YES user_id=329402 Cygwin Python raises ValueError when you call setrlimit() for RLIMIT_FSIZE. That limit is hardcoded at infinity and cannot be changed. I have submitted an alternative patch that looks for ValueError rather than checking sys.platform. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:44 Message: Logged In: YES user_id=21627 Don't check for systems, check for features instead. In this specific case, what error does Cygwin report? Could that be used to deal with the missing feature in a more general way? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 From noreply@sourceforge.net Sun Jun 2 19:32:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Jun 2002 11:32:32 -0700 Subject: [Patches] [ python-Patches-557946 ] Ebcdic compliancy in stringobject source Message-ID: Patches item #557946, was opened at 2002-05-19 14:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jean-Yves MENGANT (jymen) Assigned to: Nobody/Anonymous (nobody) Summary: Ebcdic compliancy in stringobject source Initial Comment: the printable character set test made inside strincgobject.c is not compliant with EBCDIC systems(OS390 or OS400) ---------------------------------------------------------------------- >Comment By: Jean-Yves MENGANT (jymen) Date: 2002-06-02 18:32 Message: Logged In: YES user_id=513881 I look at the approach taken in patch #479898 , looks fine so I made a quick test on OS390 EBCDIC platform just extracting the SINGLE_BYTE isprint based changed which works fine on OS390 too. It works well and is definitivelly the best approach for the problem. I looked also at the PRINT_MULTIBYTE_STRING approach based on iswprint. Looking at IBM's doc it should also work for OS390 EBCDIC too , allthough I am not able to test it on my OS390 box. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-28 09:58 Message: Logged In: YES user_id=21627 Modifying pyconfig.h.in (alone) is a mistake: this is a generated file, edit configure.in instead. When producing patches, please produce a single file containing all changes (e.g. with diff -r); this makes processing the patch simpler. I'm still opposed to singling-out a specific encoding; instead, I believe that the approach taken in patch #479898 is more general and ought to solve your problem as well. Can you please study this patch, and see whether you can make it work on your system? ---------------------------------------------------------------------- Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-26 16:38 Message: Logged In: YES user_id=513881 The last attached diff files contains a more robust patch by defining the HAVE_EBCDIC inside the pyconfig.h and using this file inside the stringobject.c ---------------------------------------------------------------------- Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-23 11:47 Message: Logged In: YES user_id=513881 I am still 100% with you on that ,my only remark here is that those are mainly either modules or py lib which are not part of python basic kernel. And the idea here is to be able to get a running minimal python kernel on an EBCDIC machine. After that when the basic kernel is up in EBCDIC mode you'll need to deal with some module/lib EBCDIC portability and decide wether or not to adress them if you need to use them.... But the important idea here is to have the python kernel running in order not to be obliged to use REXX if you're prefering python :=) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-23 09:54 Message: Logged In: YES user_id=21627 I believe there are a number of places where the code assumes that 'a' .. 'z' covers all Latin letters, and only those, e.g. pypcre.c, regexpr.c, sre.py. ---------------------------------------------------------------------- Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-23 08:38 Message: Logged In: YES user_id=513881 when porting to OS390(EBCDIC os) , the only place I found a bad ASCII asumption which leeds to further python's startup interpreter troubles is the one pointed here. When I fixed it I have been able to use the python interpreter kernel without troubles.Some modules like xmllib may make some ascii asumption but modules portability is a different story since those modules may be declared non EBCDIC compliant. On the second topic using a C library function I am 100% ok the only question is that I am persuaded that using for instance the isascii XPG C function will generate more complex and slower code when trying to keep it in compliancy both with EBCDIC/ASCII targets. Having a more generic #define like : #define EBCDIC inside the config.h set by ./configure when platform is EBCDIC is IMO the best compromise here. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:09 Message: Logged In: YES user_id=21627 Is it really worth fixing this? Python assumes that the character set of byte strings is an ASCII superset in many places. If there is any change made here, it should be based on C library functions, rather than on static knowledge of the operating system. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 From noreply@sourceforge.net Mon Jun 3 13:44:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Jun 2002 05:44:00 -0700 Subject: [Patches] [ python-Patches-551960 ] Add check for setrlimit() support Message-ID: Patches item #551960, was opened at 2002-05-03 18:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Add check for setrlimit() support Initial Comment: The new test_resource test calls resource.setrlimit() to change the file size limits. This fails on Cygwin, which supports setrlimit() and getrlimit(), just not changing that particular setting. (The same would apply to any other platforms that has those functions but not that particular feature.) Since that getrlimit() works, and setrlimit() can be used for other reasons, a check for sys.platform was added to that part of the test. ---------------------------------------------------------------------- >Comment By: Gerald S. Williams (gsw_agere) Date: 2002-06-03 12:44 Message: Logged In: YES user_id=329402 Since there are other limits that can be set via setrlimit(), failing the entire test due to a limitation on setrlimit(FSIZE) did not seem appropriate (even though this is currently the only resource limit that is tested). Besides, even though setrlimit(FSIZE) isn't allowed to change the value, it should still be able to set it to the values returned via getrlimit(), and should still report ValueError for extremely large values for either cur or max. So the test is meaningful even on systems that aren't allowed to lower the FSIZE limit. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 17:53 Message: Logged In: YES user_id=21627 I'm not sure I understand the logic in the modified setrlimit(FSIZE) case. If setting the limit fails, it seems that the entire test should be skipped. Raising TestSkipped might be appropriate, to indicate that the result of the test is not trustworthy. ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-06 13:11 Message: Logged In: YES user_id=329402 Cygwin Python raises ValueError when you call setrlimit() for RLIMIT_FSIZE. That limit is hardcoded at infinity and cannot be changed. I have submitted an alternative patch that looks for ValueError rather than checking sys.platform. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 08:44 Message: Logged In: YES user_id=21627 Don't check for systems, check for features instead. In this specific case, what error does Cygwin report? Could that be used to deal with the missing feature in a more general way? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 From noreply@sourceforge.net Mon Jun 3 17:45:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Jun 2002 09:45:00 -0700 Subject: [Patches] [ python-Patches-550765 ] SocketServer behavior Message-ID: Patches item #550765, was opened at 2002-04-30 16:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550765&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Gilfix (mgilfix) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer behavior Initial Comment: A bug, or lack of behavior in ServerSocket.py was exposed while created a unit test for Python 2.3. As of 2.3, signals between threads propagate differently. When cancelling a server that implemented threading with a keyboard interrupt, the server would shut down but not terminate (waiting on client threads). The fit for this was to make the client threads daemon-threads with the setDaemon call. Because this was non-apparent, this patch adds a member variable which acts as a hook and makes it clear that clients need to either set or unset the variable when deriving the class to control this behavior. setDaemon is off by default, as this is thought to be the consensus behavior. ---------------------------------------------------------------------- >Comment By: Michael Gilfix (mgilfix) Date: 2002-06-03 12:45 Message: Logged In: YES user_id=116038 All Address in the new patch. See SocketServer.py.patch.2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 13:44 Message: Logged In: YES user_id=21627 Could you please provide changes to the documentation as well (i.e. Doc/lib/libsocksvr.tex, and Misc/NEWS)? There is a typo: 'chanegs' -> 'changes' There is no need to attach the modified source to the patch; the context diff is enough. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550765&group_id=5470 From noreply@sourceforge.net Mon Jun 3 17:53:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Jun 2002 09:53:33 -0700 Subject: [Patches] [ python-Patches-563954 ] posixmodule.c RedHat 6.1 (bug #535545) Message-ID: Patches item #563954, was opened at 2002-06-03 18:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=563954&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: posixmodule.c RedHat 6.1 (bug #535545) Initial Comment: The given patch prevents the compiler error as described in bug #535545. Some side-effects occur - notably compiler warnings - but the glibc (or Linux) header files seem to protect against most undesirable redefinitions, it would seem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=563954&group_id=5470 From noreply@sourceforge.net Mon Jun 3 18:02:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Jun 2002 10:02:12 -0700 Subject: [Patches] [ python-Patches-557719 ] OSX build -- make python.app Message-ID: Patches item #557719, was opened at 2002-05-18 18:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557719&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: OSX build -- make python.app Initial Comment: Some small improvements to OSX build: 1. When building from separate directory than the build directory, automatic --with-suffix code was not working. 2. Tk for Mac OS X is detected and built automatically. 3. WASTE is found more automatically. 4. Building of Python.app can be invoked from the main makefile. (via make python.app) 5. A .pth file is installed in the Python.framework so that Mac modules are found by default. Also, a change to the Python IDE: when it looks for and creates an "IDE Scripts" folder under OSX, it was breaking. ---------------------------------------------------------------------- >Comment By: Tony Lownds (tonylownds) Date: 2002-06-03 17:02 Message: Logged In: YES user_id=24100 Hi Jack, I put in the WASTE search because, when building from CVS, the "sibling" directory to "python/" is "../../../waste". Without the search the developer needs to put WASTE into the "python/dist" directory. There are four cases I considered: building from a release or building from CVS, and building in a subdirectory fo the source tree or building in the source tree directly. That led to the search for up to 4 parent locations.Thanks for looking at the patch. Sorry for the delay in response, my SF email needs fixing. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-05-21 13:06 Message: Logged In: YES user_id=45365 Grabbed responsibility for this patch. Tony, the one thing I don't like is the search for WASTE by going up the file tree. What is your reason for wanting this? (so, consider this also a note that I *do* like all the rest of your patch;-) ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2002-05-18 18:47 Message: Logged In: YES user_id=24100 The new file python/dist/src/Mac/OSX/Mac.pth wasn't included in diff so I am attaching it now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557719&group_id=5470 From noreply@sourceforge.net Mon Jun 3 22:00:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Jun 2002 14:00:32 -0700 Subject: [Patches] [ python-Patches-400998 ] experimental support for extended slicing on lists Message-ID: Patches item #400998, was opened at 2000-07-27 17:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=400998&group_id=5470 Category: Core (C code) Group: None >Status: Open >Resolution: Remind Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) Summary: experimental support for extended slicing on lists Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-03 17:00 Message: Logged In: YES user_id=6380 Michael, the tide has changed. Would you be interested in reviving this patch and finishing it? It could possibly help to address bug 473985 and maybe also 459235. If you have no time, let me know and I'll see if I can find time myself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-18 17:19 Message: Rejected for lack of interest. Sorry, Michael! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-11-13 14:45 Message: Is reviewing and applying this patch the best use of my time? I note that this is okay, but low priority -- I doubt that it will get used much. Plus, what about the array module, strings, UserList? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-08-31 22:10 Message: Too late for the release, sorry. And Tim hates negative strides. We'll get back to this for 2.1. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-16 15:30 Message: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-16 15:30 Message: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-15 15:04 Message: OK, I'll get to that soon (ie. <24hours, hopefully <4). But bear in mind I'm now going to the pub... I may need some advice for the docs... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-08-15 14:53 Message: Note that without doc and test patches too, and Real Soon, I'll have to Postpone this. Assigned to me to remind me of that. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-30 14:41 Message: meep! naughty Michael hadn't been running "make test" often enough. this update fixes that. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-30 14:10 Message: bugfixes (refounting in assignment, logic in deletion) & a few tweaks. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-29 06:36 Message: updated patch to support slice assignements, deletions (needs testing still) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-28 02:47 Message: negative indices! for i in listvar[::-1]: pass now iterates over the list backwards (rather than coredumping...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-27 17:39 Message: c'mon michael! at least get *some* of the boundary cases... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-27 17:31 Message: this 10 minute hack adds support for "extended slicing" to lists, by which I mean things like: >>> range(100)[23:60:12] [23, 35, 47, 59] todo: find out if this is the approved approach add support for tuples write docs, testsuite (make test passes as is, but should be extended). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=400998&group_id=5470 From noreply@sourceforge.net Mon Jun 3 22:03:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Jun 2002 14:03:07 -0700 Subject: [Patches] [ python-Patches-440407 ] Remote execution patch for IDLE Message-ID: Patches item #440407, was opened at 2001-07-11 09:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440407&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Accepted Priority: 1 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Remote execution patch for IDLE Initial Comment: This is the code I have for the remote execution patch. (Remote execution must be enabled with an explicit command line argument -r.) Caveats: - undocumented - slow - security issue: the subprocess should not be the server but the client, to prevent a hacker from gaining access This should apply cleanly against IDLE as currently checked into the Python CVS tree. I don't want to check this in yet because of the security issue, and I don't have time to work on it. I hope the idlefork project will pick this up though and address the issues above. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-03 17:03 Message: Logged In: YES user_id=6380 IDLEFORK has now applied this patch and is working on making it better. Closing here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-09 09:19 Message: Logged In: YES user_id=6380 No, the IDLEfork project has stalled except for tweaking the configuration code (which would be good to merge into the Python IDLE tree when it's ready). I expect the patch failure is shallow so I won't bother fixing it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-09 06:02 Message: Logged In: YES user_id=21627 It appears the patch is slightly outdated now, atleast the chunk removing set_break does not apply anymore. Has this been integrated to idlefork? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 09:38 Message: Logged In: YES user_id=6380 Uploading the patch again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440407&group_id=5470 From noreply@sourceforge.net Mon Jun 3 22:45:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Jun 2002 14:45:57 -0700 Subject: [Patches] [ python-Patches-545096 ] Janitoring in ConfigParser Message-ID: Patches item #545096, was opened at 2002-04-17 10:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=545096&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Janitoring in ConfigParser Initial Comment: The first patch fixes a bug, implements some speed improvements, some memory consumption improvements, enforces the usage of the already available global variables, and extends the allowed chars in option names to be very permissive. The second one, if used, is supposed to be applied over the first one, and implements a walk() generator method for walking trough the options of a section. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-03 21:45 Message: Logged In: YES user_id=7887 Hello Fred! - About has_section(), I thought about the possibility of subclassing it. But, besides agreeing with you on the messy code matter, other functions weren't (and still aren't) considering this possibility, so I doubt some one will be able to subclass it anyways. Anyway, I may change the patch to use whatever you suggest. - About MAX_INTERPOLATION_DEPTH, I understand your position of wanting "a safety net", but my intention of using it in the code was not to let the user change it, but to clarify and give consistence to the code. I think using literal constants in the code is not a good measure at all. If this was adopted, many modules would have to be changed (in a bad way) for consistence. With a quick look at the library, I was able to find smtpd.py, base64.py, binhex.py, cgi.py, cmd.py, and many others using similar purpose constants. You'll probably agree with me if you think about this more extensively. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 16:11 Message: Logged In: YES user_id=3066 I should clarify: By "retain the use of the constant" I mean the constant numeric literal, not MAX_INTERPOLATION_DEPTH. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 16:06 Message: Logged In: YES user_id=3066 Two comments: - "section in self.__sections.keys()" can be written (still more efficiently) as "section in self.__sections", *but* the use of the sections() method is done to be subclass-friendly. I'm not sure how important this is since I can't imagine anyone actually subclassing from such a mass of messy code. Perhaps these could be modified to use the has_section() method, which is relatively new. - MAX_INTERPOLATION_DEPTH was not "honored" in the code since it's really a safety net; there's no intention that client code be able to change it. (The sanity of the value is not checked before use.) I'm inclined to retain the use of the constant in the interpolation code, and add a comment above the constant the it exists for informational purposes only. Otherwise, I'm fine with the patch. ;-) Sorry for the delay in responding to this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 17:55 Message: Logged In: YES user_id=6380 I'm assigning this to Fred Drake, who has some opinions on ConfigParser. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-04-18 17:07 Message: Logged In: YES user_id=7887 I'd rather explain here the patch that changes behavior, since it's pretty small. This line in the regular expression OPTCRE: r'(?P