From noreply@sourceforge.net Tue Apr 1 01:52:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 31 Mar 2003 17:52:13 -0800 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 12:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 1 Submitted By: Jon Riehl (jriehl) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-05 10:42 Message: Logged In: YES user_id=6380 Closed. Jon, if you're still interested in this, upload something new and reopen the patch (or I can do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 11:32 Message: Logged In: YES user_id=6380 Lowering priority until Jon has his next version ready. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-12 23:35 Message: Logged In: YES user_id=6380 Cool. Maybe I'll get to it, maybe not. :-( ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2002-09-12 13:04 Message: Logged In: YES user_id=22448 Guido, as per my private message, I'll attempt to submit another patch by the end of the month, pending resumption of "work" on the 23rd. Commitment of the memory allocation patch is fine, and any future patches would be against the updated pgen code (I don't have commit permissions, so someone else will have to do this possibly.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 07:09 Message: Logged In: YES user_id=6380 I looked a bit, and it's very raw - the author admits that. Jon, are you still working on this? Do you have a more polished version? Maybe we can separate out the memory allocation patches and commit these already? They don't break anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply@sourceforge.net Tue Apr 1 17:51:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Apr 2003 09:51:14 -0800 Subject: [Patches] [ python-Patches-713428 ] Fixes for 'commands' module on win32 Message-ID: Patches item #713428, was opened at 2003-04-01 12:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Warnes (warnes) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes for 'commands' module on win32 Initial Comment: Currently the 'commands' module is provided with python on Win32 systems, but does not function properly. (The library reference says it is only available on Unix). The commands module provides 3 functions: getoutput(cmd) returns output generated by executing 'cmd' in a shell getstatusoutput(cmd) returns (status,output) generated by executing 'cmd' in a shell getstatus(file) returns output of "ls -ld file" Below is a simple patch which enables 'getoutput' and 'getstatusoutut' to work properly on Win32. Since 'getstatusfile' only makes sense on Unix, the patch prevents it from being defined on Win32. The current behavior is maintained on all other platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470 From noreply@sourceforge.net Tue Apr 1 19:11:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Apr 2003 11:11:19 -0800 Subject: [Patches] [ python-Patches-709178 ] remove -static option from cygwinccompiler Message-ID: Patches item #709178, was opened at 2003-03-24 17:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709178&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Kabir Luebs (jkluebs) Assigned to: Jason Tishler (jlt63) Summary: remove -static option from cygwinccompiler Initial Comment: Currently, the cygwinccompiler.py compiler handling in distutils is invoking the cygwin and mingw compilers with the -static option. Logically, this means that the linker should choose to link to static libraries instead of shared/dynamically linked libraries. Current win32 binutils expect import libraries to have a .dll.a suffix and static libraries to have .a suffix. If -static is passed, it will skip the .dll.a libraries. This is pain if one has a tree with both static and dynamic libraries using this naming convention, and wish to use the dynamic libraries. The -static option being passed in distutils is to get around a bug in old versions of binutils where it would get confused when it found the DLLs themselves. The decision to use static or shared libraries is site or package specific, and should be left to the setup script or to command line options. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-04-01 10:11 Message: Logged In: YES user_id=86216 Martin, Thanks for your approval. I would like to check in the changes in parts. For example: 1. John's remove -static patch. 2. my get_versions() fix patch 3. my -shared patch 4. etc. In this way, I can more easily roll back if I goof. Can I just attach more patches to this one? Or, should I create a new SF patch for each of my patches? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 12:33 Message: Logged In: YES user_id=21627 jlt63: Your proposed changes all sound fine. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-31 08:02 Message: Logged In: YES user_id=86216 jkluebs> I can help with testing. I have access to W2K jkluebs> and Win98 (ugh) boxen. I don't mind jkluebs> installing a few older toolchains if you jkluebs> think that's necessary. Thanks for the offer. I'm set up for the current Cygwin and Mingw tool chains. Let's wait to see if testing with older ones is necessary. jkluebs> I think any C/C++ python extension using jkluebs> plain distutils (no fancy hacks added on) and jkluebs> has one or more DLL dependencies is a good jkluebs> test case. Can you point me to one that builds OOTB under Python 2.2.2? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-31 07:58 Message: Logged In: YES user_id=86216 loewis> I'm in favour of applying this patch, and loewis> also of patches that mandate recent Cygwin loewis> releases; I would like to apply an enhanced version of this patch. By enhanced, I mean using "gcc -shared" (no more dllwrap and gcc -mdll) and removing redundant gcc options, etc. Additionally, I would like to fix get_versions() so it can deal with versions that only have two components (e.g., 3.2) as opposed to requiring three (e.g. 2.95.3). Are these changes acceptable? loewis> if such patches are implemented, the minimum loewis> required Cygwin version should be stated loewis> somewhere. I propose that the currently available Cygwin and Mingw tool chains be that above stated minimum. Is this acceptable? Unfortunately, I have no idea where the above stated "somewhere" shoud be. ---------------------------------------------------------------------- Comment By: John Kabir Luebs (jkluebs) Date: 2003-03-28 14:31 Message: Logged In: YES user_id=87160 I can help with testing. I have access to W2K and Win98 (ugh) boxen. I don't mind installing a few older toolchains if you think that's necessary. I think any C/C++ python extension using plain distutils (no fancy hacks added on) and has one or more DLL dependencies is a good test case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-28 13:15 Message: Logged In: YES user_id=21627 I'm in favour of applying this patch, and also of patches that mandate recent Cygwin releases; if such patches are implemented, the minimum required Cygwin version should be stated somewhere. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-28 12:16 Message: Logged In: YES user_id=86216 John, would you be willing to help test or supply me with test cases? I have built exactly one Win32 extension. ---------------------------------------------------------------------- Comment By: John Kabir Luebs (jkluebs) Date: 2003-03-28 11:56 Message: Logged In: YES user_id=87160 The -mdll --entry DllMain@12 option is guarded for an old version of gcc that did not have the correct specs to accept -shared. I didn't touch it, even though it's crazy if anyone is using such an old and buggy toolchain. --shared and --dll are equivalent as far as ld is concerned. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-28 09:41 Message: Logged In: YES user_id=86216 Note that I only have minimal experience building Win32 extensions modules... This patch works "fine" with my *very* limited testing. Specifically, I successfully rebuilt the Win32 readline module with it applied. BTW, this area of Distutils probably should be revisited to bring it up to date. For example, the "-mdll --entry _DllMain@12" options could be replaced by "-shared". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 15:03 Message: Logged In: YES user_id=21627 Jason, can you take a look? If not, please unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709178&group_id=5470 From noreply@sourceforge.net Tue Apr 1 23:33:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Apr 2003 15:33:40 -0800 Subject: [Patches] [ python-Patches-713599 ] rfc8223.parsedate returns a tuple Message-ID: Patches item #713599, was opened at 2003-04-01 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713599&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: rfc8223.parsedate returns a tuple Initial Comment: It seems as though this should return a time.struct_time instead. Patch (trivial) attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713599&group_id=5470 From noreply@sourceforge.net Tue Apr 1 23:53:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Apr 2003 15:53:10 -0800 Subject: [Patches] [ python-Patches-713599 ] rfc822.parsedate returns a tuple Message-ID: Patches item #713599, was opened at 2003-04-01 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713599&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) >Summary: rfc822.parsedate returns a tuple Initial Comment: It seems as though this should return a time.struct_time instead. Patch (trivial) attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713599&group_id=5470 From noreply@sourceforge.net Wed Apr 2 01:17:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Apr 2003 17:17:48 -0800 Subject: [Patches] [ python-Patches-713645 ] freeze fails when extensions_win32.ini is missing Message-ID: Patches item #713645, was opened at 2003-04-01 17:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713645&group_id=5470 Category: Demos and tools Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: David Schnepper (dschnepper) Assigned to: Nobody/Anonymous (nobody) Summary: freeze fails when extensions_win32.ini is missing Initial Comment: Incorrect variable referenced during print of warning message when extensions_win32.ini is missing. Test: import checkextensions_win32 reload(checkextensions_win32) # for testing import os os.rename("extensions_win32.ini", "tmp.ini") try: checkextensions_win32.checkextensions([], [], "any") print "PASS: checkextensions with missing extensions_win32.ini" finally: os.rename("tmp.ini", "extensions_win32.ini") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713645&group_id=5470 From noreply@sourceforge.net Wed Apr 2 11:10:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Apr 2003 03:10:17 -0800 Subject: [Patches] [ python-Patches-713820 ] iconv_codec NG Message-ID: Patches item #713820, was opened at 2003-04-02 20:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713820&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: iconv_codec NG Initial Comment: This new implementation of iconv_codec resolves problems of current implementations below: - Having a reentrant context vulnerable point: encoder and/or decoder can be called multiple level in a same time when PEP293 codec error callback can call another iconv encoder session, too. So, all encode/ decode session must open their own iconv session but the current implementation shares the iconv session in the whole codec life time. - StreamReader can't work correctly: Because iconv keeps their context private, StreamReader can't work smart only with encode/decode function. Also, handling EINVAL and giving pending characters from previous data to error callback is very weak in the current implementation. - Putting a replacement character as just '?' is not safe for many encodings: On stateful encodings and non-byte stream encodings, we need to encode with iconv even for the replacement character. - Can't use encoding names including - and uppercases: Because codec subsystem changes - to _ and uppercases to lowercases, we can't pass them to the iconv_codec module without loss. For example, we need the next aliases to use CJK encodings on Sun iconv: # simplified chinese "euc_cn": "zh_CN.euc", "iso_2022_zh": "zh_CN.iso2022-CN", "gbk": "zh_CN.gbk", "cp935": "zh_CN-cp935", # traditional chinese "euc_tw": "zh_TW.euc", "iso_2022_tw": "zh_TW.iso2022-7", "big5": "zh_TW.big5", "cp937": "zh_TW.cp937", # japanese "iso_2022_jp": "ISO-2022-JP", "euc_jp": "eucJP", "shift_jis": "PCK", # korean "euc_kr": "ko_KR.euc", "iso_2022_kr": "ISO-2022-KR", "johab": "ko_KR.johap", "cp932": "ko_KR.cp932", "cp949": "ko_KR.cp949", - Can't try multiple unicode encodings or methods: On some iconv implementations like of HP-UX or Solaris, UCS2 -> ISO-8859-1 is available but UCS2 -> euc-kr isn't avaiable and only UTF-8 -> euc-kr is. And, many multibyte codecs such as CJK or iconv might have duplicated code for processing error callbacks and handling Streams. So, I splitted them out to another source. CJK and iconv codecs can share them just in source level by putting multibytecodec.c to Modules/ and linking the file to each of the codecs. Alternatively, if multibytecodec.c goes to Python/ and is linked to main python library, the codecs can be compiled and loaded by themselves. multibytecodec.c, the common multibyte codec framework can be used by any usual multibyte encodings. By using it, some codec writer can create a codec for his/her multibyte encodings without any care for handling error callbacks or implementing StreamReader structure. I wrote CJK codecs using it. and will submit a patch in an individual patch report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713820&group_id=5470 From noreply@sourceforge.net Wed Apr 2 11:23:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Apr 2003 03:23:32 -0800 Subject: [Patches] [ python-Patches-713824 ] Unicode Codecs for CJK Encodings Message-ID: Patches item #713824, was opened at 2003-04-02 20:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713824&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: Unicode Codecs for CJK Encodings Initial Comment: This patch includes the python unicode codecs for the following encodings: _ja_codecs: shiftjis cp932 euc_jp _ko_codecs: euc_kr cp949 _zh_CN_codecs: gb2312 cp936 gb18030 _zh_TW_codecs: big5 cp950 With this codecs, the Python can be a legal software in China. :) (gb18030 is a mandatory standard.) i386 stripped ELF size: 58416 _ja_codecs.so 59280 _ko_codecs.so 82992 _zh_CN_codecs.so 58224 _zh_TW_codecs.so powerpc unstripped Mach-O size: 88676 _ja_codecs.so 88096 _ko_codecs.so 111336 _zh_CN_codecs.so 86184 _zh_TW_codecs.so ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713824&group_id=5470 From noreply@sourceforge.net Wed Apr 2 16:53:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Apr 2003 08:53:39 -0800 Subject: [Patches] [ python-Patches-710127 ] Make "%c" % u"a" work Message-ID: Patches item #710127, was opened at 2003-03-26 17:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=710127&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Martin v. Löwis (loewis) >Summary: Make "%c" % u"a" work Initial Comment: Currently "%c" % u"a" fails, while "%s" % u"a" works. This patch fixes this problem. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-04-02 18:53 Message: Logged In: YES user_id=89016 OK, I've checked in the OverflowError change as: Objects/unicodeobject.c 2.185 Misc/NEWS 1.710 Lib/test/test_unicode.py 1.82 Closing the patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-01 00:16 Message: Logged In: YES user_id=21627 I can't see why "%c" % 256 should pass; interpreting the 256 as a Unicode ordinal is stretching things too much (if 256 was a Unicode ordinal, then 255 should be a Unicode ordinal too, and you would have to take into account the system encoding). I would think it would be consistent if both gave OverflowError (Result too large to be represented); this deserves another NEWS entry. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-31 20:36 Message: Logged In: YES user_id=89016 Checked in as: Misc/NEWS 1.708 Objects/stringobject.c 2.206 Lib/test/test_unicode.py 1.80 Lib/test/test_str.py 1.2 Lib/test/string_tests.py 1.30 BTW "%c" % 256 still fails. Should this be fixed too? "%c" % 256 raises an OverflowError now, u"%c" % sys.maxunicode+1 raises a ValueError. At least they should be changed to raise the same exception. If we fix "%c" % 256 what about chr()? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-29 15:18 Message: Logged In: YES user_id=21627 Looks fine, please apply it. Also add a test case that fails now but passes with the change, and add a NEWS entry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=710127&group_id=5470 From noreply@sourceforge.net Thu Apr 3 03:14:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Apr 2003 19:14:16 -0800 Subject: [Patches] [ python-Patches-714348 ] Guard against segfaults in debug code Message-ID: Patches item #714348, was opened at 2003-04-03 13:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714348&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mark Hammond (mhammond) Assigned to: Tim Peters (tim_one) Summary: Guard against segfaults in debug code Initial Comment: When dumping invalid objects, we may as well avoid segfaults if possible. This allows us to extract as much information as possible before dieing, which may be handy in release builds etc. Trivial patch just to get started (as I actually hit this block!). Assign back if you are OK with it, or I will be OK with you not wanting to start this slippery slope. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714348&group_id=5470 From noreply@sourceforge.net Thu Apr 3 03:16:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Apr 2003 19:16:30 -0800 Subject: [Patches] [ python-Patches-714348 ] Guard against segfaults in debug code Message-ID: Patches item #714348, was opened at 2003-04-03 13:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714348&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mark Hammond (mhammond) Assigned to: Tim Peters (tim_one) Summary: Guard against segfaults in debug code Initial Comment: When dumping invalid objects, we may as well avoid segfaults if possible. This allows us to extract as much information as possible before dieing, which may be handy in release builds etc. Trivial patch just to get started (as I actually hit this block!). Assign back if you are OK with it, or I will be OK with you not wanting to start this slippery slope. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-04-03 13:16 Message: Logged In: YES user_id=14198 Attaching patch. It indents a couple of blocks, so FYI, a --ignore-all-space diff is: RCS file: /cvsroot/python/python/dist/src/Objects/obmalloc.c,v retrieving revision 2.50 diff -w -r2.50 obmalloc.c 1126a1127 > int tail_reachable = 0; /* can we dereference tail without segfault */ 1163a1165,1175 > #ifdef MS_WINDOWS > _try { > #endif /* MS_WINDOWS */ > tail_reachable = *tail ? 1 : 1; /* if we don't die, it is reachable! */ > #ifdef MS_WINDOWS > } _except(1) { > /* tail_reachable remains 0 */ > } > #endif /* MS_WINDOWS */ > > if (tail_reachable) { 1185a1198,1200 > } else { > fprintf(stderr, "INVALID\n"); > } 1197c1212 < if (q < tail) { --- > if (q < tail && tail_reachable) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714348&group_id=5470 From noreply@sourceforge.net Thu Apr 3 05:04:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Apr 2003 21:04:51 -0800 Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv Message-ID: Patches item #670715, was opened at 2003-01-19 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Martin v. Löwis (loewis) Summary: Universal Unicode Codec for POSIX iconv Initial Comment: Here's the unicode codec using POSIX iconv(3) library. Tested on these platforms and seems to work: FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64, FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2 This codec implementation supports PEP293, also. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-03 07:04 Message: Logged In: YES user_id=21627 I have reverted this patch because of problems with setup.py 1.159 __init__.py 1.17 iconv_codec.py delete regrtest.py 1.137 test_iconv_codecs.py delete NEWS 1.712 Setup.dist 1.39 _iconv_codec.c delete ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 21:10 Message: Logged In: YES user_id=539787 It was a misspelling; ISO8859-7 is what I used in the module, the underscore came from my using it with str.decode ("iso8859_7"). o2k 348# ls -l python -rwxr-xr-x 1 root sys 1976320 Feb 4 21:21 python o2k 349# ./python Python 2.3a1 (#12, Feb 4 2003, 21:14:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "a".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) I then changed it to: iconv_t hdl = iconv_open("UCS-2", "LATIN1"); (sys.maxunicode is 65535) and it still fails at the same line (I ran "dbx python core"). I made sure that I use the freshly built _iconv_codec.so (ie no other exists on the system). I added some code to show the errno, and it's 22 (EINVAL). I ran iconv -l at the prompt, and used UCS-2 and ISO8859-1 (LATIN1 didn't show up in the list). Now, the code runs fine for str.decode and unicode.encode, and test.test_codecs and test.test_263 pass fine. (BTW, if you're used to vi keystrokes, never press ESC while typing with IE in the "Add a comment:" text box... :( ) I then applied the diff-debug patch, and got: >>> "a".decode("ascii") init_iconv_codec: 0x0030 u'a' Please note that on Irix, UCS-2-INTERNAL is not available, only UCS-2, so that had to be changed too. It's an initialisation thing; I could provide a special case of defines for Irix, but how can you know which codecs are available on a platform during the configure process? Perhaps running iconv -l and trying to decode the output? iconv -l on GNU/linux shows a comma separated list, while on Irix it shows pairs of available conversions, one on each line... Thanks for the direction about encodings/__init__.py, Walter. Thanks guys, now I must find if pymalloc has changed and occasionally dumps core in dictresize or listextend_internal... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:57 Message: Logged In: YES user_id=89016 "ISO8859_7" is not known on Linux, can you try "ISO8859-7" or better "ISO8859-1" or "LATIN1"? Also I wonder whether it is a good thing to test iconv() with the character '\x01'. Can you try diff-char.txt and see what happens? If all this fails, try diff-debug.txt and report what the output is. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:02 Message: Logged In: YES user_id=539787 I am afraid that SGI Irix' iconv must be added to the list of scary commercial implementations... at first the module did not compile due to two missing typecasts (see patch 680146), but even after that, the module fails (and python dumps core): Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) (message at line 674 of the module) This is because Irix iconv knows nothing about ASCII encoding... I changed the "ASCII" argument to something existing, "ISO8859_7" which is my country's encoding, and then python dumps core with: Fatal Python error: can't initialize the _iconv_codec module: mixed endianess Abort (core dumped) MIPS processors are big endian. python works fine in all my programs where there is no use of str.decode and unicode.encode . To make sure that the problem exists only in this module, I need to compile without the _iconv_codec . Do I do that by changing setup.py? This seems the way, but I haven't succeeded yet. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 21:04 Message: Logged In: YES user_id=89016 I checked in a version of iconvcodec-3.txt that does a byte swapping check in the init function as Modules/_iconv_codec.c 1.5 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 19:26 Message: Logged In: YES user_id=89016 iconvcodec-3.txt does byteswapping under the following conditions: #ifndef WORDS_BIGENDIAN #ifdef __GNU_LIBRARY__ Byteswapping is done before encoding to the whole input and to every piece returned from iconv() for decoding. Detecting whether byteswapping is neccessary might not work reliably with the above tests. If this is the case, a test call to iconv() should probably be done in Modules/_conv_codec.c::init_iconv_codec() to determine whether to byte swap or not. Another possibility might be to use utf-16/utf-32 instead of ucs-2/ucs-4. One test still fails: test_sane(), because it uses the internal encoding in Python, where the real endianness is of course unknown. The test also assumes a narrow Python build. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-26 16:19 Message: Logged In: YES user_id=55188 Thank you very much for your works. I'm working on UCS endian detection and UCS transparent wrapper for UTF-{8,16}. I'll submit new patch in a week. Please feel free to change my codes because I'm not familiar with python code convention and culture. :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 12:32 Message: Logged In: YES user_id=21627 I have committed it now with minimal changes so that it works on Linux, as setup.py 1.138 __init__.py 1.15 iconv_codec.py 1.1 regrtest.py 1.117 NEWS 1.627 I will make further changes; please watch the CVS. If you would like to make further changes, please submit patches against the CVS. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 02:07 Message: Logged In: YES user_id=21627 Hmm. I see that Solaris does support conversion of CJK to UTF-8. So even though we cannot convert into the internal encoding, we could still convert through UTF-8. Looking at /usr/lib/nls/iconv/config.iconv of HP-UX 11.11, I see conversions from and to ucs2, for iso-8859, eucJP, sjis, eucTW, big5, roc15, kore5, hp15CN, and many IBM code pages. So I think the iconv codec should convert into the Python internal representation if possible. If no encoding name for that is known, it should convert to ucs2 (be) if possible, or else to UTF-8; in all cases, it will then construct a Unicode object from the resulting string. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-22 01:21 Message: Logged In: YES user_id=55188 iconv implementations on commercial UNIXes are very scary. Solaris implementation: no support for CJK <-> UCS conversion. They support UCS[24] only for iso-8859 and UTFs. HP-UX implementation: They have useless iconv. HP-UX iconv has no unicode support. BSD implementation (Konstantin Chuguev's): compatible with this patch (provides ucs-[24]-internal) GLIBC implementation: provides ucs-[24] and they are same with GNU iconv's ucs-[24]-internal. Because ucs-[24] of GNU/BSD implentation is big endian always. We can't use ucs-[24] for every platform. In conclusion, we must use 3rd party iconv on Solaris or HP-UX. And, we need to detect whether the linked iconv is GNU/BSD iconv or GLIBC iconv. (how?) I'll investigate how to detect them, but ... :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-21 23:27 Message: Logged In: YES user_id=21627 I'm quite happy with this patch, and will apply it shortly. However, I am concerned that it is specific for GNU iconv. IMO, there should be machinery to find out the "internal" encoding, in case native the native iconv implementation is used instead of GNU iconv. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-20 14:33 Message: Logged In: YES user_id=55188 Thank you for comments. :-> I uploaded a new revised patch with unittest and some code style fixes. I saw Martin v. Loewis's iconvcodecs about a years ago. His implementation is very neat, but it had a limit on error handling due to recursive call. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-19 23:56 Message: Logged In: YES user_id=38388 The patch looks good, but you'll need to add some form of testing to underline the "seems to work" :-) Some docs on how to use the codec would also be needed. Martin von Loewis has written a similar codec some months ago. Perhaps you two could get in touch and sort out the details ?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470 From noreply@sourceforge.net Thu Apr 3 05:07:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Apr 2003 21:07:58 -0800 Subject: [Patches] [ python-Patches-713820 ] iconv_codec NG Message-ID: Patches item #713820, was opened at 2003-04-02 13:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713820&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: iconv_codec NG Initial Comment: This new implementation of iconv_codec resolves problems of current implementations below: - Having a reentrant context vulnerable point: encoder and/or decoder can be called multiple level in a same time when PEP293 codec error callback can call another iconv encoder session, too. So, all encode/ decode session must open their own iconv session but the current implementation shares the iconv session in the whole codec life time. - StreamReader can't work correctly: Because iconv keeps their context private, StreamReader can't work smart only with encode/decode function. Also, handling EINVAL and giving pending characters from previous data to error callback is very weak in the current implementation. - Putting a replacement character as just '?' is not safe for many encodings: On stateful encodings and non-byte stream encodings, we need to encode with iconv even for the replacement character. - Can't use encoding names including - and uppercases: Because codec subsystem changes - to _ and uppercases to lowercases, we can't pass them to the iconv_codec module without loss. For example, we need the next aliases to use CJK encodings on Sun iconv: # simplified chinese "euc_cn": "zh_CN.euc", "iso_2022_zh": "zh_CN.iso2022-CN", "gbk": "zh_CN.gbk", "cp935": "zh_CN-cp935", # traditional chinese "euc_tw": "zh_TW.euc", "iso_2022_tw": "zh_TW.iso2022-7", "big5": "zh_TW.big5", "cp937": "zh_TW.cp937", # japanese "iso_2022_jp": "ISO-2022-JP", "euc_jp": "eucJP", "shift_jis": "PCK", # korean "euc_kr": "ko_KR.euc", "iso_2022_kr": "ISO-2022-KR", "johab": "ko_KR.johap", "cp932": "ko_KR.cp932", "cp949": "ko_KR.cp949", - Can't try multiple unicode encodings or methods: On some iconv implementations like of HP-UX or Solaris, UCS2 -> ISO-8859-1 is available but UCS2 -> euc-kr isn't avaiable and only UTF-8 -> euc-kr is. And, many multibyte codecs such as CJK or iconv might have duplicated code for processing error callbacks and handling Streams. So, I splitted them out to another source. CJK and iconv codecs can share them just in source level by putting multibytecodec.c to Modules/ and linking the file to each of the codecs. Alternatively, if multibytecodec.c goes to Python/ and is linked to main python library, the codecs can be compiled and loaded by themselves. multibytecodec.c, the common multibyte codec framework can be used by any usual multibyte encodings. By using it, some codec writer can create a codec for his/her multibyte encodings without any care for handling error callbacks or implementing StreamReader structure. I wrote CJK codecs using it. and will submit a patch in an individual patch report. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-03 07:07 Message: Logged In: YES user_id=21627 Because of complaints about its brokenness, I had to revert the current iconv codec. It is extremely unlikely that such code will be added for Python 2.3. So please update this submission for the current CVS. There is no need to hurry, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713820&group_id=5470 From noreply@sourceforge.net Thu Apr 3 07:06:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Apr 2003 23:06:27 -0800 Subject: [Patches] [ python-Patches-536883 ] SimpleXMLRPCServer auto-docing subclass Message-ID: Patches item #536883, was opened at 2002-03-29 11:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=536883&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Martin v. Löwis (loewis) Summary: SimpleXMLRPCServer auto-docing subclass Initial Comment: This SimpleXMLRPCServer subclass automatically serves HTML documentation, generated using pydoc, in response to an HTTP GET request (XML-RPC always uses POST). Here are some examples: http://www.sweetapp.com/cgi-bin/xmlrpc-test/rpc1.py http://www.sweetapp.com/cgi-bin/xmlrpc-test/rpc2.py ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2003-04-02 23:06 Message: Logged In: YES user_id=108973 Module resubmitted with test function. Documentation attached in text format. The documentation doesn't seem terribly good to me so feel free to suggest changes. Will it be clear to the newbie that they should look at SimpleXMLRPCServer for RPC related methods? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 13:30 Message: Logged In: YES user_id=21627 Ok, leave the naming as-is, unless other reviewers comment in one direction or the other. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2003-03-31 01:22 Message: Logged In: YES user_id=108973 Write test function: ok Write documentation: ok >If the module is named, say, DocXMLRPCServer, there is >no need to have the Doc prefix on the class names. Hmmm. If you look at the core BaseHTTPRequestHandler derived classes, each one is prefixed to match the module that it is found in. The only two modules that I can think of with identical class names are cStringIO and StringIO, which theoretically provide identical semantics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 01:07 Message: Logged In: YES user_id=21627 I see. The code is fine, but it needs to come with a test function, to operate the module as a program. I suggest that the test server provides the get_source_code() operation just as your demo client does; the docstring of the class may provide an xmlrpclib fragment that retrieves the source code (AFAICT, the source code is not directly accessible through an URL, is it?) I also recommend that you reconsider renaming the classes: If the module is named, say, DocXMLRPCServer, there is no need to have the Doc prefix on the class names. Instead, they can be named just "XMLRPCServer" etc. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2003-03-30 22:56 Message: Logged In: YES user_id=108973 >I'm not sure how to place this. Is this an extension to >pydoc? No. This module provides subclasses for SimpleXMLRPCServer and CGIXMLRPCServer. These subclasses serve pydoc-style documentation when you point your browser at them - see the examples in the patch summary. > Should it go into Tools, or into Lib, or into some > existing module? The attached file should go into Lib. > If this goes into Lib somewhere, it lacks documentation. Fair enough. Conditional on me writing documentation, is this contribution acceptable as is? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 06:59 Message: Logged In: YES user_id=21627 I'm not sure how to place this. Is this an extension to pydoc? Should it go into Tools, or into Lib, or into some existing module? If this goes into Lib somewhere, it lacks documentation. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2003-02-10 12:25 Message: Logged In: YES user_id=108973 Patch 473586 has been accepted so this patch can be accepted. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2002-04-04 11:26 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about the description: This patch is dependant on patch 473586: [473586] SimpleXMLRPCServer - fixes and CGI So please don't check this in until that patch is accepted. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2002-04-04 09:55 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about the description: This patch is dependant on patch 473586: [473586] SimpleXMLRPCServer - fixes and CGI So please don't check this in until that patch is accepted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-04 09:31 Message: Logged In: YES user_id=6380 Looks cute to me. Fredrik, any problem if I just check this in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=536883&group_id=5470 From noreply@sourceforge.net Thu Apr 3 12:51:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Apr 2003 04:51:51 -0800 Subject: [Patches] [ python-Patches-714592 ] timeouts for FTP connect (and other supported ops) Message-ID: Patches item #714592, was opened at 2003-04-03 13:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714592&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Russell (mattruss) Assigned to: Nobody/Anonymous (nobody) Summary: timeouts for FTP connect (and other supported ops) Initial Comment: This patch attempts to provide users with support for enabling the timeout feature on the undlying socket. new parameter added to the __init__ and connect(). i have tested this only briefly. ftp = ftplib.FTP() ftp.connect(host="ftp.python.org", timeout=2) ftp.settimeout(0.01) -> Error socket.error: (11, 'Resource temporarily unavailable') ftp.settimeout(1.2) ftp.login("anonymous") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714592&group_id=5470 From noreply@sourceforge.net Thu Apr 3 14:49:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Apr 2003 06:49:30 -0800 Subject: [Patches] [ python-Patches-714592 ] timeouts for FTP connect (and other supported ops) Message-ID: Patches item #714592, was opened at 2003-04-03 07:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714592&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Russell (mattruss) Assigned to: Nobody/Anonymous (nobody) Summary: timeouts for FTP connect (and other supported ops) Initial Comment: This patch attempts to provide users with support for enabling the timeout feature on the undlying socket. new parameter added to the __init__ and connect(). i have tested this only briefly. ftp = ftplib.FTP() ftp.connect(host="ftp.python.org", timeout=2) ftp.settimeout(0.01) -> Error socket.error: (11, 'Resource temporarily unavailable') ftp.settimeout(1.2) ftp.login("anonymous") ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-03 09:49 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714592&group_id=5470 From noreply@sourceforge.net Thu Apr 3 23:43:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Apr 2003 15:43:52 -0800 Subject: [Patches] [ python-Patches-714957 ] Document freeze process in PC/config.c Message-ID: Patches item #714957, was opened at 2003-04-03 15:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714957&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Schnepper (dschnepper) Assigned to: Nobody/Anonymous (nobody) Summary: Document freeze process in PC/config.c Initial Comment: Resolved an XXX comment in PC/config.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714957&group_id=5470 From noreply@sourceforge.net Thu Apr 3 23:46:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Apr 2003 15:46:37 -0800 Subject: [Patches] [ python-Patches-714957 ] Document freeze process in PC/config.c Message-ID: Patches item #714957, was opened at 2003-04-03 15:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714957&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None >Priority: 2 Submitted By: David Schnepper (dschnepper) Assigned to: Nobody/Anonymous (nobody) Summary: Document freeze process in PC/config.c Initial Comment: Resolved an XXX comment in PC/config.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714957&group_id=5470 From noreply@sourceforge.net Fri Apr 4 12:36:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Apr 2003 04:36:15 -0800 Subject: [Patches] [ python-Patches-714592 ] timeouts for FTP connect (and other supported ops) Message-ID: Patches item #714592, was opened at 2003-04-03 13:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714592&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Russell (mattruss) Assigned to: Nobody/Anonymous (nobody) Summary: timeouts for FTP connect (and other supported ops) Initial Comment: This patch attempts to provide users with support for enabling the timeout feature on the undlying socket. new parameter added to the __init__ and connect(). i have tested this only briefly. ftp = ftplib.FTP() ftp.connect(host="ftp.python.org", timeout=2) ftp.settimeout(0.01) -> Error socket.error: (11, 'Resource temporarily unavailable') ftp.settimeout(1.2) ftp.login("anonymous") ---------------------------------------------------------------------- >Comment By: Matthew Russell (mattruss) Date: 2003-04-04 13:36 Message: Logged In: YES user_id=737261 The patch i suggested could be applied at a higher level of abstraction to counter duplication in other connect()'s in most other Protocols. Please consider the following argument (on google): http://groups.google.com/groups?dq=&start=25&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&group=comp.lang.python&selm=459f9b68.0304030504.48f0a940%40posting.google.com The classes ftplib.FTP, telnet.Telnet, httplib.HTTPConnection are affected. There may be more (?) NB open function is more or less the same as connect in telnetlib. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-03 15:49 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714592&group_id=5470 From noreply@sourceforge.net Fri Apr 4 12:38:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Apr 2003 04:38:52 -0800 Subject: [Patches] [ python-Patches-714592 ] timeouts for FTP connect (and other supported ops) Message-ID: Patches item #714592, was opened at 2003-04-03 13:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714592&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Russell (mattruss) Assigned to: Nobody/Anonymous (nobody) Summary: timeouts for FTP connect (and other supported ops) Initial Comment: This patch attempts to provide users with support for enabling the timeout feature on the undlying socket. new parameter added to the __init__ and connect(). i have tested this only briefly. ftp = ftplib.FTP() ftp.connect(host="ftp.python.org", timeout=2) ftp.settimeout(0.01) -> Error socket.error: (11, 'Resource temporarily unavailable') ftp.settimeout(1.2) ftp.login("anonymous") ---------------------------------------------------------------------- >Comment By: Matthew Russell (mattruss) Date: 2003-04-04 13:38 Message: Logged In: YES user_id=737261 that link should of read: http://groups.google.com/groups?dq=&start=25&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&group=comp.lang.python&selm=459f9b68.0304030504.48f0a940%40posting.google.com sorry ---------------------------------------------------------------------- Comment By: Matthew Russell (mattruss) Date: 2003-04-04 13:36 Message: Logged In: YES user_id=737261 The patch i suggested could be applied at a higher level of abstraction to counter duplication in other connect()'s in most other Protocols. Please consider the following argument (on google): http://groups.google.com/groups?dq=&start=25&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&group=comp.lang.python&selm=459f9b68.0304030504.48f0a940%40posting.google.com The classes ftplib.FTP, telnet.Telnet, httplib.HTTPConnection are affected. There may be more (?) NB open function is more or less the same as connect in telnetlib. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-03 15:49 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714592&group_id=5470 From noreply@sourceforge.net Fri Apr 4 18:33:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Apr 2003 10:33:14 -0800 Subject: [Patches] [ python-Patches-715466 ] failed attempt to fix boom Message-ID: Patches item #715466, was opened at 2003-04-04 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=715466&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Tim Peters (tim_one) Summary: failed attempt to fix boom Initial Comment: This patch allows boom.py to run successfully but blows up in the regression test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=715466&group_id=5470 From noreply@sourceforge.net Fri Apr 4 18:40:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Apr 2003 10:40:17 -0800 Subject: [Patches] [ python-Patches-715466 ] patch to fix boom Message-ID: Patches item #715466, was opened at 2003-04-04 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=715466&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Tim Peters (tim_one) >Summary: patch to fix boom Initial Comment: This patch allows boom.py to run successfully but blows up in the regression test. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-04-04 18:40 Message: Logged In: YES user_id=31392 Actually, it may not be as bad as I feared. It blew up in the regression test because of unfinished changes I had to make cPickle.Pickler objects traversable. Otherwise, it looks like the only failure is test_gc's test_list(). I don't understand quite why the resurrection during hasattr() works, but it seems to work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=715466&group_id=5470 From noreply@sourceforge.net Fri Apr 4 20:39:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Apr 2003 12:39:35 -0800 Subject: [Patches] [ python-Patches-715466 ] patch to fix boom Message-ID: Patches item #715466, was opened at 2003-04-04 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=715466&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Tim Peters (tim_one) Summary: patch to fix boom Initial Comment: This patch allows boom.py to run successfully but blows up in the regression test. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-04-04 18:40 Message: Logged In: YES user_id=31392 Actually, it may not be as bad as I feared. It blew up in the regression test because of unfinished changes I had to make cPickle.Pickler objects traversable. Otherwise, it looks like the only failure is test_gc's test_list(). I don't understand quite why the resurrection during hasattr() works, but it seems to work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=715466&group_id=5470 From noreply@sourceforge.net Sun Apr 6 10:20:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Apr 2003 01:20:23 -0800 Subject: [Patches] [ python-Patches-701494 ] more apply removals Message-ID: Patches item #701494, was opened at 2003-03-11 07:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=701494&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Raymond Hettinger (rhettinger) Summary: more apply removals Initial Comment: More apply() removals from the following files: ./compiler/transformer.py ./curses/wrapper.py ./distutils/command/build_ext.py ./distutils/command/build_py.py ./distutils/archive_util.py ./distutils/dir_util.py ./distutils/filelist.py ./distutils/util.py ./bsddb/test/test_basics.py ./bsddb/test/test_dbobj.py ./bsddb/dbobj.py ./bsddb/dbshelve.py ./lib-tk/Canvas.py ./lib-tk/Dialog.py ./lib-tk/ScrolledText.py ./lib-tk/Tix.py ./lib-tk/Tkinter.py ./lib-tk/tkColorChooser.py ./lib-tk/tkCommonDialog.py ./lib-tk/tkFont.py ./lib-tk/tkMessageBox.py ./lib-tk/tkSimpleDialog.py ./lib-tk/turtle.py ./test/reperf.py ./test/test_b1.py ./test/test_builtin.py ./test/test_curses.py ./logging/__init__.py ./logging/config.py ./xml/dom/minidom.py ./plat-mac/Carbon/MediaDescr.py ./plat-mac/EasyDialogs.py ./plat-mac/FrameWork.py ./plat-mac/MiniAEFrame.py ./plat-mac/argvemulator.py ./plat-mac/icopen.py I know that the edited files are syntactically correct (ie compileall.compile_dir throws no errors), but please help testing that functionality is the same. I am testing at the moment for lib-tk changes. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-06 04:20 Message: Logged In: YES user_id=80475 Re-reviewed files. Fixed one incomplete + (,args) in Tix.py. Added pending deprecation doc string to apply(). Marked approved and applied (no pun intended). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-03-21 03:32 Message: Logged In: YES user_id=357491 Well, then SF is broken right now because I don't have an option to upload. As for the PendingDeprecationWarning check, I think that is a good idea. Shouldn't that be a separate patch, though? I personally can't do it any time soon because of PyCon plus I have updating test_urllib on my todo list (thanks, Raymond =). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-21 03:16 Message: Logged In: YES user_id=89016 This shouldn't have anything to do with commit privileges. I'm uploading your apply3.diff so it doesn't get lost. If test_builtin calls apply it should probably make sure that both the PendingDeprecationWarning and the DeprecationWarning that might be issued some day are switched off. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-03-21 02:42 Message: Logged In: YES user_id=357491 Well, I have now run into my first issue of not having commit priveleges; I can't upload my diff. So you will have to get it from http://www.ocf.berkeley.edu/~bac/apply3.diff . The only difference between my diff and Walter's is that I changed three files and removed the diff for test_builtin.py . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-21 00:14 Message: Logged In: YES user_id=80475 Good job Brett :-) I'll wait for your next post before going through this one with a fine toothed comb. -- R ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-03-20 21:49 Message: Logged In: YES user_id=357491 I went through Walter's diff by hand and found two places where more clean-up could be done and two show-stoppers. In case I don't get my version of the patch up fast enough for people, the files that have spots that could use some more minor clean-up are Lib/lib-tk/Tix.py and Lib/lib-tk/Tkinter.py . The showstoppers are in Lib/lib-tk/tkCommonDialog.py (method call that didn't get *'ed) and Lib/test/test_builtin.py (test_builtin.py should not even be patched since the affected lines are in the tests for apply() itself). I will have my version up before the weekend. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-20 10:26 Message: Logged In: YES user_id=89016 I've gone over the patch and simplyfied it a bit (e.g. replacing f(*(1,2,3) + args) with f(1,2,3, *args)). I've also removed the patches for distutils, logging and bsddb (code at the start of bsddb/dbutils.py seems to indicate that it should be usable with versions prior to 2.3). Raymond, do you have time to recheck the patch? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-03-12 03:46 Message: Logged In: YES user_id=539787 Walter: I untargzipped the python-latest.tgz of 2003-03-10 over an older directory (I think about a month ago), therefore the existence of test_b1.py. All files that exist in the current dist were also current. Raymond: you are correct about my not reading the file headers (it was a multifile vi session with a +/"apply(" option...) I just had a little time available for non-creative work, so I checked, saw that Guido already had changed most of the library files, and offered the change of the rest of them; you guys can do whatever you want with it :) The lib-tk changes seem to be ok, after running some UI python scripts I have. I haven't checked bsddb yet. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 20:41 Message: Logged In: YES user_id=80475 Also, be sure to read the PEP on which modules should not be modernized. Sometimes that information is written in the file itself rather than the pep. For instance, the logging package is supposed to be kept in a form that runs on older pythons. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 13:34 Message: Logged In: YES user_id=89016 There is no longer a test/test_b1.py in current CVS, so it seems you've done the diff against an older version. Could you update the patch for current CVS? Also according to PEP 291 (http://www.python.org/peps/pep-0291.html) both distutils and logging should remain 1.5.2 compatible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=701494&group_id=5470 From noreply@sourceforge.net Mon Apr 7 03:19:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Apr 2003 19:19:19 -0700 Subject: [Patches] [ python-Patches-706707 ] time.tzset standards compliance update Message-ID: Patches item #706707, was opened at 2003-03-20 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706707&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Stuart Bishop (zenzen) Assigned to: Neal Norwitz (nnorwitz) Summary: time.tzset standards compliance update Initial Comment: Update to configure.in and test_time.py to only use TZ environment variable format documented at http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2003-04-07 12:19 Message: Logged In: YES user_id=46639 The bare except can go (just 'time.tzset()' without the try..except around it). The failure under Redhat is wierd - I can confirm that it works on a Redhat 7.2 box (as well as under OS X 10.2 and Solaris 2.8). The Australian timezone checks are testing that the timezone initialization stuff works in the southern hemisphere, and that time.altzone is being reset by tzset(). This will probably need to be taken to Python-dev unless you feel like applying the patch to HEAD and seeing who screams. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-30 07:46 Message: Logged In: YES user_id=33168 In the last chunk added, there is a bare except when calling time.tzset(). What are the possible exceptions? I don't want to have a bare except since this can mask a real error. The patch still fails for me on Linux (Redhat): * line 107: self.failUnless(time.tzname[1] == 'AEDT') - tzname has: ('AEST', 'AEST') * line 109: self.failUnlessEqual(time.daylight, 1) * line 111: self.failUnlessEqual(time.altzone, -39600) Haven't tried on other Unixes. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-03-28 07:12 Message: Logged In: YES user_id=46639 tzset3.diff is an updated diff against the CVS head. Fixes: -Don't test time.altzone for UTC - non-DST means altzone is undefined -Make sure dst timezone name is not the same as non-dst timezone name in TZ environment variable, to work around an apparent Solaris bug. -Extraneous cruft removed from test_time.py and configure.in - no more irrelevant comments. -More whitespace as per Tim's comments comments. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-22 08:28 Message: Logged In: YES user_id=33168 After patching, the test fails: File "/home/neal/build/python/2_3/Lib/test/test_time.py", line 115, in test_tzset self.failUnlessEqual(time.daylight,1) File "/home/neal/build/python/2.3/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 0 != 1 Also, why is the code commented out (via a string) on lines 120-144? Should these be removed? I see the comment about wallclock time, but don't understand why the code should be left in if we can't test it. I can understand a comment describing generally the issue. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-21 12:18 Message: Logged In: YES user_id=33168 I'll try to get to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-21 12:11 Message: Logged In: YES user_id=6380 Unassigning, as I won't hve time for this. But it is important - someone else should make sure this goes into 2.3b1! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 08:50 Message: Logged In: YES user_id=31435 Assigned to Guido, as I can't test it. Two notes: 1. Leaving commented-out code in config and the test suite doesn't appear to serve a purpose, although it will serve to confuse future readers ("why is this here? why is it commented out?"). 2. The Python style guide asks for a blank after commas in argument lists and tuples. We're not really in danger of stretching the screen here . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706707&group_id=5470 From noreply@sourceforge.net Mon Apr 7 13:30:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 05:30:53 -0700 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 13:03 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Open Resolution: Wont Fix Priority: 1 Submitted By: Jon Riehl (jriehl) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-05 11:42 Message: Logged In: YES user_id=6380 Closed. Jon, if you're still interested in this, upload something new and reopen the patch (or I can do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 12:32 Message: Logged In: YES user_id=6380 Lowering priority until Jon has his next version ready. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-13 00:35 Message: Logged In: YES user_id=6380 Cool. Maybe I'll get to it, maybe not. :-( ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2002-09-12 14:04 Message: Logged In: YES user_id=22448 Guido, as per my private message, I'll attempt to submit another patch by the end of the month, pending resumption of "work" on the 23rd. Commitment of the memory allocation patch is fine, and any future patches would be against the updated pgen code (I don't have commit permissions, so someone else will have to do this possibly.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 08:09 Message: Logged In: YES user_id=6380 I looked a bit, and it's very raw - the author admits that. Jon, are you still working on this? Do you have a more polished version? Maybe we can separate out the memory allocation patches and commit these already? They don't break anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply@sourceforge.net Mon Apr 7 13:38:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 05:38:25 -0700 Subject: [Patches] [ python-Patches-698505 ] docs for hotshot module Message-ID: Patches item #698505, was opened at 2003-03-06 16:36 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=698505&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: docs for hotshot module Initial Comment: The attached provides documentation for the hotshot module. Assigning to Fred for review. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-04-07 22:38 Message: Logged In: YES user_id=29957 checked in. I'll look into adding further docs as I get more into the code I'm writing to sit on top of hotshot (to replace pstats)... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-11 04:02 Message: Logged In: YES user_id=3066 Please commit. Further changes can be made in CVS. Thanks! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-07 17:43 Message: Logged In: YES user_id=80475 The TeX markup checks out fine. Consider documenting lineevents and linetimings which are exposed upon: import hotshot. For the example, consider adding a comment line at the beginning with hints that the example produces large files and takes a long time to run. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-03-06 16:39 Message: Logged In: YES user_id=29957 stupid sourceforge tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=698505&group_id=5470 From noreply@sourceforge.net Mon Apr 7 21:04:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 13:04:03 -0700 Subject: [Patches] [ python-Patches-716969 ] fix thread bug in 2.2.2 and later Message-ID: Patches item #716969, was opened at 2003-04-07 16:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Klanderman (gregklanderman) Assigned to: Nobody/Anonymous (nobody) Summary: fix thread bug in 2.2.2 and later Initial Comment: in at least 2.2.2 and later (and probably earlier), the pthread implementation of thread.create_new_thread() is no longer handling the inability to create a new thread properly - it returns as though a new thread was created but in fact no thread was started. the bug seems to have been introduced here: Python/thread_pthread.h: > revision 2.35 > date: 2001/10/16 21:13:49; author: gvanrossum; ... > Partial patch from SF #452266, by Jason Petrone. > > This changes Pythread_start_thread() to return the thread ID, or -1 > for an error. (It's technically an incompatible API change, but I > doubt anyone calls it.) it apepars that the same bug may exist in the nt and solaris thread implementations though i was not able to test this hypothesis. here's a test script to run import thread, time, traceback def foo(i): time.sleep(10) print "thread %3d finished" % (i,) for i in range(3000): try: v = thread.start_new_thread(foo, (i,)) print "started thread %d --> %s" % (i, v) except thread.error, e: print "thread limit reached: %d" % (i,) traceback.print_exc() break time.sleep(30) you'll notice that on 1.5.2, after around 256 threads are created, an error is raised, and that all the threads prior to this then complete a few seconds later. in 2.2.2, an error is never raised, but only about 1000 threads have actually been successfully created. patch is attached. i've taken the liberty of renaming one of the variables for clarity. greg gak@klanderman.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 From noreply@sourceforge.net Mon Apr 7 22:44:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 14:44:45 -0700 Subject: [Patches] [ python-Patches-714348 ] Guard against segfaults in debug code Message-ID: Patches item #714348, was opened at 2003-04-02 22:14 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714348&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mark Hammond (mhammond) >Assigned to: Mark Hammond (mhammond) Summary: Guard against segfaults in debug code Initial Comment: When dumping invalid objects, we may as well avoid segfaults if possible. This allows us to extract as much information as possible before dieing, which may be handy in release builds etc. Trivial patch just to get started (as I actually hit this block!). Assign back if you are OK with it, or I will be OK with you not wanting to start this slippery slope. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-04-07 17:44 Message: Logged In: YES user_id=31435 Do you think this helps? I'm OK with it either way. Normally, this routine doesn't exist in a release build, and in the debug build if we didn't segfault we'd end up calling Py_FatalError() after it returned. BTW. since we're on Windows, would it be simpler to call the Win32 IsBadReadPtr()? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-04-02 22:16 Message: Logged In: YES user_id=14198 Attaching patch. It indents a couple of blocks, so FYI, a --ignore-all-space diff is: RCS file: /cvsroot/python/python/dist/src/Objects/obmalloc.c,v retrieving revision 2.50 diff -w -r2.50 obmalloc.c 1126a1127 > int tail_reachable = 0; /* can we dereference tail without segfault */ 1163a1165,1175 > #ifdef MS_WINDOWS > _try { > #endif /* MS_WINDOWS */ > tail_reachable = *tail ? 1 : 1; /* if we don't die, it is reachable! */ > #ifdef MS_WINDOWS > } _except(1) { > /* tail_reachable remains 0 */ > } > #endif /* MS_WINDOWS */ > > if (tail_reachable) { 1185a1198,1200 > } else { > fprintf(stderr, "INVALID\n"); > } 1197c1212 < if (q < tail) { --- > if (q < tail && tail_reachable) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714348&group_id=5470 From noreply@sourceforge.net Tue Apr 8 00:16:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 16:16:31 -0700 Subject: [Patches] [ python-Patches-717102 ] Fetch oparg with unsigned short Message-ID: Patches item #717102, was opened at 2003-04-07 18:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717102&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Tim Peters (tim_one) Summary: Fetch oparg with unsigned short Initial Comment: This is faster than retrieving two unsigned chars and assembling them with a shift and bitwise-or. Wrapped in a conditional macro because the transformation only works for little endian architectures. Tim, is there something better than MS_WINDOWS to test for a little endian environment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717102&group_id=5470 From noreply@sourceforge.net Tue Apr 8 01:50:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 17:50:12 -0700 Subject: [Patches] [ python-Patches-717152 ] has_function() method for CCompiler Message-ID: Patches item #717152, was opened at 2003-04-07 19:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717152&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: A.M. Kuchling (akuchling) Summary: has_function() method for CCompiler Initial Comment: On the psycopg mailing list, Federico bemoaned the problem figuring out via distutils if a particular platform contains an implementation for asprintf(). I wrote the attached method as a starting point for such functionality in distutils. It's been barely tested at all, but seems to me to be a reasonable addition to the set of stuff distutils can check for. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717152&group_id=5470 From noreply@sourceforge.net Tue Apr 8 01:56:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 17:56:14 -0700 Subject: [Patches] [ python-Patches-717152 ] has_function() method for CCompiler Message-ID: Patches item #717152, was opened at 2003-04-07 19:50 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717152&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: A.M. Kuchling (akuchling) Summary: has_function() method for CCompiler Initial Comment: On the psycopg mailing list, Federico bemoaned the problem figuring out via distutils if a particular platform contains an implementation for asprintf(). I wrote the attached method as a starting point for such functionality in distutils. It's been barely tested at all, but seems to me to be a reasonable addition to the set of stuff distutils can check for. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-04-07 19:56 Message: Logged In: YES user_id=44345 Also note a number of known nits: * it doesn't yet clean up after itself * it doesn't yet suppress messages to stderr * I haven't tested it in any but the simplest of cases ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717152&group_id=5470 From noreply@sourceforge.net Tue Apr 8 02:32:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 18:32:21 -0700 Subject: [Patches] [ python-Patches-717102 ] Fetch oparg with unsigned short Message-ID: Patches item #717102, was opened at 2003-04-07 19:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717102&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Fetch oparg with unsigned short Initial Comment: This is faster than retrieving two unsigned chars and assembling them with a shift and bitwise-or. Wrapped in a conditional macro because the transformation only works for little endian architectures. Tim, is there something better than MS_WINDOWS to test for a little endian environment? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-04-07 21:32 Message: Logged In: YES user_id=31435 You could write an autoconfig test to determine the endianness of the box, and then builds for non-Unix platforms would need to define the symbol (or not) by hand. We do that for lots of stuff already. In fact, I'm pretty sure autoconf already generates endian info. I discourage using this, though. HW-related ifdefs are a nightmare to maintain over time, and an optimizing compiler should be smart enough to do this transformation on its own -- provided it's really a win on the platform at hand. The architecture trend is toward penalizing unaligned access of all kinds, and if you didn't test this under every flavor of Pentium that has been, and ever will be, released, you don't know all its effects on speed. That's why HW- related ifdefs become a nightmare over time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717102&group_id=5470 From noreply@sourceforge.net Tue Apr 8 05:01:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 21:01:14 -0700 Subject: [Patches] [ python-Patches-713824 ] Unicode Codecs for CJK Encodings Message-ID: Patches item #713824, was opened at 2003-04-02 20:23 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713824&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode Codecs for CJK Encodings Initial Comment: This patch includes the python unicode codecs for the following encodings: _ja_codecs: shiftjis cp932 euc_jp _ko_codecs: euc_kr cp949 _zh_CN_codecs: gb2312 cp936 gb18030 _zh_TW_codecs: big5 cp950 With this codecs, the Python can be a legal software in China. :) (gb18030 is a mandatory standard.) i386 stripped ELF size: 58416 _ja_codecs.so 59280 _ko_codecs.so 82992 _zh_CN_codecs.so 58224 _zh_TW_codecs.so powerpc unstripped Mach-O size: 88676 _ja_codecs.so 88096 _ko_codecs.so 111336 _zh_CN_codecs.so 86184 _zh_TW_codecs.so ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713824&group_id=5470 From noreply@sourceforge.net Tue Apr 8 06:56:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 22:56:53 -0700 Subject: [Patches] [ python-Patches-716969 ] fix thread bug in 2.2.2 and later Message-ID: Patches item #716969, was opened at 2003-04-07 22:04 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Klanderman (gregklanderman) >Assigned to: Martin v. Löwis (loewis) Summary: fix thread bug in 2.2.2 and later Initial Comment: in at least 2.2.2 and later (and probably earlier), the pthread implementation of thread.create_new_thread() is no longer handling the inability to create a new thread properly - it returns as though a new thread was created but in fact no thread was started. the bug seems to have been introduced here: Python/thread_pthread.h: > revision 2.35 > date: 2001/10/16 21:13:49; author: gvanrossum; ... > Partial patch from SF #452266, by Jason Petrone. > > This changes Pythread_start_thread() to return the thread ID, or -1 > for an error. (It's technically an incompatible API change, but I > doubt anyone calls it.) it apepars that the same bug may exist in the nt and solaris thread implementations though i was not able to test this hypothesis. here's a test script to run import thread, time, traceback def foo(i): time.sleep(10) print "thread %3d finished" % (i,) for i in range(3000): try: v = thread.start_new_thread(foo, (i,)) print "started thread %d --> %s" % (i, v) except thread.error, e: print "thread limit reached: %d" % (i,) traceback.print_exc() break time.sleep(30) you'll notice that on 1.5.2, after around 256 threads are created, an error is raised, and that all the threads prior to this then complete a few seconds later. in 2.2.2, an error is never raised, but only about 1000 threads have actually been successfully created. patch is attached. i've taken the liberty of renaming one of the variables for clarity. greg gak@klanderman.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 From noreply@sourceforge.net Tue Apr 8 06:59:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 22:59:21 -0700 Subject: [Patches] [ python-Patches-713645 ] freeze fails when extensions_win32.ini is missing Message-ID: Patches item #713645, was opened at 2003-04-02 03:17 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713645&group_id=5470 Category: Demos and tools Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: David Schnepper (dschnepper) >Assigned to: Martin v. Löwis (loewis) Summary: freeze fails when extensions_win32.ini is missing Initial Comment: Incorrect variable referenced during print of warning message when extensions_win32.ini is missing. Test: import checkextensions_win32 reload(checkextensions_win32) # for testing import os os.rename("extensions_win32.ini", "tmp.ini") try: checkextensions_win32.checkextensions([], [], "any") print "PASS: checkextensions with missing extensions_win32.ini" finally: os.rename("tmp.ini", "extensions_win32.ini") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713645&group_id=5470 From noreply@sourceforge.net Tue Apr 8 06:59:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 22:59:45 -0700 Subject: [Patches] [ python-Patches-714957 ] Document freeze process in PC/config.c Message-ID: Patches item #714957, was opened at 2003-04-04 01:43 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714957&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 2 Submitted By: David Schnepper (dschnepper) >Assigned to: Martin v. Löwis (loewis) Summary: Document freeze process in PC/config.c Initial Comment: Resolved an XXX comment in PC/config.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714957&group_id=5470 From noreply@sourceforge.net Tue Apr 8 07:02:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 23:02:25 -0700 Subject: [Patches] [ python-Patches-713428 ] Fixes for 'commands' module on win32 Message-ID: Patches item #713428, was opened at 2003-04-01 19:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Warnes (warnes) >Assigned to: Martin v. Löwis (loewis) Summary: Fixes for 'commands' module on win32 Initial Comment: Currently the 'commands' module is provided with python on Win32 systems, but does not function properly. (The library reference says it is only available on Unix). The commands module provides 3 functions: getoutput(cmd) returns output generated by executing 'cmd' in a shell getstatusoutput(cmd) returns (status,output) generated by executing 'cmd' in a shell getstatus(file) returns output of "ls -ld file" Below is a simple patch which enables 'getoutput' and 'getstatusoutut' to work properly on Win32. Since 'getstatusfile' only makes sense on Unix, the patch prevents it from being defined on Win32. The current behavior is maintained on all other platforms. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-08 08:02 Message: Logged In: YES user_id=21627 Can you please resubmit this as a unified diff? Also, please make sure you don't incude white-space only changes: Your patch says that it changes all lines, just because you add a CR at the end of every line (so either convert the modified file to Unix conventions, or the original file to Windows conventions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470 From noreply@sourceforge.net Tue Apr 8 07:03:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Apr 2003 23:03:26 -0700 Subject: [Patches] [ python-Patches-711902 ] Cause pydoc to show data descriptor __doc__ strings Message-ID: Patches item #711902, was opened at 2003-03-29 20:01 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711902&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Martin v. Löwis (loewis) Summary: Cause pydoc to show data descriptor __doc__ strings Initial Comment: Data descriptors (descriptors having both a __get__ and a __set__ method) often have __doc__ strings. Pydoc displays these for descriptors of type property, but not for other types (e.g., getsets). The attached patch will display __doc__ strings for data descriptors (if available) in the "Data and non-method functions" section of the type description. This patch is intended to be a minimal change. It's possible that inspect.classify_class_attrs should return a new kind for data descriptors (or possibly the "property" kind should include all data descriptors (not just properties)), which could then be handled differently from other non-classified data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711902&group_id=5470 From rnyjtjy@hotbox.ru Tue Apr 8 09:13:22 2003 From: rnyjtjy@hotbox.ru (=?windows-1251?b?0/fl4e376SDk5e/g8PLg7OXt8g==?=) Date: Tue, 08 Apr 2003 08:13:22 +0000 Subject: [Patches] =?windows-1251?b?xOv/IOTo8OXq8u7w4CDv7iDs4PDq5fLo7ePzLiAgZA==?= Message-ID: <200304080813.XUS7F7HP@oekmhreyav.com>  ñâîåé êàæäîäíåâíîé ðàáîòå ÂÛ ÷àñòî çàíèìàåòåñü íå òîëüêî ïðîâåäåíèåì ìàðêåòèíãîâûõ èññëåäîâàíèé, íî è îöåíêîé êîíêóðåíòîñïîñîáíîñòè ïðåäïðèÿòèÿ, îðãàíèçàöèåé ñáûòîâîé ñåòè, óïðàâëåíèåì öåíîé, îðãàíèçàöèåé ìåðîïðèÿòèé ïî ïðîäâèæåíèþ êîìïàíèè. ×àñòî íà ïëå÷è óïðàâëÿþùèõ ìàðêåòèíãîì ëîæàòñÿ îáÿçàííîñòè, ïðÿìûì ñëåäñòâèåì êîòîðûõ ÿâëÿåòñÿ óâåëè÷åíèå îáúåìà ïðîäàæ, óëó÷øåíèå èìèäæà êîìïàíèè. Ôàêòè÷åñêè, èìåííî Âû, êàê ìàðêåòîëîã, îïðåäåëÿåòå äîëãîñðî÷íóþ ñòðàòåãèþ ðàçâèòèÿ áèçíåñà.  öåëÿõ ðàçðàáîòêè îïòèìàëüíîãî ó÷åáíîãî êóðñà áûë ïðîâåäåí îïðîñ ðóêîâîäèòåëåé ìàðêåòèíãîâûõ ñëóæá, êîòîðûé ïîçâîëèë âûÿâèòü îáùèå äëÿ âñåõ ôóíêöèè è îáÿçàííîñòè. Äëÿ ðåøåíèÿ êîíêðåòíûõ çàäà÷, ñòîÿùèõ ïåðåä êàæäûì äèðåêòîðîì ïî ìàðêåòèíãó, ìû ñîáðàëè ïðèêëàäíûå òåõíîëîãèè è èíñòðóìåíòû, îáúåäèíèâ èõ â ïðîãðàììó ÍÅÄÅËÜÍÎÃÎ ÑÏÅÖÈÀËÈÇÈÐÎÂÀÍÍÎÃÎ ÑÅÌÈÍÀÐÀ-ÏÐÀÊÒÈÊÓÌÀ: ÏÐÀÊÒÈ×ÅÑÊÈÉ ÊÓÐÑ ÄËß ÄÈÐÅÊÒÎÐÀ ÏÎ ÌÀÐÊÅÒÈÍÃÓ 14 - 20 ÀÏÐÅËß 2003 ãîäà  ïðîãðàììå êóðñà: - àóäèò ìàðêåòèíãà ïðåäïðèÿòèè - êðèòåðèè ýôôåêòèâíîñòè ôóíêöèîíèðîâàíèÿ ìàðêåòèíãîâîé ñëóæáû - óïðàâëåíèå òåêóùåé ìàðêåòèíãîâîé äåÿòåëüíîñòüþ - ðàçðàáîòêà ìàðêåòèíãîâîãî ïëàíà - îöåíêà êîíêóðåíòîñïîñîáíîñòè ïðåäïðèÿòèÿ - óïðàâëåíèå öåíîé, öåíîâàÿ ïîëèòèêà - îðãàíèçàöèÿ ñáûòîâîé ñåòè - áþäæåòèðîâàíèå â ñëóæáå ìàðêåòèíãà - ìàðêåòèíãîâûå èññëåäîâàíèÿ - ìàëîáþäæåòíîå ïðîäâèæåíèå - ïîçèöèîíèðîâàíèå (ñîçäàíèå óñòîé÷èâîé ïîçèöèè íà ðûíêå) Äàííûé êóðñ íîñèò èñêëþ÷èòåëüíî ïðàêòè÷åñêóþ íàïðàâëåííîñòü.  ïðîöåññå îáó÷åíèÿ ó÷àñòíèêè ïîëó÷àò êîíêðåòíûå ñïîñîáû, òåõíîëîãèè è ìåòîäèêè îïòèìèçà- öèè ìàðêåòèíãîâîé äåÿòåëüíîñòè. Ïîìèìî ìåòîäè÷åñêîãî ïîñîáèÿ äëÿ ðàáîòû íà ñåìèíàðå è ðàáî÷åé òåòðàäè ó÷àñòíèêè ïîëó÷àò: íàáîð êíèã "Áèáëèîòåêà ìàðêåòîëîãà", ñîñòàâëåííûé ïî ðåêîìåíäàöèÿì àâòîðîâ. ×òîáû ïîëó÷èòü ïîäðîáíóþ èíôîðìàöèþ èëè ïðîãðàììó êóðñà, ïîçâîíèòå ïî òåë. (095) 258-51-85 jrltnwr zkis From noreply@sourceforge.net Tue Apr 8 16:44:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Apr 2003 08:44:38 -0700 Subject: [Patches] [ python-Patches-717575 ] allow timeit to see your globals() Message-ID: Patches item #717575, was opened at 2003-04-08 10:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717575&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Tim Peters (tim_one) Summary: allow timeit to see your globals() Initial Comment: This patch allows the timeit caller to specify the globals() for the code snippet being timed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717575&group_id=5470 From gkkq@mail.ru Wed Apr 9 07:08:51 2003 From: gkkq@mail.ru (=?windows-1251?b?0/fl4e376SDE5e/g8PLg7OXt8g==?=) Date: Wed, 09 Apr 2003 06:08:51 +0000 Subject: [Patches] =?windows-1251?b?09HPxdjN28Ug0sXVzcjKyCDPxdDFw87CztDOwiAgaQ==?= Message-ID: <200304090608.FBKRG5LP@gsstnnzfzz.com> Óâàæàåìûå ãîñïîäà! Ïðèãëàøàåì Âàñ ðàññìîòðåòü âîçìîæíîñòü ó÷àñòèÿ â ñïåöèàëüíîé ïðîãðàììå ïî øèðîêîìó ñïåêòðó ïåðåãîâîðíûõ ïðèåìîâ êîòîðàÿ áóäåò èíòåðåñíà â ïåðâóþ î÷åðåäü îïûòíûì ìåíåäæåðàì è òîï-ïåðåãîâîðùèêàì "ÓÑÏÅØÍÛÅ ÒÅÕÍÈÊÈ ÏÅÐÅÃÎÂÎÐÎÂ" Ñåìèíàð ñîñòîèòñÿ â ã. Êèåâå 19-20 àïðåëÿ 2003ã. Öåëü ñåìèíàðà: Íàó÷èòü ó÷àñòíèêîâ äîñòèãàòü óñïåõà â ëþáûõ ïåðåãîâîðàõ. Ëåãêàÿ, íî ñâîåîáðàçíàÿ êóõíÿ îñîáûõ êîììóíèêàòèâíûõ ïðèåìîâ ÷àñòî îêàçûâàåòñÿ èìåííî òåì, ÷åãî íå õâàòàåò äëÿ ïîñòðîåíèÿ ýôôåêòèâíîé ñèñòåìû âçàèìîîòíîøåíèé ñ êëèåíòóðîé. Íå ìåíüøóþ ïîëüçó ïîëó÷àò ðóêîâîäèòåëè, êîòîðûì ïî äîëãó ñëóæáû ïðèõîäèòñÿ ïîñòîÿííî âåñòè ïåðåãîâîðû íà ðàçíûõ óðîâíÿõ. Ñîäåðæàíèå ñåìèíàðà: ÂÎÇÌÎÆÍÎÑÒÈ ÏÅÐÅÃÎÂÎÐÍÛÕ ÒÅÕÍÎËÎÃÈÉ - Ðàáîòà ñ ìîòèâàìè. - Ñïåöèàëüíûå ìåòîäû. ÂÍÓØÅÍÈÅ - Ðå÷åâûå òåõíèêè ìàíèïóëÿöèè ñîçíàíèåì îïïîíåíòà. - Ðå÷åâûå ìîäàëüíîñòè è êîíòðîëü ïðàâäèâîñòè. ÒÅÕÍÎËÎÃÈß ÓÁÅÆÄÅÍÈß - Öåëè è îñîáåííîñòè óáåæäåíèÿ. - Ïëàíèðîâàíèå óáåæäåíèÿ. - Âûáîð àðãóìåíòàöèè. - Ïðàâèëà óáåæäåíèÿ. - Ñõåìà óáåæäåíèÿ. - Âàæíûå ïðèíöèïû. - Ñïîñîáû äîêàçàòåëüñòâà. - Îïðîâåðæåíèå. - Ñïîñîáû îïðîâåðæåíèÿ. - Ìåòîäû óáåæäåíèÿ. ÎÑÎÁÎ ÒßÆÅËÛÅ ÏÅÐÅÃÎÂÎÐÛ - Àíòèïåðåãîâîðíûå ñòðàòåãèè. - Èãðà íà êîíôëèêòîãåíàõ. - Íàèáîëåå ðàñïðîñòðàíåííûå óëîâêè, îñëîæíÿþùèå ïåðåãîâîðû. - Äèñêóññèîííûå àòàêè è êîíòðàòàêè. - Èíûå ñöåíàðèè. ÂÎÇÐÀÆÅÍÈß È ÇÀÌÅ×ÀÍÈß - Ðàñïðîñòðàíåííûå âèäû çàìå÷àíèé. - Íåéòðàëèçàöèÿ çàìå÷àíèé. - Ïðàâèëà ðàáîòû ñ îòâîäîì âîçðàæåíèé - êëàññèôèêàöèÿ è àëãîðèòìû. Àâòîð ñåìèíàðà: Äåðåâèöêèé Àëåêñàíäð Àíàòîëüåâè÷ - áèçíåñ-òðåíåð-ýêñïåðò ïî ïðîäàæàì è ïåðåãîâîðàì. Àâòîð êíèã, îñíîâàííûõ íà ñîáñòâåííîì áîãàòîì îïûòå ïðîäàæ: "Øïàðãàëêà àãåíòà", "Àðò-Øëàíã èëè Ïðàêòèêà êîíòð-ìåíåäæìåíòà", "Êóðñ àãåíòóðû (ìèðîâîé îïûò êîììèâîÿæà)", "Îõîòà íà ïîêóïàòåëÿ". Òðåíèíãè, ñåìèíàðû è àäàïòèíãè Äåðåâèöêîãî ïîëüçóþòñÿ îãðîìíîé ïîïóëÿðíîñòüþ â Óêðàèíå, Ðîññèè, Áåëîðóññèè ñ 1994 ã. Ðåãëàìåíò ïðîâåäåíèÿ: Ñåìèíàð ïðîõîäèò äâà äíÿ ñ 10.00 äî 18.00 ñ ïåðåðûâàìè íà îáåä è êîôå-ïàóçû. Ñòîèìîñòü ó÷àñòèÿ â îòêðûòîé 16-÷àñîâîé ïðîãðàììå â ã. Êèåâå äëÿ îäíîãî ÷åëîâåêà ñîñòàâëÿåò 180 ó.å.  ñòîèìîñòü îáó÷åíèÿ âõîäèò ìåòîäè÷åñêèé ìàòåðèàë, êîôå-ïàóçû, îáåä. Êîíòàêòíàÿ èíôîðìàöèÿ: Åñëè Âû ðåøèëè ïðèíÿòü ó÷àñòèå â ñåìèíàðå, ïîæàëóéñòà, çâîíèòå ïî òåë. (044) 4597457 è çàêàçûâàéòå áðîíü íà ó÷àñòèå. Æäåì Âàñ è æåëàåì Óñïåøíûõ ïåðåãîâîðîâ! Âàø àäðåñ ïîëó÷åí èç ñâîáîäíûõ èñòî÷íèêîâ. Îòïèñàòüñÿ ìîæíî registr_m@ua.fm From noreply@sourceforge.net Wed Apr 9 08:00:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 00:00:40 -0700 Subject: [Patches] [ python-Patches-718027 ] Patch to distutils doc for metadata explanation Message-ID: Patches item #718027, was opened at 2003-04-09 17:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718027&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to distutils doc for metadata explanation Initial Comment: The attached patch adds additional information to the explanation about distutils metadata. It should be applied to the current (version 1.52) CVS HEAD documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718027&group_id=5470 From noreply@sourceforge.net Wed Apr 9 08:45:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 00:45:33 -0700 Subject: [Patches] [ python-Patches-718049 ] Setting exe_extension for cygwin Message-ID: Patches item #718049, was opened at 2003-04-09 16:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: Setting exe_extension for cygwin Initial Comment: On cygwin, the setup.py script uses unixccompiler.py for compiling and linking C extensions. The unixccompiler.py script assumes that executables do not get special extensions, which makes sense for Unix. However, on Cygwin, executables get an .exe extension. This causes a problem during the configuration step (python setup.py config), in which some temporary executables may be generated. As unixccompiler.py does not know about the .exe extension, distutils fails to clean up after itself: it does not remove _configtest.exe but tries to remove _configtest instead. The attached patch to unixccompiler.py sets the correct exe_extension for cygwin by checking if sys.platform is 'cygwin'. With this patch, distutils cleans up after itself correctly. Michiel de Hoon University of Tokyo, Human Genome Center. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 From noreply@sourceforge.net Wed Apr 9 15:44:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 07:44:13 -0700 Subject: [Patches] [ python-Patches-718286 ] DESTDIR variable patch Message-ID: Patches item #718286, was opened at 2003-04-09 16:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718286&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: wrobell (wrobell) Assigned to: Nobody/Anonymous (nobody) Summary: DESTDIR variable patch Initial Comment: This patch adds DESTDIR variable feature known from automake generated Makefile's. It simplifies packaging task and is useful for distro (i.e. PLD, RedHat, Debian) developers. For example, for rpm, one can specify in %install section: make install DESTDIR=$RPM_BUILD_ROOT then Python will be installed under $RPM_BUILD_ROOT directory. Otherwise distro developer is forced to specify: make install \ BINDIR=$RPM_BUILD_ROOT%{_bindir} \ SCRIPTDIR=$RPM_BUILD_ROOT%{_libdir} \ LIBDIR=$RPM_BUILD_ROOT%{_libdir} \ MANDIR=$RPM_BUILD_ROOT%{_mandir} \ INCLUDEDIR=$RPM_BUILD_ROOT%{_includedir} \ CONFINCLUDEDIR=$RPM_BUILD_ROOT%{_includedir} The patch has been tested on Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718286&group_id=5470 From noreply@sourceforge.net Wed Apr 9 15:46:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 07:46:47 -0700 Subject: [Patches] [ python-Patches-718286 ] DESTDIR variable patch Message-ID: Patches item #718286, was opened at 2003-04-09 16:44 Message generated for change (Comment added) made by wrobell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718286&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: wrobell (wrobell) Assigned to: Nobody/Anonymous (nobody) Summary: DESTDIR variable patch Initial Comment: This patch adds DESTDIR variable feature known from automake generated Makefile's. It simplifies packaging task and is useful for distro (i.e. PLD, RedHat, Debian) developers. For example, for rpm, one can specify in %install section: make install DESTDIR=$RPM_BUILD_ROOT then Python will be installed under $RPM_BUILD_ROOT directory. Otherwise distro developer is forced to specify: make install \ BINDIR=$RPM_BUILD_ROOT%{_bindir} \ SCRIPTDIR=$RPM_BUILD_ROOT%{_libdir} \ LIBDIR=$RPM_BUILD_ROOT%{_libdir} \ MANDIR=$RPM_BUILD_ROOT%{_mandir} \ INCLUDEDIR=$RPM_BUILD_ROOT%{_includedir} \ CONFINCLUDEDIR=$RPM_BUILD_ROOT%{_includedir} The patch has been tested on Linux. ---------------------------------------------------------------------- >Comment By: wrobell (wrobell) Date: 2003-04-09 16:46 Message: Logged In: YES user_id=387193 Adding the patch due to current sf policy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718286&group_id=5470 From noreply@sourceforge.net Wed Apr 9 15:49:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 07:49:56 -0700 Subject: [Patches] [ python-Patches-718299 ] test uploading file on submission Message-ID: Patches item #718299, was opened at 2003-04-09 10:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718299&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test uploading file on submission Initial Comment: test ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718299&group_id=5470 From noreply@sourceforge.net Wed Apr 9 15:50:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 07:50:37 -0700 Subject: [Patches] [ python-Patches-718299 ] test uploading file on submission Message-ID: Patches item #718299, was opened at 2003-04-09 10:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718299&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test uploading file on submission Initial Comment: test ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 10:50 Message: Logged In: YES user_id=33168 Yeah, it worked, closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718299&group_id=5470 From noreply@sourceforge.net Wed Apr 9 17:23:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 09:23:14 -0700 Subject: [Patches] [ python-Patches-709178 ] remove -static option from cygwinccompiler Message-ID: Patches item #709178, was opened at 2003-03-24 17:55 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709178&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Kabir Luebs (jkluebs) Assigned to: Jason Tishler (jlt63) Summary: remove -static option from cygwinccompiler Initial Comment: Currently, the cygwinccompiler.py compiler handling in distutils is invoking the cygwin and mingw compilers with the -static option. Logically, this means that the linker should choose to link to static libraries instead of shared/dynamically linked libraries. Current win32 binutils expect import libraries to have a .dll.a suffix and static libraries to have .a suffix. If -static is passed, it will skip the .dll.a libraries. This is pain if one has a tree with both static and dynamic libraries using this naming convention, and wish to use the dynamic libraries. The -static option being passed in distutils is to get around a bug in old versions of binutils where it would get confused when it found the DLLs themselves. The decision to use static or shared libraries is site or package specific, and should be left to the setup script or to command line options. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-04-09 08:23 Message: Logged In: YES user_id=86216 Checked in as Lib/distutils/cygwinccompiler.py 1.22. Sorry, for sluggish response time. I will create separate SF patches for the forthcoming, related patches. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-04-01 10:11 Message: Logged In: YES user_id=86216 Martin, Thanks for your approval. I would like to check in the changes in parts. For example: 1. John's remove -static patch. 2. my get_versions() fix patch 3. my -shared patch 4. etc. In this way, I can more easily roll back if I goof. Can I just attach more patches to this one? Or, should I create a new SF patch for each of my patches? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 12:33 Message: Logged In: YES user_id=21627 jlt63: Your proposed changes all sound fine. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-31 08:02 Message: Logged In: YES user_id=86216 jkluebs> I can help with testing. I have access to W2K jkluebs> and Win98 (ugh) boxen. I don't mind jkluebs> installing a few older toolchains if you jkluebs> think that's necessary. Thanks for the offer. I'm set up for the current Cygwin and Mingw tool chains. Let's wait to see if testing with older ones is necessary. jkluebs> I think any C/C++ python extension using jkluebs> plain distutils (no fancy hacks added on) and jkluebs> has one or more DLL dependencies is a good jkluebs> test case. Can you point me to one that builds OOTB under Python 2.2.2? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-31 07:58 Message: Logged In: YES user_id=86216 loewis> I'm in favour of applying this patch, and loewis> also of patches that mandate recent Cygwin loewis> releases; I would like to apply an enhanced version of this patch. By enhanced, I mean using "gcc -shared" (no more dllwrap and gcc -mdll) and removing redundant gcc options, etc. Additionally, I would like to fix get_versions() so it can deal with versions that only have two components (e.g., 3.2) as opposed to requiring three (e.g. 2.95.3). Are these changes acceptable? loewis> if such patches are implemented, the minimum loewis> required Cygwin version should be stated loewis> somewhere. I propose that the currently available Cygwin and Mingw tool chains be that above stated minimum. Is this acceptable? Unfortunately, I have no idea where the above stated "somewhere" shoud be. ---------------------------------------------------------------------- Comment By: John Kabir Luebs (jkluebs) Date: 2003-03-28 14:31 Message: Logged In: YES user_id=87160 I can help with testing. I have access to W2K and Win98 (ugh) boxen. I don't mind installing a few older toolchains if you think that's necessary. I think any C/C++ python extension using plain distutils (no fancy hacks added on) and has one or more DLL dependencies is a good test case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-28 13:15 Message: Logged In: YES user_id=21627 I'm in favour of applying this patch, and also of patches that mandate recent Cygwin releases; if such patches are implemented, the minimum required Cygwin version should be stated somewhere. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-28 12:16 Message: Logged In: YES user_id=86216 John, would you be willing to help test or supply me with test cases? I have built exactly one Win32 extension. ---------------------------------------------------------------------- Comment By: John Kabir Luebs (jkluebs) Date: 2003-03-28 11:56 Message: Logged In: YES user_id=87160 The -mdll --entry DllMain@12 option is guarded for an old version of gcc that did not have the correct specs to accept -shared. I didn't touch it, even though it's crazy if anyone is using such an old and buggy toolchain. --shared and --dll are equivalent as far as ld is concerned. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-28 09:41 Message: Logged In: YES user_id=86216 Note that I only have minimal experience building Win32 extensions modules... This patch works "fine" with my *very* limited testing. Specifically, I successfully rebuilt the Win32 readline module with it applied. BTW, this area of Distutils probably should be revisited to bring it up to date. For example, the "-mdll --entry _DllMain@12" options could be replaced by "-shared". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 15:03 Message: Logged In: YES user_id=21627 Jason, can you take a look? If not, please unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709178&group_id=5470 From noreply@sourceforge.net Wed Apr 9 21:22:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 13:22:36 -0700 Subject: [Patches] [ python-Patches-718551 ] cygwinccompiler.get_versions() patch Message-ID: Patches item #718551, was opened at 2003-04-09 12:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718551&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: cygwinccompiler.get_versions() patch Initial Comment: The cygwinccompiler.get_versions() function only handles versions numbers of the form "x.y.z". The attached patch enhances get_versions() to handle "x.y" too (i.e., the ".z" is optional). This change causes the unnecessary "--entry _DllMain@12" link option to be suppressed for recent Cygwin and Mingw toolchains. Additionally, it directs recent Mingw toolchains to use gcc instead of dllwrap during linking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718551&group_id=5470 From noreply@sourceforge.net Wed Apr 9 21:30:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 13:30:56 -0700 Subject: [Patches] [ python-Patches-718551 ] cygwinccompiler.get_versions() patch Message-ID: Patches item #718551, was opened at 2003-04-09 12:22 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718551&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: cygwinccompiler.get_versions() patch Initial Comment: The cygwinccompiler.get_versions() function only handles versions numbers of the form "x.y.z". The attached patch enhances get_versions() to handle "x.y" too (i.e., the ".z" is optional). This change causes the unnecessary "--entry _DllMain@12" link option to be suppressed for recent Cygwin and Mingw toolchains. Additionally, it directs recent Mingw toolchains to use gcc instead of dllwrap during linking. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-04-09 12:30 Message: Logged In: YES user_id=86216 Checked in as Lib/distutils/cygwinccompiler.py 1.23. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718551&group_id=5470 From noreply@sourceforge.net Thu Apr 10 00:35:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 16:35:58 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Raymond Hettinger (rhettinger) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 19:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Thu Apr 10 05:50:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2003 21:50:37 -0700 Subject: [Patches] [ python-Patches-713428 ] Fixes for 'commands' module on win32 Message-ID: Patches item #713428, was opened at 2003-04-01 12:51 Message generated for change (Comment added) made by warnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Warnes (warnes) Assigned to: Martin v. Löwis (loewis) Summary: Fixes for 'commands' module on win32 Initial Comment: Currently the 'commands' module is provided with python on Win32 systems, but does not function properly. (The library reference says it is only available on Unix). The commands module provides 3 functions: getoutput(cmd) returns output generated by executing 'cmd' in a shell getstatusoutput(cmd) returns (status,output) generated by executing 'cmd' in a shell getstatus(file) returns output of "ls -ld file" Below is a simple patch which enables 'getoutput' and 'getstatusoutut' to work properly on Win32. Since 'getstatusfile' only makes sense on Unix, the patch prevents it from being defined on Win32. The current behavior is maintained on all other platforms. ---------------------------------------------------------------------- >Comment By: Gregory Warnes (warnes) Date: 2003-04-10 00:50 Message: Logged In: YES user_id=9316 Uploaded a revised patch file, as requested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-08 02:02 Message: Logged In: YES user_id=21627 Can you please resubmit this as a unified diff? Also, please make sure you don't incude white-space only changes: Your patch says that it changes all lines, just because you add a CR at the end of every line (so either convert the modified file to Unix conventions, or the original file to Windows conventions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470 From noreply@sourceforge.net Thu Apr 10 09:41:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 01:41:11 -0700 Subject: [Patches] [ python-Patches-713820 ] iconv_codec NG Message-ID: Patches item #713820, was opened at 2003-04-02 20:10 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713820&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: iconv_codec NG Initial Comment: This new implementation of iconv_codec resolves problems of current implementations below: - Having a reentrant context vulnerable point: encoder and/or decoder can be called multiple level in a same time when PEP293 codec error callback can call another iconv encoder session, too. So, all encode/ decode session must open their own iconv session but the current implementation shares the iconv session in the whole codec life time. - StreamReader can't work correctly: Because iconv keeps their context private, StreamReader can't work smart only with encode/decode function. Also, handling EINVAL and giving pending characters from previous data to error callback is very weak in the current implementation. - Putting a replacement character as just '?' is not safe for many encodings: On stateful encodings and non-byte stream encodings, we need to encode with iconv even for the replacement character. - Can't use encoding names including - and uppercases: Because codec subsystem changes - to _ and uppercases to lowercases, we can't pass them to the iconv_codec module without loss. For example, we need the next aliases to use CJK encodings on Sun iconv: # simplified chinese "euc_cn": "zh_CN.euc", "iso_2022_zh": "zh_CN.iso2022-CN", "gbk": "zh_CN.gbk", "cp935": "zh_CN-cp935", # traditional chinese "euc_tw": "zh_TW.euc", "iso_2022_tw": "zh_TW.iso2022-7", "big5": "zh_TW.big5", "cp937": "zh_TW.cp937", # japanese "iso_2022_jp": "ISO-2022-JP", "euc_jp": "eucJP", "shift_jis": "PCK", # korean "euc_kr": "ko_KR.euc", "iso_2022_kr": "ISO-2022-KR", "johab": "ko_KR.johap", "cp932": "ko_KR.cp932", "cp949": "ko_KR.cp949", - Can't try multiple unicode encodings or methods: On some iconv implementations like of HP-UX or Solaris, UCS2 -> ISO-8859-1 is available but UCS2 -> euc-kr isn't avaiable and only UTF-8 -> euc-kr is. And, many multibyte codecs such as CJK or iconv might have duplicated code for processing error callbacks and handling Streams. So, I splitted them out to another source. CJK and iconv codecs can share them just in source level by putting multibytecodec.c to Modules/ and linking the file to each of the codecs. Alternatively, if multibytecodec.c goes to Python/ and is linked to main python library, the codecs can be compiled and loaded by themselves. multibytecodec.c, the common multibyte codec framework can be used by any usual multibyte encodings. By using it, some codec writer can create a codec for his/her multibyte encodings without any care for handling error callbacks or implementing StreamReader structure. I wrote CJK codecs using it. and will submit a patch in an individual patch report. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-03 14:07 Message: Logged In: YES user_id=21627 Because of complaints about its brokenness, I had to revert the current iconv codec. It is extremely unlikely that such code will be added for Python 2.3. So please update this submission for the current CVS. There is no need to hurry, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713820&group_id=5470 From noreply@sourceforge.net Thu Apr 10 09:41:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 01:41:26 -0700 Subject: [Patches] [ python-Patches-718867 ] Fix reference leak for time.strptime Message-ID: Patches item #718867, was opened at 2003-04-10 01:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718867&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Fix reference leak for time.strptime Initial Comment: There is a missing Py_DECREF in for the time.strptime code (there is a call to PyImport_ImportModule() but not Py_DECREF() on the returned module object before the function returns). Ran the whole test suite with no incident. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718867&group_id=5470 From noreply@sourceforge.net Thu Apr 10 09:46:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 01:46:44 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Thu Apr 10 10:10:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 02:10:32 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Thu Apr 10 17:01:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 09:01:16 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Raymond Hettinger (rhettinger) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 11:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 18:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Thu Apr 10 17:19:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 09:19:17 -0700 Subject: [Patches] [ python-Patches-709178 ] remove -static option from cygwinccompiler Message-ID: Patches item #709178, was opened at 2003-03-24 17:55 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709178&group_id=5470 Category: Distutils and setup.py Group: None >Status: Open >Resolution: Accepted Priority: 5 Submitted By: John Kabir Luebs (jkluebs) Assigned to: Jason Tishler (jlt63) Summary: remove -static option from cygwinccompiler Initial Comment: Currently, the cygwinccompiler.py compiler handling in distutils is invoking the cygwin and mingw compilers with the -static option. Logically, this means that the linker should choose to link to static libraries instead of shared/dynamically linked libraries. Current win32 binutils expect import libraries to have a .dll.a suffix and static libraries to have .a suffix. If -static is passed, it will skip the .dll.a libraries. This is pain if one has a tree with both static and dynamic libraries using this naming convention, and wish to use the dynamic libraries. The -static option being passed in distutils is to get around a bug in old versions of binutils where it would get confused when it found the DLLs themselves. The decision to use static or shared libraries is site or package specific, and should be left to the setup script or to command line options. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-04-10 08:19 Message: Logged In: YES user_id=86216 After some more reflection, I would like to revert the original patch and apply my version, cygwinccompiler.py-shared.diff, instead. My reasons are the following: 1. support for older toolchains is retained 2. support for new toolchains (i.e., ld -shared) is added The goal of my approach is to avoid breaking older toolchains while adding better support for newer ones. John and/or anyone else, is my approach acceptable? Can you find any problems with it? Thanks. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-04-09 08:23 Message: Logged In: YES user_id=86216 Checked in as Lib/distutils/cygwinccompiler.py 1.22. Sorry, for sluggish response time. I will create separate SF patches for the forthcoming, related patches. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-04-01 10:11 Message: Logged In: YES user_id=86216 Martin, Thanks for your approval. I would like to check in the changes in parts. For example: 1. John's remove -static patch. 2. my get_versions() fix patch 3. my -shared patch 4. etc. In this way, I can more easily roll back if I goof. Can I just attach more patches to this one? Or, should I create a new SF patch for each of my patches? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 12:33 Message: Logged In: YES user_id=21627 jlt63: Your proposed changes all sound fine. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-31 08:02 Message: Logged In: YES user_id=86216 jkluebs> I can help with testing. I have access to W2K jkluebs> and Win98 (ugh) boxen. I don't mind jkluebs> installing a few older toolchains if you jkluebs> think that's necessary. Thanks for the offer. I'm set up for the current Cygwin and Mingw tool chains. Let's wait to see if testing with older ones is necessary. jkluebs> I think any C/C++ python extension using jkluebs> plain distutils (no fancy hacks added on) and jkluebs> has one or more DLL dependencies is a good jkluebs> test case. Can you point me to one that builds OOTB under Python 2.2.2? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-31 07:58 Message: Logged In: YES user_id=86216 loewis> I'm in favour of applying this patch, and loewis> also of patches that mandate recent Cygwin loewis> releases; I would like to apply an enhanced version of this patch. By enhanced, I mean using "gcc -shared" (no more dllwrap and gcc -mdll) and removing redundant gcc options, etc. Additionally, I would like to fix get_versions() so it can deal with versions that only have two components (e.g., 3.2) as opposed to requiring three (e.g. 2.95.3). Are these changes acceptable? loewis> if such patches are implemented, the minimum loewis> required Cygwin version should be stated loewis> somewhere. I propose that the currently available Cygwin and Mingw tool chains be that above stated minimum. Is this acceptable? Unfortunately, I have no idea where the above stated "somewhere" shoud be. ---------------------------------------------------------------------- Comment By: John Kabir Luebs (jkluebs) Date: 2003-03-28 14:31 Message: Logged In: YES user_id=87160 I can help with testing. I have access to W2K and Win98 (ugh) boxen. I don't mind installing a few older toolchains if you think that's necessary. I think any C/C++ python extension using plain distutils (no fancy hacks added on) and has one or more DLL dependencies is a good test case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-28 13:15 Message: Logged In: YES user_id=21627 I'm in favour of applying this patch, and also of patches that mandate recent Cygwin releases; if such patches are implemented, the minimum required Cygwin version should be stated somewhere. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-28 12:16 Message: Logged In: YES user_id=86216 John, would you be willing to help test or supply me with test cases? I have built exactly one Win32 extension. ---------------------------------------------------------------------- Comment By: John Kabir Luebs (jkluebs) Date: 2003-03-28 11:56 Message: Logged In: YES user_id=87160 The -mdll --entry DllMain@12 option is guarded for an old version of gcc that did not have the correct specs to accept -shared. I didn't touch it, even though it's crazy if anyone is using such an old and buggy toolchain. --shared and --dll are equivalent as far as ld is concerned. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-28 09:41 Message: Logged In: YES user_id=86216 Note that I only have minimal experience building Win32 extensions modules... This patch works "fine" with my *very* limited testing. Specifically, I successfully rebuilt the Win32 readline module with it applied. BTW, this area of Distutils probably should be revisited to bring it up to date. For example, the "-mdll --entry _DllMain@12" options could be replaced by "-shared". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 15:03 Message: Logged In: YES user_id=21627 Jason, can you take a look? If not, please unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709178&group_id=5470 From noreply@sourceforge.net Thu Apr 10 17:20:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 09:20:33 -0700 Subject: [Patches] [ python-Patches-718867 ] Fix reference leak for time.strptime Message-ID: Patches item #718867, was opened at 2003-04-10 03:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718867&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Fix reference leak for time.strptime Initial Comment: There is a missing Py_DECREF in for the time.strptime code (there is a call to PyImport_ImportModule() but not Py_DECREF() on the returned module object before the function returns). Ran the whole test suite with no incident. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 11:20 Message: Logged In: YES user_id=80475 Looks good. Applied to 2.136. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718867&group_id=5470 From noreply@sourceforge.net Thu Apr 10 17:22:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 09:22:42 -0700 Subject: [Patches] [ python-Patches-717102 ] Fetch oparg with unsigned short Message-ID: Patches item #717102, was opened at 2003-04-07 18:16 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717102&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Fetch oparg with unsigned short Initial Comment: This is faster than retrieving two unsigned chars and assembling them with a shift and bitwise-or. Wrapped in a conditional macro because the transformation only works for little endian architectures. Tim, is there something better than MS_WINDOWS to test for a little endian environment? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-07 20:32 Message: Logged In: YES user_id=31435 You could write an autoconfig test to determine the endianness of the box, and then builds for non-Unix platforms would need to define the symbol (or not) by hand. We do that for lots of stuff already. In fact, I'm pretty sure autoconf already generates endian info. I discourage using this, though. HW-related ifdefs are a nightmare to maintain over time, and an optimizing compiler should be smart enough to do this transformation on its own -- provided it's really a win on the platform at hand. The architecture trend is toward penalizing unaligned access of all kinds, and if you didn't test this under every flavor of Pentium that has been, and ever will be, released, you don't know all its effects on speed. That's why HW- related ifdefs become a nightmare over time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=717102&group_id=5470 From noreply@sourceforge.net Thu Apr 10 18:10:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 10:10:33 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Raymond Hettinger (rhettinger) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 19:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Thu Apr 10 18:14:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 10:14:58 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Raymond Hettinger (rhettinger) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 19:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Thu Apr 10 18:53:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 10:53:34 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Raymond Hettinger (rhettinger) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 12:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 12:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 11:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 18:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Thu Apr 10 19:20:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 11:20:48 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Raymond Hettinger (rhettinger) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 14:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 13:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 19:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Fri Apr 11 00:15:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 16:15:08 -0700 Subject: [Patches] [ python-Patches-719359 ] fix test_long failure on OSF/1 Message-ID: Patches item #719359, was opened at 2003-04-10 19:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=719359&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: fix test_long failure on OSF/1 Initial Comment: When using cc on OSF/1 V5.1, test_long fails because PyFloat_FromString() returns a ValueError instead of an OverflowError when the string is too long. The library appears to work a bit different. This patch fixes the problem. test test_long crashed -- exceptions.ValueError: invalid literal for float(): 12345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=719359&group_id=5470 From noreply@sourceforge.net Fri Apr 11 03:33:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2003 19:33:48 -0700 Subject: [Patches] [ python-Patches-706707 ] time.tzset standards compliance update Message-ID: Patches item #706707, was opened at 2003-03-19 23:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706707&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Stuart Bishop (zenzen) Assigned to: Neal Norwitz (nnorwitz) Summary: time.tzset standards compliance update Initial Comment: Update to configure.in and test_time.py to only use TZ environment variable format documented at http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 22:33 Message: Logged In: YES user_id=33168 Stuart, I saw the mails on py-dev, but am not sure about any conclusions. I tested the patch on Solaris 8 and Redhat 7.2. Solaris works (fails before the patch). Redhat fails with the patch, but I think it worked before the patch. I can check in to test on other architectures and back out if necessary. Let me know how to proceed. Thanks. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-04-06 22:19 Message: Logged In: YES user_id=46639 The bare except can go (just 'time.tzset()' without the try..except around it). The failure under Redhat is wierd - I can confirm that it works on a Redhat 7.2 box (as well as under OS X 10.2 and Solaris 2.8). The Australian timezone checks are testing that the timezone initialization stuff works in the southern hemisphere, and that time.altzone is being reset by tzset(). This will probably need to be taken to Python-dev unless you feel like applying the patch to HEAD and seeing who screams. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:46 Message: Logged In: YES user_id=33168 In the last chunk added, there is a bare except when calling time.tzset(). What are the possible exceptions? I don't want to have a bare except since this can mask a real error. The patch still fails for me on Linux (Redhat): * line 107: self.failUnless(time.tzname[1] == 'AEDT') - tzname has: ('AEST', 'AEST') * line 109: self.failUnlessEqual(time.daylight, 1) * line 111: self.failUnlessEqual(time.altzone, -39600) Haven't tried on other Unixes. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-03-27 15:12 Message: Logged In: YES user_id=46639 tzset3.diff is an updated diff against the CVS head. Fixes: -Don't test time.altzone for UTC - non-DST means altzone is undefined -Make sure dst timezone name is not the same as non-dst timezone name in TZ environment variable, to work around an apparent Solaris bug. -Extraneous cruft removed from test_time.py and configure.in - no more irrelevant comments. -More whitespace as per Tim's comments comments. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-21 16:28 Message: Logged In: YES user_id=33168 After patching, the test fails: File "/home/neal/build/python/2_3/Lib/test/test_time.py", line 115, in test_tzset self.failUnlessEqual(time.daylight,1) File "/home/neal/build/python/2.3/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 0 != 1 Also, why is the code commented out (via a string) on lines 120-144? Should these be removed? I see the comment about wallclock time, but don't understand why the code should be left in if we can't test it. I can understand a comment describing generally the issue. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-20 20:18 Message: Logged In: YES user_id=33168 I'll try to get to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-20 20:11 Message: Logged In: YES user_id=6380 Unassigning, as I won't hve time for this. But it is important - someone else should make sure this goes into 2.3b1! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-20 16:50 Message: Logged In: YES user_id=31435 Assigned to Guido, as I can't test it. Two notes: 1. Leaving commented-out code in config and the test suite doesn't appear to serve a purpose, although it will serve to confuse future readers ("why is this here? why is it commented out?"). 2. The Python style guide asks for a blank after commas in argument lists and tuples. We're not really in danger of stretching the screen here . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706707&group_id=5470 From noreply@sourceforge.net Fri Apr 11 08:17:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 00:17:05 -0700 Subject: [Patches] [ python-Patches-711002 ] new test_urllib and patch for found urllib bug Message-ID: Patches item #711002, was opened at 2003-03-27 13:09 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711002&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: new test_urllib and patch for found urllib bug Initial Comment: Free time at PyCon led to me writing a new test_urllib (happy, Raymond? =). Since I have no guarantee that there would be a net connection (and didn't want to use it without user permission since I view using the 'network' resource as using sockets and not the Net) I wrote all tests using temporary files. And do this found a bug, sort of. The docs and doc string for urlretrieve() says the second value from the returned tuple should be None when a local file is passed as an argument. Well, it wasn't; it was returning an rfc2822.Message object like it does for remote files. So I patched it to match the docs. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-04-11 00:17 Message: Logged In: YES user_id=357491 This is bloody wonderful. Not only is the uploaded test_urllib.py the tet_urllib currently in CVS (i.e., the old one), but I can't find my new version nor can I delete the bad version I have uploaded (why can't SF let the creator of a patch delete files?). At least my patch for urllib.py is still okay. Damn it, now I have to write test_urllib from scratch, *again*. At least I am getting version 2.0 done before 1.0 is even out the door <0.1 wink>. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-03-30 14:06 Message: Logged In: YES user_id=357491 I just noticed that Skip uploaded test_urllibnet.py to test timeouts by connecting to python.org . Is it okay to write tests that connect to the Net when the `network' resourse is enabled? If so then I can add network tests to test_urllib.py . Oh, and the beginning of the 2nd paragraph for my summary should have read "And I did find a bug, sort of" and not the mess of broken grammar rules as I initially typed it in. =) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711002&group_id=5470 From noreply@sourceforge.net Fri Apr 11 16:38:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 08:38:38 -0700 Subject: [Patches] [ python-Patches-706707 ] time.tzset standards compliance update Message-ID: Patches item #706707, was opened at 2003-03-19 23:57 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706707&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Stuart Bishop (zenzen) Assigned to: Neal Norwitz (nnorwitz) Summary: time.tzset standards compliance update Initial Comment: Update to configure.in and test_time.py to only use TZ environment variable format documented at http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-11 11:38 Message: Logged In: YES user_id=6380 Neal, I think you can check it in now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 22:33 Message: Logged In: YES user_id=33168 Stuart, I saw the mails on py-dev, but am not sure about any conclusions. I tested the patch on Solaris 8 and Redhat 7.2. Solaris works (fails before the patch). Redhat fails with the patch, but I think it worked before the patch. I can check in to test on other architectures and back out if necessary. Let me know how to proceed. Thanks. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-04-06 22:19 Message: Logged In: YES user_id=46639 The bare except can go (just 'time.tzset()' without the try..except around it). The failure under Redhat is wierd - I can confirm that it works on a Redhat 7.2 box (as well as under OS X 10.2 and Solaris 2.8). The Australian timezone checks are testing that the timezone initialization stuff works in the southern hemisphere, and that time.altzone is being reset by tzset(). This will probably need to be taken to Python-dev unless you feel like applying the patch to HEAD and seeing who screams. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:46 Message: Logged In: YES user_id=33168 In the last chunk added, there is a bare except when calling time.tzset(). What are the possible exceptions? I don't want to have a bare except since this can mask a real error. The patch still fails for me on Linux (Redhat): * line 107: self.failUnless(time.tzname[1] == 'AEDT') - tzname has: ('AEST', 'AEST') * line 109: self.failUnlessEqual(time.daylight, 1) * line 111: self.failUnlessEqual(time.altzone, -39600) Haven't tried on other Unixes. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-03-27 15:12 Message: Logged In: YES user_id=46639 tzset3.diff is an updated diff against the CVS head. Fixes: -Don't test time.altzone for UTC - non-DST means altzone is undefined -Make sure dst timezone name is not the same as non-dst timezone name in TZ environment variable, to work around an apparent Solaris bug. -Extraneous cruft removed from test_time.py and configure.in - no more irrelevant comments. -More whitespace as per Tim's comments comments. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-21 16:28 Message: Logged In: YES user_id=33168 After patching, the test fails: File "/home/neal/build/python/2_3/Lib/test/test_time.py", line 115, in test_tzset self.failUnlessEqual(time.daylight,1) File "/home/neal/build/python/2.3/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 0 != 1 Also, why is the code commented out (via a string) on lines 120-144? Should these be removed? I see the comment about wallclock time, but don't understand why the code should be left in if we can't test it. I can understand a comment describing generally the issue. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-20 20:18 Message: Logged In: YES user_id=33168 I'll try to get to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-20 20:11 Message: Logged In: YES user_id=6380 Unassigning, as I won't hve time for this. But it is important - someone else should make sure this goes into 2.3b1! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-20 16:50 Message: Logged In: YES user_id=31435 Assigned to Guido, as I can't test it. Two notes: 1. Leaving commented-out code in config and the test suite doesn't appear to serve a purpose, although it will serve to confuse future readers ("why is this here? why is it commented out?"). 2. The Python style guide asks for a blank after commas in argument lists and tuples. We're not really in danger of stretching the screen here . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706707&group_id=5470 From pmcptc@peterlink.ru Fri Apr 11 16:33:25 2003 From: pmcptc@peterlink.ru (=?windows-1251?b?0/fl4e376SD25e3y8A==?=) Date: Fri, 11 Apr 2003 15:33:25 +0000 Subject: [Patches] =?windows-1251?b?0+/w7vnl7e3g/yDx6PHy5ezgIO3g6+7j7u7h6+7m5e3o/yAgcw==?= Message-ID: <200304111533.6TG8REK8@lswgmvvhxi.com> Ïðèãëàøàåì Âàñ ïðèíÿòü ó÷àñòèå â ñåìèíàðå "Óïðîùåííàÿ ñèñòåìà íàëîãîîáëîæåíèÿ äëÿ ìàëûõ ïðåäïðèÿòèé. Ïî èòîãàì 1-ãî êâàðòàëà ïðèìåíåíèÿ ÓÑÍ" 17 àïðåëÿ 2003 ã. êîíòàêòíûå òåëåôîíû 207-26-21, 789-81-90, 772-92-46 1. Óïðîùåííàÿ ñèñòåìà íàëîãîîáëîæåíèÿ (ÓÑÍ). Íàëîãè è ñáîðû, èñ÷èñëÿåìûå ïðè ÓÑÍ; â êàêèõ ñëó÷àÿõ îðãàíèçàöèè, ïåðåøåäøèå íà ÓÑÍ, ÿâëÿþòñÿ íàëîãîâûìè àãåíòàìè ïî ÍÄÑ, íàëîãó íà ïðèáûëü è äðóãèì íàëîãàì; ïðåèìóùåñòâà è íåäîñòàòêè íîâîé óïðîùåííîé ñèñòåìû íàëîãîîáëîæåíèÿ. 2. Äîõîäû: ñîñòàâ, äîêóìåíòèðîâàíèå, ïðèçíàíèå, îòðàæåíèå â êíèãå è äðóãèõ íàëîãîâûõ ðåãèñòðàõ. Äîõîäû, íå ó÷èòûâàåìûå äëÿ íàëîãîîáëîæåíèÿ. 3. Ðàñõîäû: ñîñòàâ, äîêóìåíòèðîâàíèå, ïðèçíàíèå, îòðàæåíèå â êíèãå è äðóãèõ íàëîãîâûõ ðåãèñòðàõ. 1) ðàñõîäû íà ïðèîáðåòåíèå îñíîâíûõ ñðåäñòâ; 2) ðàñõîäû íà ïðèîáðåòåíèå íåìàòåðèàëüíûõ àêòèâîâ; 3) ðàñõîäû íà ðåìîíò îñíîâíûõ ñðåäñòâ (â òîì ÷èñëå àðåíäîâàííûõ); 4) àðåíäíûå (â òîì ÷èñëå ëèçèíãîâûå) ïëàòåæè çà àðåíäóåìîå (â òîì ÷èñëå ïðèíÿòîå â ëèçèíã) èìóùåñòâî; 5) ìàòåðèàëüíûå ðàñõîäû; 6) ðàñõîäû íà îïëàòó òðóäà, âûïëàòó ïîñîáèé ïî âðåìåííîé íåòðóäîñïîñîáíîñòè â ñîîòâåòñòâèè ñ çàêîíîäàòåëüñòâîì Ðîññèéñêîé Ôåäåðàöèè; 7) ðàñõîäû íà îáÿçàòåëüíîå ñòðàõîâàíèå ðàáîòíèêîâ è èìóùåñòâà; 8) ñóììû íàëîãà íà äîáàâëåííóþ ñòîèìîñòü ïî ïðèîáðåòàåìûì òîâàðàì (ðàáîòàì è óñëóãàì); 9) ïðîöåíòû, óïëà÷èâàåìûå çà ïðåäîñòàâëåíèå â ïîëüçîâàíèå äåíåæíûõ ñðåäñòâ (êðåäèòîâ, çàéìîâ), à òàêæå ðàñõîäû, ñâÿçàííûå ñ îïëàòîé óñëóã, îêàçûâàåìûõ êðåäèòíûìè îðãàíèçàöèÿìè; 10) ðàñõîäû íà îáåñïå÷åíèå ïîæàðíîé áåçîïàñíîñòè íàëîãîïëàòåëüùèêà, ðàñõîäû íà óñëóãè ïî îõðàíå èìóùåñòâà è ò.ï.; 11) ñóììû òàìîæåííûõ ïëàòåæåé; 12) ðàñõîäû íà ñîäåðæàíèå ñëóæåáíîãî òðàíñïîðòà; 13) ðàñõîäû íà êîìàíäèðîâêè, â ÷àñòíîñòè íà: 14) ïëàòà ãîñóäàðñòâåííîìó è (èëè) ÷àñòíîìó íîòàðèóñó çà íîòàðèàëüíîå îôîðìëåíèå äîêóìåíòîâ; 15) ðàñõîäû íà àóäèòîðñêèå óñëóãè; 16) ðàñõîäû íà ïóáëèêàöèþ áóõãàëòåðñêîé îò÷åòíîñòè; 17) ðàñõîäû íà êàíöåëÿðñêèå òîâàðû; 18) ðàñõîäû íà ïî÷òîâûå, òåëåôîííûå, òåëåãðàôíûå è äðóãèå ïîäîáíûå óñëóãè, ðàñõîäû íà îïëàòó óñëóã ñâÿçè; 19) ðàñõîäû, ñâÿçàííûå ñ ïðèîáðåòåíèåì ïðàâà íà èñïîëüçîâàíèå ïðîãðàìì äëÿ ÝÂÌ è áàç äàííûõ; 20) ðàñõîäû íà ðåêëàìó; 21) ðàñõîäû íà ïîäãîòîâêó è îñâîåíèå íîâûõ ïðîèçâîäñòâ, öåõîâ è àãðåãàòîâ; 22) óïëà÷åííûå ñóììû íàëîãîâ è ñáîðîâ; 23) ðàñõîäû ïî îïëàòå ñòîèìîñòè òîâàðîâ, ïðèîáðåòåííûõ äëÿ äàëüíåéøåé ðåàëèçàöèè. Ðàñõîäû, íå ó÷èòûâàåìûå äëÿ íàëîãîîáëîæåíèÿ. 5. Ïîðÿäîê ðàñ÷åòà íàëîãà è åãî çà÷èñëåíèÿ â áþäæåòû è âíåáþäæåòíûå ôîíäû. 6. Îò÷åòíîñòü îðãàíèçàöèè, ïðèìåíÿþùåé ÓÑÍ. Ïîðÿäîê çàïîëíåíèÿ è ñðîêè ïîäà÷è íàëîãîâîé äåêëàðàöèè. Îò÷åòíîñòü ïî äðóãèì íàëîãàì, â òîì ÷èñëå ïî òåì, ïëàòåëüùèêàìè êîòîðûõ íå ÿâëÿþòñÿ îðãàíèçàöèè, ïðèìåíÿþùèå ÓÑÍ - êîãäà è â êàêîì îáúåìå åå ïîäàâàòü. 7. Îñîáåííîñòè òðóäîâûõ îòíîøåíèé ñ ðàáîòíèêàìè â îðãàíèçàöèè, ïðèìåíÿþùåé ÓÑÍ. Óïëàòà íàëîãà íà äîõîäû ôèçè÷åñêèõ ëèö è âçíîñîâ íà îáÿçàòåëüíîå ïåíñèîííîå ñòðàõîâàíèå. Îáåñïå÷åíèå ðàáîòíèêîâ ïîñîáèÿìè ïî âðåìåííîé íåòðóäîñïîñîáíîñòè. 8. Ñëîæíûå âîïðîñû ïðèìåíåíèÿ ÓÑÍ, â òîì ÷èñëå ïðîáëåìû ïåðåõîäà íà ÓÑÍ; ñïèñàíèÿ ÍÄÑ, îòðàæåííîãî íà ñ÷åòå 19 íà 1.01.03; ïðèçíàíèÿ ðàñõîäîâ íà ïðèîáðåòåíèå îñíîâíûõ ñðåäñòâ; ëèìèòèðóåìûå âèäû ðàñõîäîâ è ò.ä. 9. Îòâåòû íà âîïðîñû. Ñåìèíàð ñîñòîèòñÿ 17 àïðåëÿ (ì.Àêàäåìè÷åñêàÿ), 3 ìèíóòû îò ìåòðî. Ïðè ó÷àñòèè îäíîãî ÷åëîâåêà ñòîèìîñòü ëþáîãî ñåìèíàðà ñîñòàâëÿåò 3 900 ðóá., ñ ó÷åòîì ÍÄÑ.  ñòîèìîñòü ñåìèíàðà âêëþ÷åíû êîôå-ïàóçà, îáåä â ðåñòîðàíå è ðàçäàòî÷íûé ìàòåðèàë. Íà ñåìèíàðå âûñòóïàåò ÊËÈÌÎÂÀ Ìàðèíà Àðêàäüåâíà, ê.ý.í., ïðîôåññèîíàëüíûé áóõãàëòåð, àâòîð êíèã "Íàëîã íà äîõîäû ôèçè÷åñêèõ ëèö", "Êàê ïðàâèëüíî îôîðìèòü ó÷åòíóþ ïîëèòèêó îðãàíèçàöèè", "Äîêóìåíòîîáîðîò â áóõãàëòåðñêîì ó÷åòå", "Òðóäîâîé Êîäåêñ ÐÔ: ïîñòàòåéíûé êîììåíòàðèé", "Çàðàáîòíàÿ ïëàòà: ïðàêòè÷åñêîå ðóêîâîäñòâî", "Óïðîùåííàÿ ñèñòåìà íàëîãîîáëîæåíèÿ" è ìíîãèõ äðóãèõ. Îðãàíèçàòîð ñåìèíàðîâ Ìåæäóíàðîäíûé öåíòð îáó÷åíèÿ. Êîíòàêòíûå òåëåôîíû 207-26-21, 789-81-90, 772-92-46 nhaaxfz From noreply@sourceforge.net Fri Apr 11 16:52:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 08:52:38 -0700 Subject: [Patches] [ python-Patches-706707 ] time.tzset standards compliance update Message-ID: Patches item #706707, was opened at 2003-03-19 23:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706707&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Stuart Bishop (zenzen) Assigned to: Neal Norwitz (nnorwitz) Summary: time.tzset standards compliance update Initial Comment: Update to configure.in and test_time.py to only use TZ environment variable format documented at http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 11:52 Message: Logged In: YES user_id=33168 Checked in as: configure: 1.390 configure.in: 1.401 Lib/test/test_time.py: 1.14 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-11 11:38 Message: Logged In: YES user_id=6380 Neal, I think you can check it in now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 22:33 Message: Logged In: YES user_id=33168 Stuart, I saw the mails on py-dev, but am not sure about any conclusions. I tested the patch on Solaris 8 and Redhat 7.2. Solaris works (fails before the patch). Redhat fails with the patch, but I think it worked before the patch. I can check in to test on other architectures and back out if necessary. Let me know how to proceed. Thanks. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-04-06 22:19 Message: Logged In: YES user_id=46639 The bare except can go (just 'time.tzset()' without the try..except around it). The failure under Redhat is wierd - I can confirm that it works on a Redhat 7.2 box (as well as under OS X 10.2 and Solaris 2.8). The Australian timezone checks are testing that the timezone initialization stuff works in the southern hemisphere, and that time.altzone is being reset by tzset(). This will probably need to be taken to Python-dev unless you feel like applying the patch to HEAD and seeing who screams. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:46 Message: Logged In: YES user_id=33168 In the last chunk added, there is a bare except when calling time.tzset(). What are the possible exceptions? I don't want to have a bare except since this can mask a real error. The patch still fails for me on Linux (Redhat): * line 107: self.failUnless(time.tzname[1] == 'AEDT') - tzname has: ('AEST', 'AEST') * line 109: self.failUnlessEqual(time.daylight, 1) * line 111: self.failUnlessEqual(time.altzone, -39600) Haven't tried on other Unixes. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-03-27 15:12 Message: Logged In: YES user_id=46639 tzset3.diff is an updated diff against the CVS head. Fixes: -Don't test time.altzone for UTC - non-DST means altzone is undefined -Make sure dst timezone name is not the same as non-dst timezone name in TZ environment variable, to work around an apparent Solaris bug. -Extraneous cruft removed from test_time.py and configure.in - no more irrelevant comments. -More whitespace as per Tim's comments comments. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-21 16:28 Message: Logged In: YES user_id=33168 After patching, the test fails: File "/home/neal/build/python/2_3/Lib/test/test_time.py", line 115, in test_tzset self.failUnlessEqual(time.daylight,1) File "/home/neal/build/python/2.3/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 0 != 1 Also, why is the code commented out (via a string) on lines 120-144? Should these be removed? I see the comment about wallclock time, but don't understand why the code should be left in if we can't test it. I can understand a comment describing generally the issue. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-20 20:18 Message: Logged In: YES user_id=33168 I'll try to get to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-20 20:11 Message: Logged In: YES user_id=6380 Unassigning, as I won't hve time for this. But it is important - someone else should make sure this goes into 2.3b1! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-20 16:50 Message: Logged In: YES user_id=31435 Assigned to Guido, as I can't test it. Two notes: 1. Leaving commented-out code in config and the test suite doesn't appear to serve a purpose, although it will serve to confuse future readers ("why is this here? why is it commented out?"). 2. The Python style guide asks for a blank after commas in argument lists and tuples. We're not really in danger of stretching the screen here . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706707&group_id=5470 From noreply@sourceforge.net Fri Apr 11 17:25:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 09:25:19 -0700 Subject: [Patches] [ python-Patches-719777 ] Remove __file__ after running $PYTHONSTARTUP Message-ID: Patches item #719777, was opened at 2003-04-11 12:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=719777&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Neal Norwitz (nnorwitz) Summary: Remove __file__ after running $PYTHONSTARTUP Initial Comment: When the file named by PYTHONSTARTUP is executed, an __file__ is left behind in __main__ even though it doesn't apply to commands run in the interactive interpreter. This causes confusing output when warnings are generated. For example, running CVS Python with -Wall: >>> raise 'foo' /home/fdrake/env/python/INIT.py:1: PendingDeprecationWarning: raising a string exception is deprecated # INIT.py Traceback (most recent call last): File "", line 1, in ? foo Clearly, the deprecation warning is not generated because of anything in the file named. This patch causes the __file__ entry in the __main__ module to be removed after the PYTHONSTARTUP file has been run. __file__ was not added to __main__ in Python 2.2; this is caused by a change to PyRun_SimpleFileExFlags() in 2.3 (in particular, a change I made so __file__ would be set while running PYTHONSTARTUP). It does this simply by causing PyRun_SimpleFileExFlags() to clean up after itself. Functions defined in PYTHONSTARTUP that need __file__ after running will simply need to cache the value somewhere (possibly just under a different name in __main__'s globals). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=719777&group_id=5470 From noreply@sourceforge.net Fri Apr 11 20:01:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 12:01:48 -0700 Subject: [Patches] [ python-Patches-707427 ] Allow range() to return long integer values Message-ID: Patches item #707427, was opened at 2003-03-21 05:57 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707427&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Chad Netzer (chadn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow range() to return long integer values Initial Comment: Extend range() builtin so that long integers may be generated. ie. range(10**20, 10**20 + 5) New code path is only executed when normal code path fails, to avoid slowing down the existing run path. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-11 15:01 Message: Logged In: YES user_id=6380 Thanks; checked in. I made a number of changes to your patch. One significant one: I changed things around so that the "long" code now also gets invoked for a single argument; that makes sure that range(-2**100) returns [] instead of raising OverflowError. range(0, -2**100) already did the right thing. I also collapsed the various Fail labels into one, using XDECREF and initializing the pointer variables to NULL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707427&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:15:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:15:10 -0700 Subject: [Patches] [ python-Patches-568669 ] gettext module charset changes Message-ID: Patches item #568669, was opened at 2002-06-13 16:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=568669&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Rejected Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: gettext module charset changes Initial Comment: The GNU gettext docs make two recommendations: that the source string to gettext() be in us-ascii, and that the default output charset be in the locale's character set. I think the latter makes the most sense for our ugettext() methods. The attached patch sets the default character set to us-ascii for NullTranslations. For GNUTranslations, the default character set is taken from the Content-Type: header if given in the .po/.mo file, otherwise it's taken from the default locale information, if available. It falls back to the base class charset (by default us-ascii). This patch also provides the following: - add a set_charset() method to the NullTranslations base class, so that it is easier to change the default character set. For symmetry, I also rename charset() to get_charset() and keep the former for backwards compatibility. - convert Lib/test/test_gettext.py to unittest style (sans the cvs rm of Lib/test/output/test_gettext which we'll do separately) - update the docs for all the code changes described above. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:15 Message: Logged In: YES user_id=33168 Barry, what's the status of this patch now? Should it be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-13 16:53 Message: Logged In: YES user_id=21627 Obtaining the locale's codeset by parsing environment variables is bogus. For example, in most installations, the codeset for de_DE@euro is iso-8859-15. However, this is impossible to find out by just parsing the environment variables. Instead, the proper way is to use locale._nl_langinfo(CODESET) where available. If that is not available, the following heuristics could be applied: - On Windows, it is "mbcs" - On Unix, parse the environment variables As for the actual usage of the charset, I think you misinterpret the gettext recommendation: the result of gettext ought to be in the locale's encoding (this is not a default encoding). This means that, if the codeset of the locale and the charset of the catalog differ, character set conversion needs to be invoked; I can see no traces of that happening in your patch. The common case is a catalog in UTF-8, and the user's codeset is language-specific (such as Latin-9). In that case, conversion works well. There is also the case of unsupported conversions (e.g. usage of EURO SIGN in the catalog, but Latin-1 in the locale); in this case, glibc iconv uses transliteration (to "EUR", in the example). Since we have no transliteration, we would probably fall back to return the string in the catalog's encoding :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=568669&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:16:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:16:59 -0700 Subject: [Patches] [ python-Patches-558745 ] GC: untrack simple objects Message-ID: Patches item #558745, was opened at 2002-05-21 12:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558745&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: GC: untrack simple objects Initial Comment: This patch makes the GC untrack tuples that contain no GC objects. Unfortunately it doesn't seem to help much. The time for the 'storetups' case of iterzip.py seems be about twice as fast (matching Daniel Dunbar result). Loading a number of complex MEMS Exchange web pages causes the size of gen2 to go up to 120000 instead of 134000 without the patch. This change doesn't seem to be worth making. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:16 Message: Logged In: YES user_id=33168 Neil, are you still interested in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558745&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:22:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:22:41 -0700 Subject: [Patches] [ python-Patches-579435 ] Shadow Password Support Module Message-ID: Patches item #579435, was opened at 2002-07-09 23:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 Category: Modules Group: Python 2.2.x >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Lance Ellinghaus (ellinghaus) >Assigned to: Neal Norwitz (nnorwitz) Summary: Shadow Password Support Module Initial Comment: Attached is the spwd module. This module provides support for Shadow Passwords on Solaris 2.8. This compliments the nis and pwd modules. This is the only way to gain access to the encrypted passwords when using shadow passwords on Solaris. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:22 Message: Logged In: YES user_id=33168 There doesn't seem to be much interest in this patch. I don't think it reaches a wide-enough audience, therefore, I'm rejecting it. If there is broader support (many people are interested in seeing shadow password support in the core), we can add it later. I think it would be best to provide this as a third-party module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:24:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:24:28 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 23:15 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:24 Message: Logged In: YES user_id=33168 Anybody, is this patch still necessary? Have the problems been fixed? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-11 06:52 Message: Logged In: YES user_id=6656 > (Aside: why does this build `python' for 10.1 but > `python.exe' for 10.2?) Because the sf machine has a case sensitive filesystem? I don't see any failures on 10.1.5 (after I ran ulimit, duh). Haven't tried this patch yet... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-11 02:42 Message: Logged In: YES user_id=12800 Ok, I've added the Wouters Elaboration to regrtest.py and verified it works on both 10.1 and 10.2 (the former being the OSX machine on the SF compile farm and the latter being my home machine). Attached is the patch (I hope :). (Aside: why does this build `python' for 10.1 but `python.exe' for 10.2?) I think this patch is fine for Py2.2.2. Today Guido said he'd feel more comfortable with a patch to main.c than a patch to regrtest.py, s?re.py, or site.py (if I understood him correctly). However, I don't think there's time for that for Py2.2.2. Perhaps we should simply commit this simple fix so the test suite passes, and then work out a more comprehensive patch for Py2.3? Note that In addition, here is the output of the regrtest on 10.1 and 10.2. Is it worth spending time trying to fix these for the Py2.2.2 release? 10.1: 170 tests OK. 2 tests failed: test_fcntl test_largefile 21 tests skipped: test_al test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_minidom test_poll test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 3 skips unexpected on darwin: test_sax test_pyexpat test_locale make: *** [test] Error 1 10.2: 171 tests OK. 1 test failed: test_locale 21 tests skipped: test_al test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_minidom test_nis test_poll test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 2 skips unexpected on darwin: test_sax test_pyexpat ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-10 18:38 Message: Logged In: YES user_id=34209 Oh, and the diff is kind of amusing. It seems to be MacBinary, but 'file' on my Debian machine isn't quite sure: /home/thomas/regrtest.diff: MacBinary III data with surprising version number Fortunately it's still readable :-) I guess I should go back to "cool with a Macintosh" too. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-10 18:28 Message: Logged In: YES user_id=34209 I'd suggest adding a min(max, ) to the patch, so that it becomes: soft, hard = resource.getrlimit(resource.RLIMIT_STACK) newsoft = min(hard, max(soft, 1024*2048)) resource.setrlimit(resource.RLIMIT_STACK, newsoft, hard) And if the test suite only triggers this problem, doesn't it make more sense in s?re.py, as Fredrik suggested ? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-10 15:05 Message: Logged In: YES user_id=12800 I can verify the patch works on 10.1, specifically the OSX Server in the SF compile farm. ---------------------------------------------------------------------- Comment By: Steven D. Majewski (sdm7g) Date: 2002-10-10 13:11 Message: Logged In: YES user_id=105602 NOT running as root -- I just tried it again and verified that it works for me. HOWEVER: I haven't yet upgraded to Jaguar/10.2 Maybe that's the difference ? I can post a request on the pythonmac list and ask some others to try it and find out if it's a 10.1.x vs 10.2 thing. -- Steve ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:04 Message: Logged In: YES user_id=44345 Sorry for the bogus updates. Opera 6.0 Beta 1 apparently has file upload problems. Resorting to IE... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:27:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:27:37 -0700 Subject: [Patches] [ python-Patches-590513 ] Add popen2 like functionality to pty.py. Message-ID: Patches item #590513, was opened at 2002-08-03 10:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590513&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Rasjid Wilcox (rasjidw) Assigned to: Thomas Wouters (twouters) Summary: Add popen2 like functionality to pty.py. Initial Comment: This patch adds a popen2 like function to pty.py. Due to use of os.execlp in pty.spawn, it is not quite the same, as all the arguments (including the command to be run) must be passed as a tupple. It is only a first draft, and may need some more work, which I am willing to do if some direction is indicated. Tested on Python2.2, under RedHat Linux 7.3. Rasjid. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:27 Message: Logged In: YES user_id=33168 I am rejecting this patch due to no activity. Rasjid, if you are still interested in completing the patch, with test, and documentation, feel free to re-open this report or add a new one. Thanks. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2003-01-02 05:22 Message: Logged In: YES user_id=39640 I do plan to do so, but some of Thomas' comments required some thought, and in the meantime other priorities came up. Also, writing docs and a testcase will take some time (and thought) and seem to be the most requrested aspect. Realistically, I would expect to get to it within the next month or two. Unfortunately, I can't really promise much more than that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 15:09 Message: Logged In: YES user_id=33168 What is the status of this patch? Rasjid do still plan to produce an updated patch. Note: 2.3 alpha 1 was released yesterday. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2002-09-10 07:38 Message: Logged In: YES user_id=39640 Thanks for the comments Thomas. a) I have not done docs or testcase yet. I wanted to be clear about the direction first. I will submit with my next version. b) No particular reason for threads, just more intuitive to me. On due reflection, os.fork is better. I shall drop the use of threads. c) I shall keep backward compatibility. Perhaps 'returning_spawn' for the new version. With luck, next version in a couple of weeks. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-09-09 09:57 Message: Logged In: YES user_id=34209 I have several comments, but I'm not sure if they've been adressed in other forums or not. Guido mentions documentation, but the patches attached don't seem to contain them; are they seperate ? I also don't see a testcase. - Why threads ? A seperate non-thread version, with a third process to handle the data trafficking, and falling back to that when threads are not available would be nice. - I concur the new behaviour is much more useful. However, I'm a stickler for backward compatibility, so I advice against renaming the old spawn :) - I don't like 'th_spawn'. 'spawn_thread' or 'threaded_spawn' or some such sound better to me (but see above about threads.) - Some minor whitespace issues (the line-wrap on line 150 is not necessary, line 179 is too long, and the backslashes on lines 190 and 205 are not necessary.) A comment describing why the tty.setraw() is done would also be nice. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2002-08-29 23:54 Message: Logged In: YES user_id=39640 Okay. My final version (I promise!). The code has been reorganised a little so that: a) it is cleaner to read b) the popen2 function now returns the pid of the child process Rasjid. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-20 14:33 Message: Logged In: YES user_id=6380 Assigning this to Thomas Wouters according to his wishes. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-08-16 09:47 Message: Logged In: YES user_id=34209 The pty module actually works on all platforms that provide openpty(). I know at least BSDI and FreeBSD do, in addition to Linux, and I suspect OpenBSD and NetBSD as well, and possibly other BSD-derived systems. Still, it is very unlikely to work on non-POSIX-ish systems, so /bin/sh is a safe bet. I can take a look at the patch, and test it on a variety of machines, but not before I leave on a two-week vacation, this sunday :) I have plenty of time to look at it when I'm back though, in the first week of September. Feel free to assign the patch to me, as a reminder. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2002-08-16 08:39 Message: Logged In: YES user_id=39640 Okay. This is essentially my final version, subject to an issue around the naming of a couple of the modules functions. My issue is that the pty.spawn funciton does not return. My new one 'th_spawn' function does. I believe quite strongly that to be consistent with the rest of python, 'th_spawn' should be renamed 'spawn', and the current spawn function should be renamed something like '_master' since it takes the place of the pty master. The issue of course is backward compatibility. However, I believe this to be relatively minor for two reasons. 1. I think very few (if any) people are using it, since it was a) largely undocumented, b) didn't always work c) wasn't particularly useful, since it only allowed control from an existing pty (so what was the point?) 2. If anyone is using it, they would _almost_ certainly be starting it on a new thread, so all that would happen if the functions were renamed would be that an extra (redundant) sub-thread is created. I have posted to comp.lang.python to see what other pty.py users think. Subject to the response here and there, I may post to python-dev in due course. Rasjid. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-05 11:20 Message: Logged In: YES user_id=6380 I mostly concur with Martin von Loewis's comments, though I'm not sure this is big enough for a PEP. I think that you're right in answering (yes, no, yes) but I have no information (portability of this module is already limited to IRIX and Linux, according to the docs). The docs use the word "baffle" -- I wonder if you could substitute something else or generally clarify that sentence; it's not very clear from the docs what spawn() does (nor what fork() does, to tell the truth -- all these could really use some examples). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-05 07:44 Message: Logged In: YES user_id=21627 I'm not a regular pty user. Please ask those questions in comp.lang.python, and python-dev. You can also ask previous authors to pty for comments. Uncertainty in such areas might be a hint that a library PEP is need, to justify the rationale for all the details. There is no need to hurry - Python 2.3 is still months away. That said, I do think that this functionality is desirable, so I'd encourage you to complete this task. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2002-08-05 07:34 Message: Logged In: YES user_id=39640 Before I do docs etc, I have a few questions: 1. I could make it more popen2 like by changing the args to def popen2(cmd, ....) and adding argv=('/bin/sh','-c',cmd) Is this a better idea? Does it reduce portability? Is it safe to assume that all posix systems have /bin/sh? (My guess is yes, no and yes.) 2. Should the threading done in the pty.popen2 function be moved to a separate function, to allow more direct access to spawn. (The current spawn function does not return until the child exits or the parent closes the pipe). 3. Should I worry about how keyboard interrupts are handled? In some cases an uncontrolled process may be left hanging around. Or is it the job of the calling process to deal with that? Lastly, I am away for a week from Wednesday, so I won't be able to do much until I get back, but I will try and finish this off then. Cheers, Rasjid. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 04:56 Message: Logged In: YES user_id=21627 Can you please write documentation and a test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590513&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:30:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:30:07 -0700 Subject: [Patches] [ python-Patches-600984 ] Refactoring of difflib.Differ Message-ID: Patches item #600984, was opened at 2002-08-27 16:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=600984&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Costas Malamas (cmalamas) Assigned to: Tim Peters (tim_one) Summary: Refactoring of difflib.Differ Initial Comment: The difflib.Differ class currently only acts as a helper for ndiff, creating human-readable diffs that mimic the Unix diff. This patch refactors Differ into two layers: BaseDiffer and Differ. BaseDiffer contains the workhorse algorithms of the current Differ without format-specific code. Instead, it adds event handlers that are triggered as the diff is calculated. Thus the Differ engine can now be used to produce diff reports in other formats (like HTML or XML) or to add programmatic behavior --for example to extract only inserted XML from an XML feed for faster parsing. Differ implements the BaseDiffer API to produce a backwards-compatible diff, just like ndiff. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:30 Message: Logged In: YES user_id=33168 Costas, since this patch would only be applied against 2.3, the current patch is not useful. If you are interested in forward porting the patch to current code, we can consider it then. Thanks. ---------------------------------------------------------------------- Comment By: Costas Malamas (cmalamas) Date: 2002-08-27 16:59 Message: Logged In: YES user_id=71233 Forgot to say that this is a 2.1 patch only as I cannot test 2.2 yet. Assigned to Tim, since it's 95% his code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=600984&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:31:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:31:52 -0700 Subject: [Patches] [ python-Patches-618791 ] [mingw patches] alloca and posixmodule Message-ID: Patches item #618791, was opened at 2002-10-04 19:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618791&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 2 Submitted By: Gerhard Häring (ghaering) Assigned to: Gerhard Häring (ghaering) Summary: [mingw patches] alloca and posixmodule Initial Comment: This is the first patch in a series of patching of porting Python to native win32, while still using the autoconf-based build process. The compiler used is mingw, the build environment used is msys, a stripped down Cygwin from the mingw project. This patch does several things: * change _alloca to alloca for both mingw and Visual C++, to avoid unnecessary #ifdef-ing. * Change the makesetup shell script to work for win32, where for some weird reason we have a module 'nt' built from a posixmodule.c file. * Change on occurence of #ifdef MS_WINDOWS in posixmodule.c where it should really have been #ifdef Py_WIN_WIDE_FILENAMES * Change the #ifdefs in posixmodule.c so that it can be built with both MSVC and mingw The result of this patch is that we can build a statically built python.exe with a simple ./configure make under mingw/msys. There's, however, still of additional work to do until we can build a native win32 Python with the autoconf-based build process. Please apply this ASAP, as I want to avoid having a diverging Python tree on my harddisk (this makes patch creation a lot more difficult). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:31 Message: Logged In: YES user_id=33168 Gerhard, is there any reason to leave this patch open? ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-05 05:35 Message: Logged In: YES user_id=163326 Cool :-) I'm assigning this patch to myself now. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 22:39 Message: Logged In: YES user_id=31435 Welcome, Gerhard! You have commit privileges now. If you need any help with SourceForge mechanics, ask on Python-Dev and you'll get more advice than you can stand . ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-04 19:57 Message: Logged In: YES user_id=163326 Sounds great. I'd have needed advice from python-dev anyway, especially on the parts where autoconf is concerned (I'm relatively green there). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-04 15:04 Message: Logged In: YES user_id=6380 What I'd like to see most is for somebody with CVS commit permission for Python *and* an understanding of mingw to start making the changes in Python's CVS. I'd be willing to give you CVS permission for this, if you're willing to work with python-dev regarding the acceptability of the various changes you're proposing. I presume you'll quickly get a sense for what kind of changes are non-controversional and can be checked in without asking. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-04 09:14 Message: Logged In: YES user_id=163326 Guido, if you think that there should either be one big patch that enables Python to be built with mingw or nothing at all, then please close this as 'rejected' or whatever. There are good reasons for doing so, just as there are arguments for incremental patches, like I described above. I won't feel offended, especially as I know how annoying it is for myself to have a SF entry page full of this kind of patches/bugs :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618791&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:35:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:35:02 -0700 Subject: [Patches] [ python-Patches-641685 ] Use .dylib for shared objects on MacOS X Message-ID: Patches item #641685, was opened at 2002-11-21 01:12 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=641685&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Use .dylib for shared objects on MacOS X Initial Comment: This patch enables python to recognize .dylib as a valid shared library extension on MacOS X/Darwin. Python will also use .dylib as the extension for native-code python modules; .so files are still recognized for backward compatibility. The reason for writing this patch was that setup.py failes to recognize the existince of openssl because there is only a shared library with suffix .dylib. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:35 Message: Logged In: YES user_id=33168 Jack, what should be done for this patch? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 13:33 Message: Logged In: YES user_id=11375 Reassigning to Jack. (It doesn't look like find_library_file in setup.jaguar.py is actually used, so maybe you could just delete it.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-27 08:48 Message: Logged In: YES user_id=11375 I've checked in my setup.py patch, and the Lib/distutils/extension.py portion of Ronald's patch. Is the rest of Ronald's patch OK? Should I check that in, too? Jack reports that there's also a duplicate find_library_file in Mac/OSX/setup.jaguar.py. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-27 04:27 Message: Logged In: YES user_id=580910 I don't have checkin priviliges for the Python CVS repository, so feel free to checkin my patches if they are correct. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-26 17:29 Message: Logged In: YES user_id=45365 I think that if we keep .so as an allowed extension for dynamically loaded modules we're okay for both 2.3a0 and 2.2.X. Unless I misunderstand how compatibility between micro-releases is suppoosed to work, should it be forward compatible too? I.e. if 2.2.3 would create dynamic modules with .dylib they won't be useable in 2.2.2. If that is a problem then I think we should keep .so as the default and allow .dylib (for 2.2.X, for 2.3 we should do the right thing). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-26 12:28 Message: Logged In: YES user_id=11375 Noted; updated version of the patch attached that uses os.path.dirname. I'll check it in after testing it on the Mac. Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-26 11:11 Message: Logged In: YES user_id=21627 Andrew, that part is fine, please check it in. There is on pitfall, though: if one of the std_dirs is a prefix of one of the paths, and the library is found in that path, the function will return the wrong result. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-26 10:37 Message: Logged In: YES user_id=11375 I can't pronounce on the rest of Ronald's patch, but the patch to distutils/extension.py seems obviously correct and should be committed in any case. Ronald, do you have CVS access or should I check it in? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-25 03:00 Message: Logged In: YES user_id=580910 Somehow I didn't upload the patch when I created this thread. Here it is. ---------------------------------------------------------------------- Comment By: Dan Wolfe (dkwolfe) Date: 2002-11-24 02:16 Message: Logged In: YES user_id=80173 I previously assumed that OS X was capable of linking against .so file. This turns out not to be the case (thanks Ronald for making me a believer!) and Ronald's original patch would have also fixed the problem. I tested both Ronald's and akuchling patches together, along with a minor modification to unixcompiler.py to remove the two dylib blocks from the find_library_file function (no longer needed with Ronald's patches) under 10.2.2, and everything works fine in a framework and regular Unix build. Only thing to worry about is that the modules in the lib-dynload directory now have a .dylib suffix. The readme should probably be updated to tell the user they need to manually remove these files. Also, the test_socket_ssl.py is not run unless a -u network is made part of the test cmd line. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-22 16:20 Message: Logged In: YES user_id=580910 Please keep in mind that the .so suffix is not a valid shared-library suffix on MacOS X: The linker will not check for 'libfoo.so' if you link with '-lfoo'. It might therefore be prudent to look for the .dylib before looking for a .so (if you want to look for a .so at all). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-22 08:36 Message: Logged In: YES user_id=11375 I've tried my patch now, and with it SSL support is automatically built on MacOS X. Whether or not this fixes the bug, though, I think this patch should be applied to cut down on some code duplication. If someone else can make a quick sanity-check on the patch in case of silly errors, I'll check it in. (Is it a bugfix candidate? Not sure, but I'm leaning toward "yes".) I've also revised the patch to make its behaviour completely compatible with the unpatched version of find_library_file; bug-in-waiting pointed out by Dan Wolfe. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-21 15:43 Message: Logged In: YES user_id=11375 I've attached a copy of my still-untested patch that fixes the code duplication in setup.py. I'll try to test it this evening. ---------------------------------------------------------------------- Comment By: Dan Wolfe (dkwolfe) Date: 2002-11-21 14:19 Message: Logged In: YES user_id=80173 There's a problem regarding Ronald's SSL patches - they make setup assume that every shared library is a .dylib rather than either a .so or .dylib, which breaks compatibility.... After some late night investigation, I found that the source of the problem is distutils. We previously had a problem under Mac OS X where it wasn't finding the .dylib libraries for libz and other similar .dylib libraries - both user and system installed. Someone came up with a patch and this can be found in /distutils/unixcompiler.py around line 278 in the function find_library_file. Basically, it just adds another check to look for .dylib if it can't find the .so file. The unixcompiler.py file inherits from the ccompiler.py file which has a stub routine for this function. For the longest time I thought the function in unixcompiler.py was being called and was pulling my hair out trying to figure out why it wasn't being finding the ssl library since it only looked for .a and .so files... It turns out that setup.py also implements a function by the SAME name, but with different parameters and instead of returning a true/false to indicate whether the library exists, it returns the pathname to the library. This function, unfortunately, was NOT previously modify to support dylibs and as a result only .a and .so files would be searched for. Below is a diff that fixes the problem simply by adding another check for a dylib file and returning the results if it exists. lobo% diff -u /Users/lobo/Desktop/Python-2.2.2/setupold.py /Users/lobo/Desktop/Python-2.2.2/setup.py --- /Users/lobo/Desktop/Python-2.2.2/setupold.py Wed Oct 9 17:59:16 2002 +++ /Users/lobo/Desktop/Python-2.2.2/setup.py Thu Nov 21 09:12:43 2002 @@ -44,6 +44,10 @@ filename = compiler.library_filename(libname, lib_type='shared') result = find_file(filename, std_dirs, paths) if result is not None: return result + + filename = compiler.library_filename(libname, lib_type='dylib') + result = find_file(filename, std_dirs, paths) + if result is not None: return result filename = compiler.library_filename(libname, lib_type='static') result = find_file(filename, std_dirs, paths) I've minimally tested it using the normal non framework installed and it appears to function correctly. Enjoy. (sorry about not uploading a patch but SF crashes IE and Chimera doesn't allow a attachement....) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=641685&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:36:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:36:23 -0700 Subject: [Patches] [ python-Patches-643711 ] refactoring and documenting ModuleFinder Message-ID: Patches item #643711, was opened at 2002-11-25 13:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=643711&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: refactoring and documenting ModuleFinder Initial Comment: This is not (yet) a complete patch, it is thought as a workspace for improvements to tools/freeze/moduulefinder, so that it can eventually go into the standard library. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:36 Message: Logged In: YES user_id=33168 What's the status of this patch now that modulefinder.py has been moved into the library? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-29 05:16 Message: Logged In: YES user_id=92689 Here's a revised patch. The previous version actually was too lenient: it could list submodules as "maybe missing" when they were missing for sure. Fixed by tracking unresolvable starimports. (Removed the module.badimports attribute of my previous patch, it now uses mf.badimports appropriately.) Meta question: are we going to commit fixes to modulefinder.py in the freeze directory and do the move when the doco is done, or do we not commit anything until we're ready for the move? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-28 15:28 Message: Logged In: YES user_id=11105 Just, I trust your analysis while I don't understand it ;-). Thinking more about my "ignore" concept shows that it is unneeded. Warnings can be better removed after modulefinder has been run by examining the data it collects. To answer your question: "excludes" does not mean 'may be missed', it means 'must be excluded' IMO, and no, this was not the purpose of my patch. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-28 15:17 Message: Logged In: YES user_id=92689 Thomas, your _add_badmodule patch actually broke my code... It took me a while to figure out why, and while at it, I discovered a blatant stupidity in my own patch: somehow I completely overlooked the fact that mf.badmodules already references the modules that did the failed import, so my module.badimports thing can go. It does the exact same thing. Almost... and your patch made that clear: the lines that you patched actually make the badmodules reference lie (and with your patch it also makes mod.badimports lie ;-): if module X imports Y.Z, and Z isn't found, it lists Y as an importer of Y.Z, which isn't true. My any_maybe_missing() code needs to know whether the __init__.py tried to failed import _itself_, because if it did (and failed) it's certain that the submodule is missing. But if it _didn't_, the "missing submodule" should be listed as "maybe missing", as it's most likely just a global in the __init__.py. I'll try to revise my patch tomorrow, it should become simpler. In the meantime I think it might indeed be useful to distinguish between "may be missed" and "must be excluded". Is that what your "ignore" patch tried to do? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-28 13:22 Message: Logged In: YES user_id=92689 What's the difference between this "ignore" variable and the "exclude" list? And why do you need to ignore modules based on importing module? In my OSX appbuilder stuff I simply have a list of modules that will be removed from the 'missing' list when reporting: MAYMISS_MODULES = ['mac', 'os2', 'nt', 'ntpath', 'dos', 'dospath', 'win32api', 'ce', '_winreg', 'nturl2path', 'sitecustomize', 'org.python.core', 'riscos', 'riscosenviron', 'riscospath' ] (I think I could just add this to the exclude list and get the same effect.) Let's please keep it simple! ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-28 07:04 Message: Logged In: YES user_id=11105 Now that it works really fine, I would like to make progress. This new patch 'thomas1.patch' is against the patched modulefinder, it is easier to read this way. First it passes all changes to self.badmodules through the _add_badmodule() method. Then, and this part is not really polished, but you may get the idea, it introduces a new ignored instance variable which is thought to suppress most of the remaining missing modules warnings. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-27 06:02 Message: Logged In: YES user_id=92689 Whoops, that was a useless patch :-( I managed to forgot to copy the last three lines of the original scan_code() which takes care of delayed imports... Fixed in the new patch. I now also patched Modulefinder.report() to actually use the new any_missing_maybe() feature. (Note for the lib doco to be written: we should document that people should use any_missing[_maybe]() instead of looking directly at mf.badmodules. mf.badmodules is the raw list, any_missing_maybe() filters out the false positives.) I've ran before/after tests on all of Lib/*.py and Lib/test_*.py and the only differences I found are those that this patch address, ie. less false positives when reporting missing modules. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-27 03:27 Message: Logged In: YES user_id=11105 Running the current CVS ModuleFinder on a simple script which contains 'import os' with Python 2.2 on Win2k finds 27 modules, while with this patch it only finds 13. (and unassign Mark) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-26 20:30 Message: Logged In: YES user_id=92689 Oh, I just realized ModuleFinder.report() should still be patched to use any_missing(), or even better, any_missing_maybe(). Will do if this gets through. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-26 20:26 Message: Logged In: YES user_id=92689 Here's a patch. Summary: any_missing() returns less bogus modules. - I've rewritten scan_code() more or less from scratch, factored bits and pieces out for readability. - keep track of global assignments and failed imports per module; use this to determine whether the Y in "from X import Y" is a submodule or just a global name. This is not 100% doable: you can't tell which symbols are imported when doing a star import of a non-Python module short of actually importing it. - added a new method to ModuleFinder: any_missing_maybe(), which returns *two* lists, one with certain misses, one with possible misses. The possible misses are *very* often false alarms, so it's useful to keep this list separate. any_misses() now simply returns the union of any_missing_maybe(). I pretty sure this is all 100% backward compatible, so after some more testing it could be checked in. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-26 03:11 Message: Logged In: YES user_id=11105 I've removed in current CVS the support for modules listed in the registry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-26 02:57 Message: Logged In: YES user_id=11105 Mark writes in private email: "Modules listed in the registry was a dumb idea. This whole scheme can die. AFAIK, no one in the world uses it (including win32all since the last build)." ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-25 14:59 Message: Logged In: YES user_id=11105 Assign to Mark, hoping for an answer. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-25 13:58 Message: Logged In: YES user_id=11105 First question for anyone listening: isn't the windows _try_registry stuff unneeded, because imp.find_module handles this itself? Even in python15, imp.find_module ("pythoncom") returns 'c:\winnt\system32\pythoncom15.dll' on my system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=643711&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:43:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:43:11 -0700 Subject: [Patches] [ python-Patches-568669 ] gettext module charset changes Message-ID: Patches item #568669, was opened at 2002-06-13 16:13 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=568669&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Rejected Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: gettext module charset changes Initial Comment: The GNU gettext docs make two recommendations: that the source string to gettext() be in us-ascii, and that the default output charset be in the locale's character set. I think the latter makes the most sense for our ugettext() methods. The attached patch sets the default character set to us-ascii for NullTranslations. For GNUTranslations, the default character set is taken from the Content-Type: header if given in the .po/.mo file, otherwise it's taken from the default locale information, if available. It falls back to the base class charset (by default us-ascii). This patch also provides the following: - add a set_charset() method to the NullTranslations base class, so that it is easier to change the default character set. For symmetry, I also rename charset() to get_charset() and keep the former for backwards compatibility. - convert Lib/test/test_gettext.py to unittest style (sans the cvs rm of Lib/test/output/test_gettext which we'll do separately) - update the docs for all the code changes described above. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-11 21:43 Message: Logged In: YES user_id=12800 Yes, let's reject this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:15 Message: Logged In: YES user_id=33168 Barry, what's the status of this patch now? Should it be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-13 16:53 Message: Logged In: YES user_id=21627 Obtaining the locale's codeset by parsing environment variables is bogus. For example, in most installations, the codeset for de_DE@euro is iso-8859-15. However, this is impossible to find out by just parsing the environment variables. Instead, the proper way is to use locale._nl_langinfo(CODESET) where available. If that is not available, the following heuristics could be applied: - On Windows, it is "mbcs" - On Unix, parse the environment variables As for the actual usage of the charset, I think you misinterpret the gettext recommendation: the result of gettext ought to be in the locale's encoding (this is not a default encoding). This means that, if the codeset of the locale and the charset of the catalog differ, character set conversion needs to be invoked; I can see no traces of that happening in your patch. The common case is a catalog in UTF-8, and the user's codeset is language-specific (such as Latin-9). In that case, conversion works well. There is also the case of unsupported conversions (e.g. usage of EURO SIGN in the catalog, but Latin-1 in the locale); in this case, glibc iconv uses transliteration (to "EUR", in the example). Since we have no transliteration, we would probably fall back to return the string in the catalog's encoding :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=568669&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:45:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:45:14 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 23:15 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) >Assigned to: Jack Jansen (jackjansen) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-11 21:45 Message: Logged In: YES user_id=12800 Yes, I think this problem still exists, but we haven't decided what to do about it. I'm assigning it to Jack for final disposition. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:24 Message: Logged In: YES user_id=33168 Anybody, is this patch still necessary? Have the problems been fixed? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-11 06:52 Message: Logged In: YES user_id=6656 > (Aside: why does this build `python' for 10.1 but > `python.exe' for 10.2?) Because the sf machine has a case sensitive filesystem? I don't see any failures on 10.1.5 (after I ran ulimit, duh). Haven't tried this patch yet... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-11 02:42 Message: Logged In: YES user_id=12800 Ok, I've added the Wouters Elaboration to regrtest.py and verified it works on both 10.1 and 10.2 (the former being the OSX machine on the SF compile farm and the latter being my home machine). Attached is the patch (I hope :). (Aside: why does this build `python' for 10.1 but `python.exe' for 10.2?) I think this patch is fine for Py2.2.2. Today Guido said he'd feel more comfortable with a patch to main.c than a patch to regrtest.py, s?re.py, or site.py (if I understood him correctly). However, I don't think there's time for that for Py2.2.2. Perhaps we should simply commit this simple fix so the test suite passes, and then work out a more comprehensive patch for Py2.3? Note that In addition, here is the output of the regrtest on 10.1 and 10.2. Is it worth spending time trying to fix these for the Py2.2.2 release? 10.1: 170 tests OK. 2 tests failed: test_fcntl test_largefile 21 tests skipped: test_al test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_minidom test_poll test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 3 skips unexpected on darwin: test_sax test_pyexpat test_locale make: *** [test] Error 1 10.2: 171 tests OK. 1 test failed: test_locale 21 tests skipped: test_al test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_minidom test_nis test_poll test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 2 skips unexpected on darwin: test_sax test_pyexpat ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-10 18:38 Message: Logged In: YES user_id=34209 Oh, and the diff is kind of amusing. It seems to be MacBinary, but 'file' on my Debian machine isn't quite sure: /home/thomas/regrtest.diff: MacBinary III data with surprising version number Fortunately it's still readable :-) I guess I should go back to "cool with a Macintosh" too. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-10 18:28 Message: Logged In: YES user_id=34209 I'd suggest adding a min(max, ) to the patch, so that it becomes: soft, hard = resource.getrlimit(resource.RLIMIT_STACK) newsoft = min(hard, max(soft, 1024*2048)) resource.setrlimit(resource.RLIMIT_STACK, newsoft, hard) And if the test suite only triggers this problem, doesn't it make more sense in s?re.py, as Fredrik suggested ? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-10 15:05 Message: Logged In: YES user_id=12800 I can verify the patch works on 10.1, specifically the OSX Server in the SF compile farm. ---------------------------------------------------------------------- Comment By: Steven D. Majewski (sdm7g) Date: 2002-10-10 13:11 Message: Logged In: YES user_id=105602 NOT running as root -- I just tried it again and verified that it works for me. HOWEVER: I haven't yet upgraded to Jaguar/10.2 Maybe that's the difference ? I can post a request on the pythonmac list and ask some others to try it and find out if it's a 10.1.x vs 10.2 thing. -- Steve ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:04 Message: Logged In: YES user_id=44345 Sorry for the bogus updates. Opera 6.0 Beta 1 apparently has file upload problems. Resorting to IE... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Sat Apr 12 02:54:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Apr 2003 18:54:20 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 05:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 04:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 14:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 10:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 08:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 12:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 08:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-20 22:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 13:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 04:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 15:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 06:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 03:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 13:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 18:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Sat Apr 12 11:40:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Apr 2003 03:40:09 -0700 Subject: [Patches] [ python-Patches-718049 ] Setting exe_extension for cygwin Message-ID: Patches item #718049, was opened at 2003-04-09 09:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: Setting exe_extension for cygwin Initial Comment: On cygwin, the setup.py script uses unixccompiler.py for compiling and linking C extensions. The unixccompiler.py script assumes that executables do not get special extensions, which makes sense for Unix. However, on Cygwin, executables get an .exe extension. This causes a problem during the configuration step (python setup.py config), in which some temporary executables may be generated. As unixccompiler.py does not know about the .exe extension, distutils fails to clean up after itself: it does not remove _configtest.exe but tries to remove _configtest instead. The attached patch to unixccompiler.py sets the correct exe_extension for cygwin by checking if sys.platform is 'cygwin'. With this patch, distutils cleans up after itself correctly. Michiel de Hoon University of Tokyo, Human Genome Center. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-12 12:40 Message: Logged In: YES user_id=21627 Can you explain wh unixccompiler is used? cygwincompiler should be used instead... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 From noreply@sourceforge.net Sat Apr 12 12:16:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Apr 2003 04:16:17 -0700 Subject: [Patches] [ python-Patches-718049 ] Setting exe_extension for cygwin Message-ID: Patches item #718049, was opened at 2003-04-09 16:45 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: Setting exe_extension for cygwin Initial Comment: On cygwin, the setup.py script uses unixccompiler.py for compiling and linking C extensions. The unixccompiler.py script assumes that executables do not get special extensions, which makes sense for Unix. However, on Cygwin, executables get an .exe extension. This causes a problem during the configuration step (python setup.py config), in which some temporary executables may be generated. As unixccompiler.py does not know about the .exe extension, distutils fails to clean up after itself: it does not remove _configtest.exe but tries to remove _configtest instead. The attached patch to unixccompiler.py sets the correct exe_extension for cygwin by checking if sys.platform is 'cygwin'. With this patch, distutils cleans up after itself correctly. Michiel de Hoon University of Tokyo, Human Genome Center. ---------------------------------------------------------------------- >Comment By: Michiel de Hoon (mdehoon) Date: 2003-04-12 20:16 Message: Logged In: YES user_id=488897 I don't know why unixccompiler is being used, you'd have to ask the person who wrote unixccompiler / cygwinccompiler. If I use "python setup.py build" on cygwin, it uses unixccompiler. I can force it to use cygwinccompiler by using "python setup.py build --compiler=cygwin". (BTW, that currently seems to be broken, the compilation fails during the linking stage). My guess is that if unixccompiler works on cygwin (which it does, except for the cleanup problem), there is no reason to have a separate cygwinccompiler. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-12 19:40 Message: Logged In: YES user_id=21627 Can you explain wh unixccompiler is used? cygwincompiler should be used instead... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 From noreply@sourceforge.net Sat Apr 12 12:30:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Apr 2003 04:30:34 -0700 Subject: [Patches] [ python-Patches-718049 ] Setting exe_extension for cygwin Message-ID: Patches item #718049, was opened at 2003-04-09 09:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Jason Tishler (jlt63) Summary: Setting exe_extension for cygwin Initial Comment: On cygwin, the setup.py script uses unixccompiler.py for compiling and linking C extensions. The unixccompiler.py script assumes that executables do not get special extensions, which makes sense for Unix. However, on Cygwin, executables get an .exe extension. This causes a problem during the configuration step (python setup.py config), in which some temporary executables may be generated. As unixccompiler.py does not know about the .exe extension, distutils fails to clean up after itself: it does not remove _configtest.exe but tries to remove _configtest instead. The attached patch to unixccompiler.py sets the correct exe_extension for cygwin by checking if sys.platform is 'cygwin'. With this patch, distutils cleans up after itself correctly. Michiel de Hoon University of Tokyo, Human Genome Center. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-12 13:30 Message: Logged In: YES user_id=21627 Jason, any opinion? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-04-12 13:16 Message: Logged In: YES user_id=488897 I don't know why unixccompiler is being used, you'd have to ask the person who wrote unixccompiler / cygwinccompiler. If I use "python setup.py build" on cygwin, it uses unixccompiler. I can force it to use cygwinccompiler by using "python setup.py build --compiler=cygwin". (BTW, that currently seems to be broken, the compilation fails during the linking stage). My guess is that if unixccompiler works on cygwin (which it does, except for the cleanup problem), there is no reason to have a separate cygwinccompiler. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-12 12:40 Message: Logged In: YES user_id=21627 Can you explain wh unixccompiler is used? cygwincompiler should be used instead... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 From noreply@sourceforge.net Sat Apr 12 13:42:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Apr 2003 05:42:49 -0700 Subject: [Patches] [ python-Patches-720188 ] proposed patch for posixpath.py: getctime() Message-ID: Patches item #720188, was opened at 2003-04-12 12:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720188&group_id=5470 Category: Modules Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Jose' Manuel Sebrosa (sebrosa) Assigned to: Nobody/Anonymous (nobody) Summary: proposed patch for posixpath.py: getctime() Initial Comment: I am using python 2.1.3 from debian woody. The module posixpath defines getatime() and getmtime() functions, but it lacks a similar getctime(). Here is my proposed patch to add getctime() to posixpath. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720188&group_id=5470 From noreply@sourceforge.net Sat Apr 12 14:43:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Apr 2003 06:43:11 -0700 Subject: [Patches] [ python-Patches-558745 ] GC: untrack simple objects Message-ID: Patches item #558745, was opened at 2002-05-21 16:10 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558745&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: GC: untrack simple objects Initial Comment: This patch makes the GC untrack tuples that contain no GC objects. Unfortunately it doesn't seem to help much. The time for the 'storetups' case of iterzip.py seems be about twice as fast (matching Daniel Dunbar result). Loading a number of complex MEMS Exchange web pages causes the size of gen2 to go up to 120000 instead of 134000 without the patch. This change doesn't seem to be worth making. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-04-12 13:43 Message: Logged In: YES user_id=35752 I'm not since it doesn't seem to help much. It looks like no one else is either. Closing it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 01:16 Message: Logged In: YES user_id=33168 Neil, are you still interested in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558745&group_id=5470 From noreply@sourceforge.net Sat Apr 12 19:41:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Apr 2003 11:41:02 -0700 Subject: [Patches] [ python-Patches-720329 ] Patch to make shlex accept escaped strings. Message-ID: Patches item #720329, was opened at 2003-04-12 14:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720329&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to make shlex accept escaped strings. Initial Comment: Shlex currently has no way to escape quoting characters within strings. This fixes that. No test is provided, but I'll be willing to write a test module to test this and the other basic behavior of the shlex module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720329&group_id=5470 From noreply@sourceforge.net Sat Apr 12 19:42:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Apr 2003 11:42:40 -0700 Subject: [Patches] [ python-Patches-720329 ] Patch to make shlex accept escaped quotes in strings. Message-ID: Patches item #720329, was opened at 2003-04-12 14:41 Message generated for change (Settings changed) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720329&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) >Summary: Patch to make shlex accept escaped quotes in strings. Initial Comment: Shlex currently has no way to escape quoting characters within strings. This fixes that. No test is provided, but I'll be willing to write a test module to test this and the other basic behavior of the shlex module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720329&group_id=5470 From noreply@sourceforge.net Sun Apr 13 01:34:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Apr 2003 17:34:18 -0700 Subject: [Patches] [ python-Patches-720468 ] nntplib file output for multiline commands Message-ID: Patches item #720468, was opened at 2003-04-13 00:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720468&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Terry Carroll (tcarroll) Assigned to: Nobody/Anonymous (nobody) Summary: nntplib file output for multiline commands Initial Comment: This patch extends the support for file output, currently supported only for the body() method (added by Travers Naran in patch 462628) to all the other methods that invoke NNTP commands that produce multiline output; in particular: newgroups(), newnews(), list(), help(), xhdr(), xgtitle() and xover(). Many of these commands, especially list(), newgroups() and xhdr(), produce a large amount of output, and requiring that the output be maintained in memory, as in the present implementation, may impair performance of the application or the entire system, in limited-resource configurations. Routing the output to a file avoids this (and, if the file object is actually a subclass of the file class, the programmer can supply a write method that processes the NNTP command output as it is produced). The file parameter added by this patch is consistent with its present use in the body() method, specifying either a string containing a file name, or an open file object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720468&group_id=5470 From noreply@sourceforge.net Sun Apr 13 06:23:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Apr 2003 22:23:51 -0700 Subject: [Patches] [ python-Patches-558745 ] GC: untrack simple objects Message-ID: Patches item #558745, was opened at 2002-05-21 12:10 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558745&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 3 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Nobody/Anonymous (nobody) Summary: GC: untrack simple objects Initial Comment: This patch makes the GC untrack tuples that contain no GC objects. Unfortunately it doesn't seem to help much. The time for the 'storetups' case of iterzip.py seems be about twice as fast (matching Daniel Dunbar result). Loading a number of complex MEMS Exchange web pages causes the size of gen2 to go up to 120000 instead of 134000 without the patch. This change doesn't seem to be worth making. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-04-13 01:23 Message: Logged In: YES user_id=31435 Unassigned. I agree with closing it, BTW -- it wasn't hot or cold, it just seemed so neutral it was depressing . ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-04-12 09:43 Message: Logged In: YES user_id=35752 I'm not since it doesn't seem to help much. It looks like no one else is either. Closing it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:16 Message: Logged In: YES user_id=33168 Neil, are you still interested in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558745&group_id=5470 From noreply@sourceforge.net Sun Apr 13 10:07:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Apr 2003 02:07:36 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 11:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Sun Apr 13 12:02:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Apr 2003 04:02:12 -0700 Subject: [Patches] [ python-Patches-720585 ] iconv_codec 3rd generation Message-ID: Patches item #720585, was opened at 2003-04-13 20:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720585&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: iconv_codec 3rd generation Initial Comment: Full featured and standalone iconv_codec implementation. - Supports UCS, UCS-SWAPPED, UTF-8 unicode encodings with runtime detection. - Supports even _sane_ StreamReader and StreamWriter. Tested on {Free,Net}BSD, Debian Linux, MacOS X, Solaris 9 and Cygwin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720585&group_id=5470 From noreply@sourceforge.net Sun Apr 13 12:29:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Apr 2003 04:29:31 -0700 Subject: [Patches] [ python-Patches-720585 ] iconv_codec 3rd generation Message-ID: Patches item #720585, was opened at 2003-04-13 20:02 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720585&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: iconv_codec 3rd generation Initial Comment: Full featured and standalone iconv_codec implementation. - Supports UCS, UCS-SWAPPED, UTF-8 unicode encodings with runtime detection. - Supports even _sane_ StreamReader and StreamWriter. Tested on {Free,Net}BSD, Debian Linux, MacOS X, Solaris 9 and Cygwin ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2003-04-13 20:29 Message: Logged In: YES user_id=55188 If the poor libiconv implementations are concerned, how about enabling iconv_codec only on platforms that we can expect sane iconv? - if platform not in ['darwin'] and iconv_incs is not None: + if platform in ['freebsd3', 'freebsd4', 'freebsd5', 'netbsd1', + 'linux2', 'sunos5'] and iconv_incs is not None: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720585&group_id=5470 From noreply@sourceforge.net Mon Apr 14 10:14:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 02:14:35 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 09:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Nobody/Anonymous (nobody) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Mon Apr 14 13:31:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 05:31:31 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 14:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 11:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Mon Apr 14 13:41:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 05:41:25 -0700 Subject: [Patches] [ python-Patches-721061 ] Add copyrange method to array. Message-ID: Patches item #721061, was opened at 2003-04-14 22:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721061&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add copyrange method to array. Initial Comment: The split buffer data structure commonly used in text editors to efficiently manipulate text and data attached to that text can be implemented using the Python array type with the addition of a way to rapidly copy data within arrays. There may be other situations in which rapidly copying blocks within an array is useful. -- Neil Hodgson ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721061&group_id=5470 From noreply@sourceforge.net Mon Apr 14 14:00:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 06:00:57 -0700 Subject: [Patches] [ python-Patches-718049 ] Setting exe_extension for cygwin Message-ID: Patches item #718049, was opened at 2003-04-08 23:45 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Jason Tishler (jlt63) Summary: Setting exe_extension for cygwin Initial Comment: On cygwin, the setup.py script uses unixccompiler.py for compiling and linking C extensions. The unixccompiler.py script assumes that executables do not get special extensions, which makes sense for Unix. However, on Cygwin, executables get an .exe extension. This causes a problem during the configuration step (python setup.py config), in which some temporary executables may be generated. As unixccompiler.py does not know about the .exe extension, distutils fails to clean up after itself: it does not remove _configtest.exe but tries to remove _configtest instead. The attached patch to unixccompiler.py sets the correct exe_extension for cygwin by checking if sys.platform is 'cygwin'. With this patch, distutils cleans up after itself correctly. Michiel de Hoon University of Tokyo, Human Genome Center. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-04-14 05:00 Message: Logged In: YES user_id=86216 loewis> Jason, any opinion? This patch seems fine to me -- at least, it does not break the Cygwin Python build. I'm willing to apply. mdehoon> I don't know why unixccompiler is being mdehoon> used, >From my point of view, Cygwin is just another Unix. So, it should use UnixCCompiler and not CygwinCCompiler. mdehoon> you'd have to ask the person who mdehoon> wrote unixccompiler / cygwinccompiler. IIRC, Rene Liebscher is the author of CygwinCCompiler. Is he still around? loewis> Can you explain wh unixccompiler is used? loewis> cygwincompiler should be used instead... See above. I always thought that CygwinCCompiler and Mingw32CCompiler where used to build Win32 Python extensions with gcc. Although, I must admit to never understanding the use for CygwinCCompiler. I must be missing something... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-12 03:30 Message: Logged In: YES user_id=21627 Jason, any opinion? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-04-12 03:16 Message: Logged In: YES user_id=488897 I don't know why unixccompiler is being used, you'd have to ask the person who wrote unixccompiler / cygwinccompiler. If I use "python setup.py build" on cygwin, it uses unixccompiler. I can force it to use cygwinccompiler by using "python setup.py build --compiler=cygwin". (BTW, that currently seems to be broken, the compilation fails during the linking stage). My guess is that if unixccompiler works on cygwin (which it does, except for the cleanup problem), there is no reason to have a separate cygwinccompiler. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-12 02:40 Message: Logged In: YES user_id=21627 Can you explain wh unixccompiler is used? cygwincompiler should be used instead... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 From noreply@sourceforge.net Mon Apr 14 14:10:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 06:10:04 -0700 Subject: [Patches] [ python-Patches-709178 ] remove -static option from cygwinccompiler Message-ID: Patches item #709178, was opened at 2003-03-24 17:55 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709178&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Kabir Luebs (jkluebs) Assigned to: Jason Tishler (jlt63) Summary: remove -static option from cygwinccompiler Initial Comment: Currently, the cygwinccompiler.py compiler handling in distutils is invoking the cygwin and mingw compilers with the -static option. Logically, this means that the linker should choose to link to static libraries instead of shared/dynamically linked libraries. Current win32 binutils expect import libraries to have a .dll.a suffix and static libraries to have .a suffix. If -static is passed, it will skip the .dll.a libraries. This is pain if one has a tree with both static and dynamic libraries using this naming convention, and wish to use the dynamic libraries. The -static option being passed in distutils is to get around a bug in old versions of binutils where it would get confused when it found the DLLs themselves. The decision to use static or shared libraries is site or package specific, and should be left to the setup script or to command line options. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-04-14 05:10 Message: Logged In: YES user_id=86216 Checked in as Lib/distutils/cygwinccompiler.py 1.24. I guess that no news is good news... :,) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-04-10 08:19 Message: Logged In: YES user_id=86216 After some more reflection, I would like to revert the original patch and apply my version, cygwinccompiler.py-shared.diff, instead. My reasons are the following: 1. support for older toolchains is retained 2. support for new toolchains (i.e., ld -shared) is added The goal of my approach is to avoid breaking older toolchains while adding better support for newer ones. John and/or anyone else, is my approach acceptable? Can you find any problems with it? Thanks. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-04-09 08:23 Message: Logged In: YES user_id=86216 Checked in as Lib/distutils/cygwinccompiler.py 1.22. Sorry, for sluggish response time. I will create separate SF patches for the forthcoming, related patches. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-04-01 10:11 Message: Logged In: YES user_id=86216 Martin, Thanks for your approval. I would like to check in the changes in parts. For example: 1. John's remove -static patch. 2. my get_versions() fix patch 3. my -shared patch 4. etc. In this way, I can more easily roll back if I goof. Can I just attach more patches to this one? Or, should I create a new SF patch for each of my patches? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 12:33 Message: Logged In: YES user_id=21627 jlt63: Your proposed changes all sound fine. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-31 08:02 Message: Logged In: YES user_id=86216 jkluebs> I can help with testing. I have access to W2K jkluebs> and Win98 (ugh) boxen. I don't mind jkluebs> installing a few older toolchains if you jkluebs> think that's necessary. Thanks for the offer. I'm set up for the current Cygwin and Mingw tool chains. Let's wait to see if testing with older ones is necessary. jkluebs> I think any C/C++ python extension using jkluebs> plain distutils (no fancy hacks added on) and jkluebs> has one or more DLL dependencies is a good jkluebs> test case. Can you point me to one that builds OOTB under Python 2.2.2? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-31 07:58 Message: Logged In: YES user_id=86216 loewis> I'm in favour of applying this patch, and loewis> also of patches that mandate recent Cygwin loewis> releases; I would like to apply an enhanced version of this patch. By enhanced, I mean using "gcc -shared" (no more dllwrap and gcc -mdll) and removing redundant gcc options, etc. Additionally, I would like to fix get_versions() so it can deal with versions that only have two components (e.g., 3.2) as opposed to requiring three (e.g. 2.95.3). Are these changes acceptable? loewis> if such patches are implemented, the minimum loewis> required Cygwin version should be stated loewis> somewhere. I propose that the currently available Cygwin and Mingw tool chains be that above stated minimum. Is this acceptable? Unfortunately, I have no idea where the above stated "somewhere" shoud be. ---------------------------------------------------------------------- Comment By: John Kabir Luebs (jkluebs) Date: 2003-03-28 14:31 Message: Logged In: YES user_id=87160 I can help with testing. I have access to W2K and Win98 (ugh) boxen. I don't mind installing a few older toolchains if you think that's necessary. I think any C/C++ python extension using plain distutils (no fancy hacks added on) and has one or more DLL dependencies is a good test case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-28 13:15 Message: Logged In: YES user_id=21627 I'm in favour of applying this patch, and also of patches that mandate recent Cygwin releases; if such patches are implemented, the minimum required Cygwin version should be stated somewhere. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-28 12:16 Message: Logged In: YES user_id=86216 John, would you be willing to help test or supply me with test cases? I have built exactly one Win32 extension. ---------------------------------------------------------------------- Comment By: John Kabir Luebs (jkluebs) Date: 2003-03-28 11:56 Message: Logged In: YES user_id=87160 The -mdll --entry DllMain@12 option is guarded for an old version of gcc that did not have the correct specs to accept -shared. I didn't touch it, even though it's crazy if anyone is using such an old and buggy toolchain. --shared and --dll are equivalent as far as ld is concerned. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-28 09:41 Message: Logged In: YES user_id=86216 Note that I only have minimal experience building Win32 extensions modules... This patch works "fine" with my *very* limited testing. Specifically, I successfully rebuilt the Win32 readline module with it applied. BTW, this area of Distutils probably should be revisited to bring it up to date. For example, the "-mdll --entry _DllMain@12" options could be replaced by "-shared". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 15:03 Message: Logged In: YES user_id=21627 Jason, can you take a look? If not, please unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709178&group_id=5470 From noreply@sourceforge.net Mon Apr 14 14:26:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 06:26:40 -0700 Subject: [Patches] [ python-Patches-718049 ] Setting exe_extension for cygwin Message-ID: Patches item #718049, was opened at 2003-04-09 09:45 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Jason Tishler (jlt63) Summary: Setting exe_extension for cygwin Initial Comment: On cygwin, the setup.py script uses unixccompiler.py for compiling and linking C extensions. The unixccompiler.py script assumes that executables do not get special extensions, which makes sense for Unix. However, on Cygwin, executables get an .exe extension. This causes a problem during the configuration step (python setup.py config), in which some temporary executables may be generated. As unixccompiler.py does not know about the .exe extension, distutils fails to clean up after itself: it does not remove _configtest.exe but tries to remove _configtest instead. The attached patch to unixccompiler.py sets the correct exe_extension for cygwin by checking if sys.platform is 'cygwin'. With this patch, distutils cleans up after itself correctly. Michiel de Hoon University of Tokyo, Human Genome Center. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-04-14 15:26 Message: Logged In: YES user_id=11105 jlt63: IIRC, Rene Liebscher is the author of CygwinCCompiler. Is he still around? Sometimes he shows up on distutils-sig. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-04-14 15:00 Message: Logged In: YES user_id=86216 loewis> Jason, any opinion? This patch seems fine to me -- at least, it does not break the Cygwin Python build. I'm willing to apply. mdehoon> I don't know why unixccompiler is being mdehoon> used, >From my point of view, Cygwin is just another Unix. So, it should use UnixCCompiler and not CygwinCCompiler. mdehoon> you'd have to ask the person who mdehoon> wrote unixccompiler / cygwinccompiler. IIRC, Rene Liebscher is the author of CygwinCCompiler. Is he still around? loewis> Can you explain wh unixccompiler is used? loewis> cygwincompiler should be used instead... See above. I always thought that CygwinCCompiler and Mingw32CCompiler where used to build Win32 Python extensions with gcc. Although, I must admit to never understanding the use for CygwinCCompiler. I must be missing something... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-12 13:30 Message: Logged In: YES user_id=21627 Jason, any opinion? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-04-12 13:16 Message: Logged In: YES user_id=488897 I don't know why unixccompiler is being used, you'd have to ask the person who wrote unixccompiler / cygwinccompiler. If I use "python setup.py build" on cygwin, it uses unixccompiler. I can force it to use cygwinccompiler by using "python setup.py build --compiler=cygwin". (BTW, that currently seems to be broken, the compilation fails during the linking stage). My guess is that if unixccompiler works on cygwin (which it does, except for the cleanup problem), there is no reason to have a separate cygwinccompiler. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-12 12:40 Message: Logged In: YES user_id=21627 Can you explain wh unixccompiler is used? cygwincompiler should be used instead... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 From noreply@sourceforge.net Mon Apr 14 17:46:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 09:46:53 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 05:14 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Gary Herron (herron) >Assigned to: Guido van Rossum (gvanrossum) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 12:46 Message: Logged In: YES user_id=6380 Will look at this ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Mon Apr 14 17:53:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 09:53:02 -0700 Subject: [Patches] [ python-Patches-643711 ] refactoring and documenting ModuleFinder Message-ID: Patches item #643711, was opened at 2002-11-25 19:52 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=643711&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: refactoring and documenting ModuleFinder Initial Comment: This is not (yet) a complete patch, it is thought as a workspace for improvements to tools/freeze/moduulefinder, so that it can eventually go into the standard library. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-04-14 18:53 Message: Logged In: YES user_id=11105 I think it can be closed (although the docs are still missing). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:36 Message: Logged In: YES user_id=33168 What's the status of this patch now that modulefinder.py has been moved into the library? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-29 11:16 Message: Logged In: YES user_id=92689 Here's a revised patch. The previous version actually was too lenient: it could list submodules as "maybe missing" when they were missing for sure. Fixed by tracking unresolvable starimports. (Removed the module.badimports attribute of my previous patch, it now uses mf.badimports appropriately.) Meta question: are we going to commit fixes to modulefinder.py in the freeze directory and do the move when the doco is done, or do we not commit anything until we're ready for the move? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-28 21:28 Message: Logged In: YES user_id=11105 Just, I trust your analysis while I don't understand it ;-). Thinking more about my "ignore" concept shows that it is unneeded. Warnings can be better removed after modulefinder has been run by examining the data it collects. To answer your question: "excludes" does not mean 'may be missed', it means 'must be excluded' IMO, and no, this was not the purpose of my patch. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-28 21:17 Message: Logged In: YES user_id=92689 Thomas, your _add_badmodule patch actually broke my code... It took me a while to figure out why, and while at it, I discovered a blatant stupidity in my own patch: somehow I completely overlooked the fact that mf.badmodules already references the modules that did the failed import, so my module.badimports thing can go. It does the exact same thing. Almost... and your patch made that clear: the lines that you patched actually make the badmodules reference lie (and with your patch it also makes mod.badimports lie ;-): if module X imports Y.Z, and Z isn't found, it lists Y as an importer of Y.Z, which isn't true. My any_maybe_missing() code needs to know whether the __init__.py tried to failed import _itself_, because if it did (and failed) it's certain that the submodule is missing. But if it _didn't_, the "missing submodule" should be listed as "maybe missing", as it's most likely just a global in the __init__.py. I'll try to revise my patch tomorrow, it should become simpler. In the meantime I think it might indeed be useful to distinguish between "may be missed" and "must be excluded". Is that what your "ignore" patch tried to do? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-28 19:22 Message: Logged In: YES user_id=92689 What's the difference between this "ignore" variable and the "exclude" list? And why do you need to ignore modules based on importing module? In my OSX appbuilder stuff I simply have a list of modules that will be removed from the 'missing' list when reporting: MAYMISS_MODULES = ['mac', 'os2', 'nt', 'ntpath', 'dos', 'dospath', 'win32api', 'ce', '_winreg', 'nturl2path', 'sitecustomize', 'org.python.core', 'riscos', 'riscosenviron', 'riscospath' ] (I think I could just add this to the exclude list and get the same effect.) Let's please keep it simple! ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-28 13:04 Message: Logged In: YES user_id=11105 Now that it works really fine, I would like to make progress. This new patch 'thomas1.patch' is against the patched modulefinder, it is easier to read this way. First it passes all changes to self.badmodules through the _add_badmodule() method. Then, and this part is not really polished, but you may get the idea, it introduces a new ignored instance variable which is thought to suppress most of the remaining missing modules warnings. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-27 12:02 Message: Logged In: YES user_id=92689 Whoops, that was a useless patch :-( I managed to forgot to copy the last three lines of the original scan_code() which takes care of delayed imports... Fixed in the new patch. I now also patched Modulefinder.report() to actually use the new any_missing_maybe() feature. (Note for the lib doco to be written: we should document that people should use any_missing[_maybe]() instead of looking directly at mf.badmodules. mf.badmodules is the raw list, any_missing_maybe() filters out the false positives.) I've ran before/after tests on all of Lib/*.py and Lib/test_*.py and the only differences I found are those that this patch address, ie. less false positives when reporting missing modules. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-27 09:27 Message: Logged In: YES user_id=11105 Running the current CVS ModuleFinder on a simple script which contains 'import os' with Python 2.2 on Win2k finds 27 modules, while with this patch it only finds 13. (and unassign Mark) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-27 02:30 Message: Logged In: YES user_id=92689 Oh, I just realized ModuleFinder.report() should still be patched to use any_missing(), or even better, any_missing_maybe(). Will do if this gets through. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-27 02:26 Message: Logged In: YES user_id=92689 Here's a patch. Summary: any_missing() returns less bogus modules. - I've rewritten scan_code() more or less from scratch, factored bits and pieces out for readability. - keep track of global assignments and failed imports per module; use this to determine whether the Y in "from X import Y" is a submodule or just a global name. This is not 100% doable: you can't tell which symbols are imported when doing a star import of a non-Python module short of actually importing it. - added a new method to ModuleFinder: any_missing_maybe(), which returns *two* lists, one with certain misses, one with possible misses. The possible misses are *very* often false alarms, so it's useful to keep this list separate. any_misses() now simply returns the union of any_missing_maybe(). I pretty sure this is all 100% backward compatible, so after some more testing it could be checked in. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-26 09:11 Message: Logged In: YES user_id=11105 I've removed in current CVS the support for modules listed in the registry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-26 08:57 Message: Logged In: YES user_id=11105 Mark writes in private email: "Modules listed in the registry was a dumb idea. This whole scheme can die. AFAIK, no one in the world uses it (including win32all since the last build)." ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-25 20:59 Message: Logged In: YES user_id=11105 Assign to Mark, hoping for an answer. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-25 19:58 Message: Logged In: YES user_id=11105 First question for anyone listening: isn't the windows _try_registry stuff unneeded, because imp.find_module handles this itself? Even in python15, imp.find_module ("pythoncom") returns 'c:\winnt\system32\pythoncom15.dll' on my system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=643711&group_id=5470 From noreply@sourceforge.net Mon Apr 14 19:15:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 11:15:53 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 05:14 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: Gary Herron (herron) >Assigned to: Fredrik Lundh (effbot) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 14:15 Message: Logged In: YES user_id=6380 Looks cool; I've checked this in unchanged, except changing one comment: the comment about the test for bug 545855 said it would generate errors during matching, while when I try it, the pattern generates a TypeError during compilation. I don't feel capable to review the code you added to _sre.c; I'll assign it to Fredrik, but I don't expect him to have time to look at it. It seems you haven't broken his requirement for this code to work back to Python 1.5.2. I'll backport to Python 2.2 as well. Do I understand correctly that the .*? addition is all Greg Chapman's work? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 12:46 Message: Logged In: YES user_id=6380 Will look at this ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Mon Apr 14 20:50:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 12:50:03 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 05:14 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Fredrik Lundh (effbot) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 15:50 Message: Logged In: YES user_id=6380 Gary, I wonder if you could rework your fix for Python 2.2? The patch doesn't apply cleanly there; one of the problems is that lastmark_restore() doesn't exist. I wonder if maybe all of the _sre.c code should simply be copied to the 2.2 branch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 14:15 Message: Logged In: YES user_id=6380 Looks cool; I've checked this in unchanged, except changing one comment: the comment about the test for bug 545855 said it would generate errors during matching, while when I try it, the pattern generates a TypeError during compilation. I don't feel capable to review the code you added to _sre.c; I'll assign it to Fredrik, but I don't expect him to have time to look at it. It seems you haven't broken his requirement for this code to work back to Python 1.5.2. I'll backport to Python 2.2 as well. Do I understand correctly that the .*? addition is all Greg Chapman's work? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 12:46 Message: Logged In: YES user_id=6380 Will look at this ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Mon Apr 14 21:44:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 13:44:38 -0700 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 13:03 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open >Resolution: Remind >Priority: 5 Submitted By: Jon Riehl (jriehl) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 16:44 Message: Logged In: YES user_id=6380 OK, reading the README now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-05 11:42 Message: Logged In: YES user_id=6380 Closed. Jon, if you're still interested in this, upload something new and reopen the patch (or I can do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 12:32 Message: Logged In: YES user_id=6380 Lowering priority until Jon has his next version ready. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-13 00:35 Message: Logged In: YES user_id=6380 Cool. Maybe I'll get to it, maybe not. :-( ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2002-09-12 14:04 Message: Logged In: YES user_id=22448 Guido, as per my private message, I'll attempt to submit another patch by the end of the month, pending resumption of "work" on the 23rd. Commitment of the memory allocation patch is fine, and any future patches would be against the updated pgen code (I don't have commit permissions, so someone else will have to do this possibly.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 08:09 Message: Logged In: YES user_id=6380 I looked a bit, and it's very raw - the author admits that. Jon, are you still working on this? Do you have a more polished version? Maybe we can separate out the memory allocation patches and commit these already? They don't break anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply@sourceforge.net Mon Apr 14 22:29:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 14:29:33 -0700 Subject: [Patches] [ python-Patches-721425 ] Enhanced bytecode optimizer Message-ID: Patches item #721425, was opened at 2003-04-14 16:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721425&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Enhanced bytecode optimizer Initial Comment: Enhanced the bytecode optimizer to mark basic blocks, apply more transformations, and to fix-up jump targets when the code size gets shorter. Old transformations no longer require filler codes. New transformations: RETURN_VALUE LOAD_CONST x RETURN_VALUE -- > RETURN_VALUE BUILD_SEQN 3 UNPACK_SEQN 3 --> ROT3 ROT2 not x in y --> x not in y not x not in y --> x in y not x is y --> x is not y not x is not y --> x is y ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721425&group_id=5470 From noreply@sourceforge.net Tue Apr 15 00:02:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 16:02:36 -0700 Subject: [Patches] [ python-Patches-721464 ] Remote debugging with pdb.py Message-ID: Patches item #721464, was opened at 2003-04-14 19:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pelecq (lpelecq) Assigned to: Nobody/Anonymous (nobody) Summary: Remote debugging with pdb.py Initial Comment: With this patch, instances of pdb.Pdb can read and write from arbitrary file objects. It is based on similar changes that have been made to cmd.py. It basically consists of replacing print statement with calls to self.stdout.write. So it is possible for example to control the debugger from another terminal to debug curses-based applications or CGI scripts. I can provide a basic client/server debugger. This patch has been tested on Mandrake Linux 9.1 with the current CVS version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&group_id=5470 From noreply@sourceforge.net Tue Apr 15 00:09:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 16:09:48 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-14 19:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 08:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 05:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 05:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 04:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 14:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 10:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 08:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 12:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 08:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-20 22:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 13:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 04:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 15:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 06:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 03:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 13:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 18:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Tue Apr 15 01:18:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Apr 2003 17:18:12 -0700 Subject: [Patches] [ python-Patches-721425 ] Enhanced bytecode optimizer Message-ID: Patches item #721425, was opened at 2003-04-14 16:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721425&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Pending >Resolution: Later Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Enhanced bytecode optimizer Initial Comment: Enhanced the bytecode optimizer to mark basic blocks, apply more transformations, and to fix-up jump targets when the code size gets shorter. Old transformations no longer require filler codes. New transformations: RETURN_VALUE LOAD_CONST x RETURN_VALUE -- > RETURN_VALUE BUILD_SEQN 3 UNPACK_SEQN 3 --> ROT3 ROT2 not x in y --> x not in y not x not in y --> x in y not x is y --> x is not y not x is not y --> x is y ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-14 19:18 Message: Logged In: YES user_id=80475 Hmm, I'm going to take this one off the table for while. Right now, it gives too little extra benefit for all the additional code. Also, it looks like removing a bytes means that the line numbering logic needs to be adjusted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721425&group_id=5470 From noreply@sourceforge.net Tue Apr 15 12:30:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Apr 2003 04:30:54 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 13:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-15 01:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 14:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 11:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Tue Apr 15 17:50:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Apr 2003 09:50:09 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 09:14 Message generated for change (Comment added) made by herron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Fredrik Lundh (effbot) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- >Comment By: Gary Herron (herron) Date: 2003-04-15 16:50 Message: Logged In: YES user_id=395736 Sure, I'll port it to Python2.2. I'm surprised it dod not apply cleanly there, but then I don't know the history of previous patches (like when lastmark_restore was introduced). I guess copying all sre code will be the first thing to try. How do I get a dev version of Python 2.2? Yes, the *? code is all Greg Chapman's. He sent it to me the day I announced my volunteering to maintain the sre code. I wrote the test cases for it, and used it as a great way to learn my way through the code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 19:50 Message: Logged In: YES user_id=6380 Gary, I wonder if you could rework your fix for Python 2.2? The patch doesn't apply cleanly there; one of the problems is that lastmark_restore() doesn't exist. I wonder if maybe all of the _sre.c code should simply be copied to the 2.2 branch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 18:15 Message: Logged In: YES user_id=6380 Looks cool; I've checked this in unchanged, except changing one comment: the comment about the test for bug 545855 said it would generate errors during matching, while when I try it, the pattern generates a TypeError during compilation. I don't feel capable to review the code you added to _sre.c; I'll assign it to Fredrik, but I don't expect him to have time to look at it. It seems you haven't broken his requirement for this code to work back to Python 1.5.2. I'll backport to Python 2.2 as well. Do I understand correctly that the .*? addition is all Greg Chapman's work? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 16:46 Message: Logged In: YES user_id=6380 Will look at this ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Tue Apr 15 19:41:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Apr 2003 11:41:30 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 05:14 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Fredrik Lundh (effbot) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-15 14:41 Message: Logged In: YES user_id=6380 The Python 2.2 maintenance branch is labeled with the CVS tag 'release22-maint'. I hope you know or can find out about working with CVS branches. Good luck! ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-15 12:50 Message: Logged In: YES user_id=395736 Sure, I'll port it to Python2.2. I'm surprised it dod not apply cleanly there, but then I don't know the history of previous patches (like when lastmark_restore was introduced). I guess copying all sre code will be the first thing to try. How do I get a dev version of Python 2.2? Yes, the *? code is all Greg Chapman's. He sent it to me the day I announced my volunteering to maintain the sre code. I wrote the test cases for it, and used it as a great way to learn my way through the code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 15:50 Message: Logged In: YES user_id=6380 Gary, I wonder if you could rework your fix for Python 2.2? The patch doesn't apply cleanly there; one of the problems is that lastmark_restore() doesn't exist. I wonder if maybe all of the _sre.c code should simply be copied to the 2.2 branch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 14:15 Message: Logged In: YES user_id=6380 Looks cool; I've checked this in unchanged, except changing one comment: the comment about the test for bug 545855 said it would generate errors during matching, while when I try it, the pattern generates a TypeError during compilation. I don't feel capable to review the code you added to _sre.c; I'll assign it to Fredrik, but I don't expect him to have time to look at it. It seems you haven't broken his requirement for this code to work back to Python 1.5.2. I'll backport to Python 2.2 as well. Do I understand correctly that the .*? addition is all Greg Chapman's work? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 12:46 Message: Logged In: YES user_id=6380 Will look at this ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Tue Apr 15 19:47:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Apr 2003 11:47:01 -0700 Subject: [Patches] [ python-Patches-722017 ] Enhance htmlentitydefs Message-ID: Patches item #722017, was opened at 2003-04-15 20:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722017&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Martin v. Löwis (loewis) Summary: Enhance htmlentitydefs Initial Comment: This new version adds two dictionaries to htmlentitydefs.py: name2codepoint maps entity names to Unicode codepoints (as integers). codepoint2name is the reverse mapping. The distinction between codepoint<256 and codepoint>=256 that entitydefs used is removed. entitydefs is still defined (and generated from name2codepoint) for backwards compatibility. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722017&group_id=5470 From noreply@sourceforge.net Tue Apr 15 19:47:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Apr 2003 11:47:33 -0700 Subject: [Patches] [ python-Patches-722017 ] Enhance htmlentitydefs Message-ID: Patches item #722017, was opened at 2003-04-15 20:47 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722017&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Martin v. Löwis (loewis) Summary: Enhance htmlentitydefs Initial Comment: This new version adds two dictionaries to htmlentitydefs.py: name2codepoint maps entity names to Unicode codepoints (as integers). codepoint2name is the reverse mapping. The distinction between codepoint<256 and codepoint>=256 that entitydefs used is removed. entitydefs is still defined (and generated from name2codepoint) for backwards compatibility. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 20:47 Message: Logged In: YES user_id=89016 Patch to the documentation added. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722017&group_id=5470 From noreply@sourceforge.net Tue Apr 15 21:00:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Apr 2003 13:00:38 -0700 Subject: [Patches] [ python-Patches-722017 ] Enhance htmlentitydefs Message-ID: Patches item #722017, was opened at 2003-04-15 20:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722017&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Enhance htmlentitydefs Initial Comment: This new version adds two dictionaries to htmlentitydefs.py: name2codepoint maps entity names to Unicode codepoints (as integers). codepoint2name is the reverse mapping. The distinction between codepoint<256 and codepoint>=256 that entitydefs used is removed. entitydefs is still defined (and generated from name2codepoint) for backwards compatibility. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-15 22:00 Message: Logged In: YES user_id=21627 I'm concerned about the startup costs, but for today's computers, this is probably not relevant anymore Please apply this patch. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 20:47 Message: Logged In: YES user_id=89016 Patch to the documentation added. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722017&group_id=5470 From noreply@sourceforge.net Wed Apr 16 11:04:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Apr 2003 03:04:00 -0700 Subject: [Patches] [ python-Patches-722017 ] Enhance htmlentitydefs Message-ID: Patches item #722017, was opened at 2003-04-15 20:47 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722017&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Enhance htmlentitydefs Initial Comment: This new version adds two dictionaries to htmlentitydefs.py: name2codepoint maps entity names to Unicode codepoints (as integers). codepoint2name is the reverse mapping. The distinction between codepoint<256 and codepoint>=256 that entitydefs used is removed. entitydefs is still defined (and generated from name2codepoint) for backwards compatibility. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-04-16 12:04 Message: Logged In: YES user_id=89016 Checked in as: Misc/NEWS 1.725 Lib/htmlentitydefs.py 1.9 Doc/lib/libhtmllib.tex 1.24 with slight modifications (Comments, delete loop variables from module namespace). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-15 22:00 Message: Logged In: YES user_id=21627 I'm concerned about the startup costs, but for today's computers, this is probably not relevant anymore Please apply this patch. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 20:47 Message: Logged In: YES user_id=89016 Patch to the documentation added. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722017&group_id=5470 From noreply@sourceforge.net Wed Apr 16 13:29:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Apr 2003 05:29:15 -0700 Subject: [Patches] [ python-Patches-722462 ] __class__ assignment for list and dict Message-ID: Patches item #722462, was opened at 2003-04-16 12:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722462&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jiba (jiba) Assigned to: Nobody/Anonymous (nobody) Summary: __class__ assignment for list and dict Initial Comment: This patch fixes the bug #712975 It also fixes an error: when calling compatible_for_assignment() in object_set_class(), old and new arguments were reversed (no consequence, but quite confusing). The following is now allowed: - __class__ assignment on a list or a dict, as long as the new type is a subtype whose subtype_dealloc will call the list / dict dealloc, - __class__ assignment on a subtype of list or dict, as long as the subtype have: - no new slots - no weaklist - no dict - no __del__ test_class_assignment.py is a PyUnit test case for this feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722462&group_id=5470 From noreply@sourceforge.net Wed Apr 16 15:18:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Apr 2003 07:18:11 -0700 Subject: [Patches] [ python-Patches-722462 ] __class__ assignment for list and dict Message-ID: Patches item #722462, was opened at 2003-04-16 08:29 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722462&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jiba (jiba) Assigned to: Nobody/Anonymous (nobody) Summary: __class__ assignment for list and dict Initial Comment: This patch fixes the bug #712975 It also fixes an error: when calling compatible_for_assignment() in object_set_class(), old and new arguments were reversed (no consequence, but quite confusing). The following is now allowed: - __class__ assignment on a list or a dict, as long as the new type is a subtype whose subtype_dealloc will call the list / dict dealloc, - __class__ assignment on a subtype of list or dict, as long as the subtype have: - no new slots - no weaklist - no dict - no __del__ test_class_assignment.py is a PyUnit test case for this feature. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 10:18 Message: Logged In: YES user_id=6380 I'm rejecting this; it's too complicated and I don't care about the functionality. Sorry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722462&group_id=5470 From noreply@sourceforge.net Wed Apr 16 18:49:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Apr 2003 10:49:36 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Wed Apr 16 19:33:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Apr 2003 11:33:55 -0700 Subject: [Patches] [ python-Patches-711448 ] Warn about inter-module assignments shadowing builtins Message-ID: Patches item #711448, was opened at 2003-03-28 17:12 Message generated for change (Settings changed) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Guido van Rossum (gvanrossum) Summary: Warn about inter-module assignments shadowing builtins Initial Comment: The attached patch modifies module tp_setattro to warn about code that adds a name to the globals of another module that shadows a builtin. Unfortunately, there are other ways to modify module globals (e.g. using vars() and mutating the dictionary). There are a few issues with module objects that I'm not clear about. For example, do modules always have a md_dict that is a PyDictObject? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-03-28 17:15 Message: Logged In: YES user_id=35752 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 From noreply@sourceforge.net Wed Apr 16 20:01:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Apr 2003 12:01:42 -0700 Subject: [Patches] [ python-Patches-711448 ] Warn about inter-module assignments shadowing builtins Message-ID: Patches item #711448, was opened at 2003-03-28 12:12 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Warn about inter-module assignments shadowing builtins Initial Comment: The attached patch modifies module tp_setattro to warn about code that adds a name to the globals of another module that shadows a builtin. Unfortunately, there are other ways to modify module globals (e.g. using vars() and mutating the dictionary). There are a few issues with module objects that I'm not clear about. For example, do modules always have a md_dict that is a PyDictObject? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 15:01 Message: Logged In: YES user_id=6380 Hm, it's kind of ugly to list all built-in names explicitly; this list will be out of sync whenever a new built-in is added. Can't you access the __builtin__ module and use its keys? (One way to get the __builtin__ module is to use PySys_GetObject("modules"), which should give you sys.modules, and take it from there; you can count on __builtin__ to be there, and if it's not, forget the whole thing.) ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-03-28 12:15 Message: Logged In: YES user_id=35752 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 From noreply@sourceforge.net Wed Apr 16 20:28:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Apr 2003 12:28:56 -0700 Subject: [Patches] [ python-Patches-722686 ] New shlex functionality Message-ID: Patches item #722686, was opened at 2003-04-16 19:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722686&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Guido van Rossum (gvanrossum) Summary: New shlex functionality Initial Comment: This patch implements the shlex.py features discussed in the mailling list. I'm not sure if "split_args()" is the best name for the introduced function. Any suggestion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722686&group_id=5470 From noreply@sourceforge.net Wed Apr 16 20:53:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Apr 2003 12:53:07 -0700 Subject: [Patches] [ python-Patches-722686 ] New shlex functionality Message-ID: Patches item #722686, was opened at 2003-04-16 15:28 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722686&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: New shlex functionality Initial Comment: This patch implements the shlex.py features discussed in the mailling list. I'm not sure if "split_args()" is the best name for the introduced function. Any suggestion? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 15:53 Message: Logged In: YES user_id=6380 I would call it simply split(), like other splitting functions. Add docs, add unit tests, check it in. We'll see if someone cares. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722686&group_id=5470 From noreply@sourceforge.net Thu Apr 17 00:59:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Apr 2003 16:59:12 -0700 Subject: [Patches] [ python-Patches-722839 ] HAVE_GAI_STRERROR typo fix Message-ID: Patches item #722839, was opened at 2003-04-16 23:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: HAVE_GAI_STRERROR typo fix Initial Comment: This patch fixes a typo in getaddrinfo.c. The #ifdef doesn't match the define in pyconfig.h ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 From yctr@rambler.ru Thu Apr 17 02:43:24 2003 From: yctr@rambler.ru (=?windows-1251?b?1uXt8vAg7uHz9+Xt6P8=?=) Date: Thu, 17 Apr 2003 01:43:24 +0000 Subject: [Patches] =?windows-1251?b?wu3o7ODt6P4g8PPq7uLu5Ojy5evl6Swg4fP14+Dr8uXw7uIsIP7w6PHy7uIhIGR4?= Message-ID: <200304170143.4TOTPQN9@fzhjkrcepo.com> ÏÐÈÃËÀØÀÅÌ ÂÀÑ ÏÎÑÅÒÈÒÜ ÀÊÒÓÀËÜÍÛÅ ÑÅÌÈÍÀÐÛ: 22 àïðåëÿ 2003 ãîäà - <Õîçÿéñòâåííûå äîãîâîðû: áóõãàëòåðñêèé ó÷åò è íàëîãîîáëîæåíèå>, 23 àïðåëÿ 2003 ãîäà - <Ôîðìèðîâàíèå ñåáåñòîèìîñòè>, êîòîðûå ñîñòîÿòñÿ â êîíôåðåíö-çàëå Èíñòèòóòà Èñòîðèè Ðîññèéñêîé Àêàäåìèè Íàóê. Îðãàíèçàòîð ñåìèíàðîâ Ìåæäóíàðîäíûé öåíòð îáó÷åíèÿ. Êîíòàêòíûå òåëåôîíû 207-26-21, 789-81-90, 772-92-46. ÏÐÎÃÐÀÌÌÀ ÑÅÌÈÍÀÐÀ 22 àïðåëÿ 2003 ãîäà - <Õîçÿéñòâåííûå äîãîâîðû: áóõãàëòåðñêèé ó÷åò è íàëîãîîáëîæåíèå>: 1. Ôîðìà è ñîäåðæàíèå ãðàæäàíñêî-ïðàâîâûõ ñäåëîê. Ïðàâîâàÿ ôîðìà ñäåëîê è èõ ýêîíîìè÷åñêîå ñîäåðæàíèå. Íåäåéñòâèòåëüíûå ñäåëêè è èõ íàëîãîâûå ïîñëåäñòâèÿ Ïðèîðèòåò â áóõãàëòåðñêîì ó÷åòå ýêîíîìè÷åñêîãî ñîäåðæàíèÿ íàä ïðàâîâîé ôîðìîé. Ñóùåñòâåííûå óñëîâèÿ äîãîâîðîâ. 2. Îñîáåííîñòè áóõãàëòåðñêîãî ó÷åòà è íàëîãîîáëîæåíèÿ îòäåëüíûõ âèäîâ äîãîâîðîâ: * êóïëè-ïðîäàæè (ìîìåíò ïåðåõîäà ïðàâ ñîáñòâåííîñòè; âîçâðàò òîâàðà; îòëè÷èÿ ìåæäó ðîçíè÷íîé è îïòîâîé òîðãîâëåé; ôîðìèðîâàíèå ñêèäîê ò.ï.); * ìåíû (îñîáåííîñòè îòðàæåíèÿ â ó÷åòå ìåíû è áàðòåðà ïî ÏÁÓ 9/99 è ÏÁÓ 10/99); * àðåíäû (ðàñõîäû ïî ðåìîíòó, ñòðàõîâàíèþ è ñîäåðæàíèþ àðåíäîâàííîãî èìóùåñòâà (âêëþ÷àÿ êîììóíàëüíûå ïëàòåæè), àðåíäà èìóùåñòâà ó ôèçè÷åñêèõ ëèö); * áåçâîçìåçäíîå ïîëüçîâàíèå èìóùåñòâîì (ññóäà); * ïîäðÿä (÷åì êàïèòàëüíûé ðåìîíò îòëè÷àåòñÿ îò ðåêîíñòðóêöèè è ìîäåðíèçàöèè?); * âîçìåçäíîå îêàçàíèå óñëóã (îñîáåííîñòè ó÷åòà ðàñõîäîâ íà îáó÷åíèå, íà îõðàíó, íà ðåêëàìó è íà îïëàòó óñëóã ñâÿçè); * ïîñðåäíè÷åñêèå ñäåëêè (ïîðó÷åíèå, êîìèññèÿ, àãåíòèðîâàíèå, äåéñòâèå â ÷óæîì èíòåðåñå áåç ïîðó÷åíèÿ); * ñòðàõîâàíèå; * ïðî÷èå âèäû ñäåëîê (ïî æåëàíèþ ñëóøàòåëåé áîëåå ïîäðîáíî ìîãóò áûòü ðàññìîòðåíû ëþáûå âèäà ñäåëîê è êîíêðåòíûõ õîçÿéñòâåííûõ äîãîâîðîâ).  õîäå ñåìèíàðà õîçÿéñòâåííûå äîãîâîðû ðàññìàòðèâàþòñÿ ñ òðåõ ïîçèöèé: ïðàâîâîé; áóõãàëòåðñêîé; íàëîãîâîé. Îòäåëüíûå ñïîðíûå ìîìåíòû èëëþñòðèðóþòñÿ ïðèìåðàìè èç ñóäåáíî-àðáèòðàæíîé ïðàêòèêè êàê Âûñøåãî Àðáèòðàæíîãî Ñóäà ÐÔ, òàê è Ôåäåðàëüíûõ àðáèòðàæíûõ ñóäîâ îêðóãîâ Ðîññèè. Íà ñåìèíàðå âûñòóïàåò: ÌÅÄÂÅÄÅ Àëåêñàíäð Íèêîëàåâè÷, ê.ý.í, ãëàâíûé àóäèòîð ÇÀÎ "Àóäèò ÁÒ", àâòîðà 40 êíèã è ñâûøå 200 æóðíàëüíûõ ñòàòåé ïî âîïðîñàì áóõãàëòåðñêîãî ó÷åòà, íàëîãîîáëîæåíèÿ è õîçÿéñòâåííîãî ïðàâà. ÏÐÎÃÐÀÌÌÀ ÑÅÌÈÍÀÐÀ 23 àïðåëÿ 2003 ãîäà <ÔÎÐÌÈÐÎÂÀÍÈÅ ÑÅÁÅÑÒÎÈÌÎÑÒÈ>: 1. Ñîñòàâ è äîêóìåíòèðîâàíèå ðàñõîäîâ. 2. Ðàñõîäû íà ïðîèçâîäñòâî è ðåàëèçàöèþ äëÿ öåëåé áóõãàëòåðñêîãî ó÷åòà - ìàòåðèàëüíûå ðàñõîäû - ðàñõîäû íà îïëàòó òðóäà - îò÷èñëåíèÿ íà ñîöèàëüíûå íóæäû - àìîðòèçàöèÿ - ïðî÷èå ðàñõîäû. 3. Ðàñõîäû, ñâÿçàííûå ñ ïðîèçâîäñòâîì è ðåàëèçàöèåé äëÿ öåëåé íàëîãîîáëîæåíèÿ ïðèáûëè - ìàòåðèàëüíûå ðàñõîäû - ðàñõîäû íà îïëàòó òðóäà - àìîðòèçàöèÿ - ïðî÷èå ðàñõîäû. 4. Ïðàâèëà, óñëîâèÿ è äàòû ïðèçíàíèÿ ðàñõîäîâ â áóõãàëòåðñêîì è íàëîãîâîì ó÷åòå. 5. Êàëüêóëèðîâàíèå ñåáåñòîèìîñòè ïðîäóêöèè (ðàáîò, óñëóã). 6. Ó÷åòíàÿ ïîëèòèêà îðãàíèçàöèè â îáëàñòè ôîðìèðîâàíèÿ ñåáåñòîèìîñòè. 7. Ñëîæíûå âîïðîñû òèïè÷íûå îøèáêè ïðè êàëüêóëèðîâàíèè ñåáåñòîèìîñòè. Íà ñåìèíàðå âûñòóïàåò ÊËÈÌÎÂÀ Ìàðèíà Àðêàäüåâíà, ê.ý.í., ïðîôåññèîíàëüíûé áóõãàëòåð, àâòîð êíèã "Íàëîã íà äîõîäû ôèçè÷åñêèõ ëèö", "Êàê ïðàâèëüíî îôîðìèòü ó÷åòíóþ ïîëèòèêó îðãàíèçàöèè", "Äîêóìåíòîîáîðîò â áóõãàëòåðñêîì ó÷åòå", "Òðóäîâîé Êîäåêñ ÐÔ: ïîñòàòåéíûé êîììåíòàðèé", "Çàðàáîòíàÿ ïëàòà: ïðàêòè÷åñêîå ðóêîâîäñòâî", <Óïðîùåííàÿ ñèñòåìà íàëîãîîáëîæåíèÿ> è ìíîãèõ äðóãèõ. Ïðè ó÷àñòèè îäíîãî ÷åëîâåêà ñòîèìîñòü ëþáîãî ñåìèíàðà ñîñòàâëÿåò 3 900 ðóá., ñ ó÷åòîì ÍÄÑ. Ïðè ó÷àñòèè â äâóõ ñåìèíàðàõ (èëè äâóõ ÷åëîâåê â îäíîì ñåìèíàðå) ïðåäîñòàâëÿåòñÿ ñêèäêà 10%. Ïðè ó÷àñòèè â òðåõ ñåìèíàðàõ (èëè òðåõ ÷åëîâåê), ÷åòâåðòûé - â ïîäàðîê.  ñòîèìîñòü ñåìèíàðà âõîäèò ðàçäàòî÷íûé ìàòåðèàë, êîôå-ïàóçà è îáåä â ðåñòîðàíå. Íà÷àëî ñåìèíàðà â 10.00 ÷àñîâ, îêîí÷àíèå - â 17.00 ÷àñîâ. Íà÷àëî ðåãèñòðàöèè - â 09-30. Ìåñòî ïðîâåäåíèÿ ñåìèíàðà - â 3-õ ìèíóòàõ õîäüáû îò ìåòðî <Àêàäåìè÷åñêàÿ>. qkmlcnvr From noreply@sourceforge.net Thu Apr 17 13:58:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 05:58:37 -0700 Subject: [Patches] [ python-Patches-722462 ] __class__ assignment for list and dict Message-ID: Patches item #722462, was opened at 2003-04-16 12:29 Message generated for change (Comment added) made by jiba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722462&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Jiba (jiba) Assigned to: Nobody/Anonymous (nobody) Summary: __class__ assignment for list and dict Initial Comment: This patch fixes the bug #712975 It also fixes an error: when calling compatible_for_assignment() in object_set_class(), old and new arguments were reversed (no consequence, but quite confusing). The following is now allowed: - __class__ assignment on a list or a dict, as long as the new type is a subtype whose subtype_dealloc will call the list / dict dealloc, - __class__ assignment on a subtype of list or dict, as long as the subtype have: - no new slots - no weaklist - no dict - no __del__ test_class_assignment.py is a PyUnit test case for this feature. ---------------------------------------------------------------------- >Comment By: Jiba (jiba) Date: 2003-04-17 12:58 Message: Logged In: YES user_id=591223 Sure it is complicated... i'll rewrite my observation API at the C level. But at least fix this: in typeobject.c, compatible_for_assignment() is defined as following line 2362: static int compatible_for_assignment(PyTypeObject* old, PyTypeObject* new, char* attr) But it is called line 2423 with new as the first argument! if (compatible_for_assignment(new, old, "__class__")) { ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 14:18 Message: Logged In: YES user_id=6380 I'm rejecting this; it's too complicated and I don't care about the functionality. Sorry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722462&group_id=5470 From noreply@sourceforge.net Thu Apr 17 16:12:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 08:12:35 -0700 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 13:03 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open >Resolution: Later >Priority: 1 Submitted By: Jon Riehl (jriehl) >Assigned to: Nobody/Anonymous (nobody) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-17 11:12 Message: Logged In: YES user_id=6380 I've checked in the changes to the parser and Makefile etc. This means you should be able to distribute pgenmodule.c as a clean extension to Python 2.3. I've decided not to incorporate pgenmodule.c at this time. There are three problems with it as I see it: - The C coding style is really different, and makes it hard to read: 2-space indents instead of tabs, spaces before left parentheses in argument lists, space between * and name in things like "PyObject * name", placement of curly braces, reversal of arguments to comparisons (e.g. "NULL != x"), and long strings of underscores in comments. - The code isn't robust enough: I got a segfault (can't remember after what sequence of events, sorry), and it caused a SystemError (error return without exception set) when the grammar file couldn't be read. - The pgen API seems a bit strange -- some things that I would expect to be methods of AST objects are functions in the pgen module (even when a companion function *is* an AST method). - The unit test doesn't fit in the Python test framework. - I cooked up a little expression grammar and tried to parse a sample string, but all I got was exceptions. I guess I am missing something, but there's no tutorial that explains me how to do things (I was copying the code from test_pgen.py which works :-( ). Nevertheless, thanks for the work so far -- I'm sure at some point pgen will be usable from Python! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 16:44 Message: Logged In: YES user_id=6380 OK, reading the README now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-05 11:42 Message: Logged In: YES user_id=6380 Closed. Jon, if you're still interested in this, upload something new and reopen the patch (or I can do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 12:32 Message: Logged In: YES user_id=6380 Lowering priority until Jon has his next version ready. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-13 00:35 Message: Logged In: YES user_id=6380 Cool. Maybe I'll get to it, maybe not. :-( ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2002-09-12 14:04 Message: Logged In: YES user_id=22448 Guido, as per my private message, I'll attempt to submit another patch by the end of the month, pending resumption of "work" on the 23rd. Commitment of the memory allocation patch is fine, and any future patches would be against the updated pgen code (I don't have commit permissions, so someone else will have to do this possibly.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 08:09 Message: Logged In: YES user_id=6380 I looked a bit, and it's very raw - the author admits that. Jon, are you still working on this? Do you have a more polished version? Maybe we can separate out the memory allocation patches and commit these already? They don't break anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply@sourceforge.net Thu Apr 17 16:31:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 08:31:19 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-04-17 17:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Thu Apr 17 17:03:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 09:03:42 -0700 Subject: [Patches] [ python-Patches-723201 ] PyArg_ParseTuple problem with 'L' format Message-ID: Patches item #723201, was opened at 2003-04-17 18:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723201&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTuple problem with 'L' format Initial Comment: PyArg_ParseTuple(tup, "B", &value) will raise 'Bad Argument to internal function' if the object is not a Python integer or long. I believe the patch fixes the problem, but it is untested. This problem probably exists since 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723201&group_id=5470 From noreply@sourceforge.net Thu Apr 17 18:02:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 10:02:09 -0700 Subject: [Patches] [ python-Patches-723231 ] __del__ in dumbdbm fails under some circumstances Message-ID: Patches item #723231, was opened at 2003-04-17 12:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723231&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Stone (timstone4) Assigned to: Nobody/Anonymous (nobody) Summary: __del__ in dumbdbm fails under some circumstances Initial Comment: Using dumbdbm for simple testing, I occasionally get the following error: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'error' " in > ignored I've tracked it down to a problem with the releasing of the reference to _os during __del__, which then calls _commit. _commit proceeds to use the _os, which is given a value of None... blamo... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723231&group_id=5470 From noreply@sourceforge.net Thu Apr 17 20:03:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 12:03:29 -0700 Subject: [Patches] [ python-Patches-723312 ] ability to pass a timeout to underlying socket Message-ID: Patches item #723312, was opened at 2003-04-17 20:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Russell (mattruss) Assigned to: Nobody/Anonymous (nobody) Summary: ability to pass a timeout to underlying socket Initial Comment: this patch superceeds an earlier one i posted (#714592) - a bit *too* enthusiastic am afraid (sorry!) classes in modules such as httplib, ftpplib do not currently allow an easy way to take advantage of the new socket timeout feature in 2.3. This patch provides that abilty though one additonal class in socket.py ( socket.NetworkConnection ) and accompying test in test_socket.py (basic though the test is :-s ) As an extra benifit, the patch removes duplicate code, as each connect method in the main class of most modules (FTP, HTTPConnection, Telnet, POP3 etc) are copies of each other. The modules that use sockets are: * ftplib * httplib * telnetlib * poplib * urllib * imaplib * nntplib * xmlrpclib Of these I have only been able to easily refactor NetworkConnection into httplib, ftplib, telnetllib, poplib and smtplib. I did look to see if there were any unittests for theese modules in .Lib/test but found none (? - I appologise if there are some, i am new to the library tests) I did however check that the test() [like] methods at the bottom of each of the afore mentioned modules worked. thanks for your advice again Skip :o) Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 From noreply@sourceforge.net Thu Apr 17 20:10:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 12:10:12 -0700 Subject: [Patches] [ python-Patches-723312 ] ability to pass a timeout to underlying socket Message-ID: Patches item #723312, was opened at 2003-04-17 20:03 Message generated for change (Settings changed) made by mattruss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Works For Me >Priority: 6 Submitted By: Matthew Russell (mattruss) >Assigned to: Skip Montanaro (montanaro) Summary: ability to pass a timeout to underlying socket Initial Comment: this patch superceeds an earlier one i posted (#714592) - a bit *too* enthusiastic am afraid (sorry!) classes in modules such as httplib, ftpplib do not currently allow an easy way to take advantage of the new socket timeout feature in 2.3. This patch provides that abilty though one additonal class in socket.py ( socket.NetworkConnection ) and accompying test in test_socket.py (basic though the test is :-s ) As an extra benifit, the patch removes duplicate code, as each connect method in the main class of most modules (FTP, HTTPConnection, Telnet, POP3 etc) are copies of each other. The modules that use sockets are: * ftplib * httplib * telnetlib * poplib * urllib * imaplib * nntplib * xmlrpclib Of these I have only been able to easily refactor NetworkConnection into httplib, ftplib, telnetllib, poplib and smtplib. I did look to see if there were any unittests for theese modules in .Lib/test but found none (? - I appologise if there are some, i am new to the library tests) I did however check that the test() [like] methods at the bottom of each of the afore mentioned modules worked. thanks for your advice again Skip :o) Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 From noreply@sourceforge.net Thu Apr 17 22:13:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 14:13:53 -0700 Subject: [Patches] [ python-Patches-723364 ] terminal type option subnegotiation in telnetlib Message-ID: Patches item #723364, was opened at 2003-04-17 21:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723364&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jon Willeke (willeke) Assigned to: Nobody/Anonymous (nobody) Summary: terminal type option subnegotiation in telnetlib Initial Comment: The attached patch makes it possible for an option negotiation callback to subnegotiate the terminal type option (per RFC 1091). The patch does the following: * defines the SB and SE commands (per RFC 854) * defines QUAL_IS and QUAL_SEND (adapted from ) * passes SB ... SE to callback in process_rawq() A simple callback would specify the terminal type as follows: * respond to IAC DO TTYPE with IAC WILL TTYPE * respond to IAC SB TTYPE QUAL_SEND IAC SE with IAC SB TTYPE QUAL_IS 'vt100' IAC SE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723364&group_id=5470 From noreply@sourceforge.net Thu Apr 17 22:36:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 14:36:04 -0700 Subject: [Patches] [ python-Patches-722686 ] New shlex functionality Message-ID: Patches item #722686, was opened at 2003-04-16 19:28 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722686&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: New shlex functionality Initial Comment: This patch implements the shlex.py features discussed in the mailling list. I'm not sure if "split_args()" is the best name for the introduced function. Any suggestion? ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-17 21:36 Message: Logged In: YES user_id=7887 I had to change the implementation to make it understand escaping as presented in posix shells. I've also introduced other minor changes, like including iso-8859-1 characters in wordchars, and a new whitespace_split mode, which helps in shell argument parsing routines. Besides that, I've written complex testcases based on the shellwords dataset (which was generated with help of a posix shell), and ported the dataset to work in non-posix mode as well. The later tests were also executed in Python 2.2 to check for compatibility issues, and no problems were detected. I've also written documentation for the new features, and included a simple description of how the parser will behave in posix and non-posix modes. These changes were applied as: Doc/lib/libshlex.tex: 1.13 Lib/shlex.py: 1.18 Lib/test/test_shlex.py: 1.1 Misc/NEWS: 1.731 I've attached the new patch (Version 2) here for reference. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 19:53 Message: Logged In: YES user_id=6380 I would call it simply split(), like other splitting functions. Add docs, add unit tests, check it in. We'll see if someone cares. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722686&group_id=5470 From noreply@sourceforge.net Thu Apr 17 23:14:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 15:14:00 -0700 Subject: [Patches] [ python-Patches-662464 ] 659188: no docs for HTMLParser Message-ID: Patches item #662464, was opened at 2003-01-04 23:10 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662464&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 659188: no docs for HTMLParser Initial Comment: Added some high level docs to explain how to use the class. Provided docstrings for the handle_* callback methods. ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-03-30 22:24 Message: Logged In: YES user_id=531881 added documentation for handle_pi callback method in libhtmlparser.tex ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-03-30 13:04 Message: Logged In: YES user_id=531881 Sure. I'll patch and post it later on today. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 12:25 Message: Logged In: YES user_id=21627 Christopher, can you please indicate whether you are going to provide a patch for the primary source of the documentation, i.e. the TeX files? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-15 07:20 Message: Logged In: YES user_id=21627 Can you please provide a patch for the Tex documentation (Doc/lib/libhtmlparser.tex) as well? I think this is where the submitter of bug 659188 was looking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662464&group_id=5470 From noreply@sourceforge.net Thu Apr 17 23:39:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 15:39:53 -0700 Subject: [Patches] [ python-Patches-662464 ] 659188: no docs for HTMLParser Message-ID: Patches item #662464, was opened at 2003-01-04 23:10 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662464&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 659188: no docs for HTMLParser Initial Comment: Added some high level docs to explain how to use the class. Provided docstrings for the handle_* callback methods. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-04-17 18:39 Message: Logged In: YES user_id=3066 Committed similar patch (based on this one) as Doc/lib/libhtmlparser.tex revisions 1.3 and 1.2.18.1. ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-03-30 22:24 Message: Logged In: YES user_id=531881 added documentation for handle_pi callback method in libhtmlparser.tex ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-03-30 13:04 Message: Logged In: YES user_id=531881 Sure. I'll patch and post it later on today. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 12:25 Message: Logged In: YES user_id=21627 Christopher, can you please indicate whether you are going to provide a patch for the primary source of the documentation, i.e. the TeX files? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-15 07:20 Message: Logged In: YES user_id=21627 Can you please provide a patch for the Tex documentation (Doc/lib/libhtmlparser.tex) as well? I think this is where the submitter of bug 659188 was looking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662464&group_id=5470 From noreply@sourceforge.net Fri Apr 18 00:41:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 16:41:01 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-26 00:16 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2003-04-18 01:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-26 00:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Fri Apr 18 01:29:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 17:29:50 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-25 18:16 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-17 20:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-17 19:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-25 18:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Fri Apr 18 01:42:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2003 17:42:53 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-26 00:16 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2003-04-18 02:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 02:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 01:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-26 00:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Fri Apr 18 11:43:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 03:43:07 -0700 Subject: [Patches] [ python-Patches-632643 ] Punycode encoding Message-ID: Patches item #632643, was opened at 2002-11-02 18:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=632643&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Punycode encoding Initial Comment: This patch implements Punycode, http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-03.txt This will be used by the internationalized domain names. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 12:43 Message: Logged In: YES user_id=21627 I have now updated this module to RFC 3492, and committed the entire set of IDNA changes as lib.tex 1.219 libcodecs.tex 1.18 libstringprep.tex 1.1 whatsnew23.tex 1.138 httplib.py 1.74 stringprep.py 1.1 idna.py 1.1 punycode.py 1.1 test_codecs.py 1.6 NEWS 1.733 socketmodule.c 1.259 mkstringprep.py 1.1 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-05 10:03 Message: Logged In: YES user_id=38388 I don't have time to review this. If punycode will acutally become a standard I'm all for adding support to Python for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=632643&group_id=5470 From noreply@sourceforge.net Fri Apr 18 11:48:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 03:48:45 -0700 Subject: [Patches] [ python-Patches-649997 ] Complementary patch for OpenVMS Message-ID: Patches item #649997, was opened at 2002-12-07 12:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=649997&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Piéronne Jean-François (pieronne) Assigned to: Martin v. Löwis (loewis) Summary: Complementary patch for OpenVMS Initial Comment: Hi, I have attach the complementary patch for OpenVMS As the previous one, all the update use conditionnal compilation for VMS, except in two place: There is for socketmodule.c two update which use ENABLE_IPV6 test but not __VMS because I think it was a bug into the initial code, there is a use of "sockaddr_storage" which is if I remember correctly a IPV6 structure. Regards, Jean-François Piéronne ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 12:48 Message: Logged In: YES user_id=21627 It appears that this patch is indeed obsolete, closing it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 23:16 Message: Logged In: YES user_id=21627 Am I correct assuming that this patch has been superceded now by 708495? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-08 11:34 Message: Logged In: YES user_id=21627 I have a number of questions: - What is RMS? (probably not Richard M Stallman :-) RMSError is not used, so it should not be included in the patch. - Why do you need to omit the argument for F_GETFD? - Why do you cast the ioctl argument to void*? In POSIX, this argument is of type int. - What is the third argument to getcwd? - Don't use nested #ifs, use #elif instead where appropriate. - ---------------------------------------------------------------------- Comment By: Piéronne Jean-François (pieronne) Date: 2002-12-08 11:00 Message: Logged In: YES user_id=414701 Done Thanks ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-08 09:49 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=649997&group_id=5470 From noreply@sourceforge.net Fri Apr 18 11:51:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 03:51:32 -0700 Subject: [Patches] [ python-Patches-714957 ] Document freeze process in PC/config.c Message-ID: Patches item #714957, was opened at 2003-04-04 01:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714957&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 2 Submitted By: David Schnepper (dschnepper) Assigned to: Martin v. Löwis (loewis) Summary: Document freeze process in PC/config.c Initial Comment: Resolved an XXX comment in PC/config.c ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 12:51 Message: Logged In: YES user_id=21627 Thanks, committed as config.c 1.39. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714957&group_id=5470 From noreply@sourceforge.net Fri Apr 18 12:44:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 04:44:26 -0700 Subject: [Patches] [ python-Patches-711835 ] Removing unnecessary lock operations Message-ID: Patches item #711835, was opened at 2003-03-29 17:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711835&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Martin v. Löwis (loewis) Summary: Removing unnecessary lock operations Initial Comment: PyThread_acquire_lock can be further optimized to do less locking on the global lock mutex. Original patch location: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86281 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 13:44 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as thread_pthread.h 2.45 and 2.36.8.3. As for performance: I ran the program import thread, time a = thread.allocate_lock() r = [None]*1000000 for k in range(5): start = time.time() for i in r: a.acquire() a.release() print time.time()-start with standard CVS (semaphores), and it gives 3.0380500555 3.00736105442 3.04938793182 2.99445092678 3.01815795898 With your patch applied, and with defining HAVE_BROKEN_POSIX_SEMAPHORES (so that semaphores are not used anymore), it gives 3.34937000275 3.3407189846 3.55324399471 3.901293993 3.6628960371 So it seems that semphores are indeed more efficient. [Of course, your patch is not relevant for this test, as there is always success] ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2003-03-31 20:21 Message: Logged In: YES user_id=205865 One of the glibc developers expressed some concern on the 2.3 implementation of the global lock using semaphores. I'd be glad to funnel any communication with the glibc community. (you) should do some timings on the current lock implementation vs the one using semaphores. POSIX semaphores have special requirements (e.g., sem_post must be callable in signal handlers) which make semaphores pretty expensive. In NPTL, for instance, sem_post always makes a syscall, there is no userlevel-only path. This makes using semaphores pretty expensive. The same restricting applies in one form or another to all POSIX compliant semaphore implementations. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-31 19:23 Message: Logged In: YES user_id=31435 I marked this as Accepted, and also don't see any problem with backporting to the 2.2 line. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 07:25 Message: Logged In: YES user_id=21627 There are plans to provide Python 2.2.3. I see no problem applying it to 2.2.2, as there shouldn't be any change in visible behaviour. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2003-03-31 05:59 Message: Logged In: YES user_id=205865 Also, this happens in 2.2.2 as well (the patch in Red Hat's bugzilla is against 2.2.2 actually). Is there a plan to release a 2.2.3? Is there value in backporting the patch? (should apply cleanly on 2.2.2). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-31 00:19 Message: Logged In: YES user_id=33168 _POSIX_SEMAPHORES aren't used if HAVE_BROKEN_POSIX_SEMAPHORES is defined. This currently occurs on Solaris 8 (at least). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-31 00:11 Message: Logged In: YES user_id=31435 Looks fine to me too. Since Python switched to using semaphores on Linux for 2.3, it's unclear that there's a system that uses the condvar code anymore. How will this get tested? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 18:49 Message: Logged In: YES user_id=21627 This looks reasonable to me, but I may be missing something. Tim, can you see a problem with that code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711835&group_id=5470 From noreply@sourceforge.net Fri Apr 18 12:45:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 04:45:13 -0700 Subject: [Patches] [ python-Patches-722839 ] HAVE_GAI_STRERROR typo fix Message-ID: Patches item #722839, was opened at 2003-04-17 01:59 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) >Assigned to: Martin v. Löwis (loewis) Summary: HAVE_GAI_STRERROR typo fix Initial Comment: This patch fixes a typo in getaddrinfo.c. The #ifdef doesn't match the define in pyconfig.h ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 From noreply@sourceforge.net Fri Apr 18 16:07:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 08:07:54 -0700 Subject: [Patches] [ python-Patches-720468 ] nntplib file output for multiline commands Message-ID: Patches item #720468, was opened at 2003-04-13 00:34 Message generated for change (Settings changed) made by tcarroll You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720468&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Terry Carroll (tcarroll) >Assigned to: Guido van Rossum (gvanrossum) Summary: nntplib file output for multiline commands Initial Comment: This patch extends the support for file output, currently supported only for the body() method (added by Travers Naran in patch 462628) to all the other methods that invoke NNTP commands that produce multiline output; in particular: newgroups(), newnews(), list(), help(), xhdr(), xgtitle() and xover(). Many of these commands, especially list(), newgroups() and xhdr(), produce a large amount of output, and requiring that the output be maintained in memory, as in the present implementation, may impair performance of the application or the entire system, in limited-resource configurations. Routing the output to a file avoids this (and, if the file object is actually a subclass of the file class, the programmer can supply a write method that processes the NNTP command output as it is produced). The file parameter added by this patch is consistent with its present use in the body() method, specifying either a string containing a file name, or an open file object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720468&group_id=5470 From noreply@sourceforge.net Fri Apr 18 16:50:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 08:50:48 -0700 Subject: [Patches] [ python-Patches-697941 ] optparse OptionGroup docs Message-ID: Patches item #697941, was opened at 2003-03-05 06:48 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=697941&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: optparse OptionGroup docs Initial Comment: A small patch to add a bit about the new OptionGroup, added in Optik 1.4 and Python CVS but currently undocumented. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-04-18 11:50 Message: Logged In: YES user_id=3066 Accepted a slightly modified version of the patch as Doc/lib/liboptparse.tex revision 1.2. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=697941&group_id=5470 From noreply@sourceforge.net Fri Apr 18 17:18:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 09:18:45 -0700 Subject: [Patches] [ python-Patches-720468 ] nntplib file output for multiline commands Message-ID: Patches item #720468, was opened at 2003-04-12 20:34 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720468&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Terry Carroll (tcarroll) Assigned to: Guido van Rossum (gvanrossum) Summary: nntplib file output for multiline commands Initial Comment: This patch extends the support for file output, currently supported only for the body() method (added by Travers Naran in patch 462628) to all the other methods that invoke NNTP commands that produce multiline output; in particular: newgroups(), newnews(), list(), help(), xhdr(), xgtitle() and xover(). Many of these commands, especially list(), newgroups() and xhdr(), produce a large amount of output, and requiring that the output be maintained in memory, as in the present implementation, may impair performance of the application or the entire system, in limited-resource configurations. Routing the output to a file avoids this (and, if the file object is actually a subclass of the file class, the programmer can supply a write method that processes the NNTP command output as it is produced). The file parameter added by this patch is consistent with its present use in the body() method, specifying either a string containing a file name, or an open file object. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 12:18 Message: Logged In: YES user_id=6380 Two comments: - Instead of "if file == None" you should test for "if file is None". - In several routines you added "if file == None" guards around a for loop over the lines returned by self.longcmd(...). But self.longcmd() returns an empty list if given a file argument, so the for loop would execute zero times. I think it's better to drop the guard and simply let the empty loop take care of things. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720468&group_id=5470 From noreply@sourceforge.net Fri Apr 18 18:29:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 10:29:52 -0700 Subject: [Patches] [ python-Patches-718049 ] Setting exe_extension for cygwin Message-ID: Patches item #718049, was opened at 2003-04-08 23:45 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Jason Tishler (jlt63) Summary: Setting exe_extension for cygwin Initial Comment: On cygwin, the setup.py script uses unixccompiler.py for compiling and linking C extensions. The unixccompiler.py script assumes that executables do not get special extensions, which makes sense for Unix. However, on Cygwin, executables get an .exe extension. This causes a problem during the configuration step (python setup.py config), in which some temporary executables may be generated. As unixccompiler.py does not know about the .exe extension, distutils fails to clean up after itself: it does not remove _configtest.exe but tries to remove _configtest instead. The attached patch to unixccompiler.py sets the correct exe_extension for cygwin by checking if sys.platform is 'cygwin'. With this patch, distutils cleans up after itself correctly. Michiel de Hoon University of Tokyo, Human Genome Center. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-04-18 09:29 Message: Logged In: YES user_id=86216 Checked in as Lib/distutils/unixccompiler.py 1.52. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-14 05:26 Message: Logged In: YES user_id=11105 jlt63: IIRC, Rene Liebscher is the author of CygwinCCompiler. Is he still around? Sometimes he shows up on distutils-sig. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-04-14 05:00 Message: Logged In: YES user_id=86216 loewis> Jason, any opinion? This patch seems fine to me -- at least, it does not break the Cygwin Python build. I'm willing to apply. mdehoon> I don't know why unixccompiler is being mdehoon> used, >From my point of view, Cygwin is just another Unix. So, it should use UnixCCompiler and not CygwinCCompiler. mdehoon> you'd have to ask the person who mdehoon> wrote unixccompiler / cygwinccompiler. IIRC, Rene Liebscher is the author of CygwinCCompiler. Is he still around? loewis> Can you explain wh unixccompiler is used? loewis> cygwincompiler should be used instead... See above. I always thought that CygwinCCompiler and Mingw32CCompiler where used to build Win32 Python extensions with gcc. Although, I must admit to never understanding the use for CygwinCCompiler. I must be missing something... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-12 03:30 Message: Logged In: YES user_id=21627 Jason, any opinion? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-04-12 03:16 Message: Logged In: YES user_id=488897 I don't know why unixccompiler is being used, you'd have to ask the person who wrote unixccompiler / cygwinccompiler. If I use "python setup.py build" on cygwin, it uses unixccompiler. I can force it to use cygwinccompiler by using "python setup.py build --compiler=cygwin". (BTW, that currently seems to be broken, the compilation fails during the linking stage). My guess is that if unixccompiler works on cygwin (which it does, except for the cleanup problem), there is no reason to have a separate cygwinccompiler. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-12 02:40 Message: Logged In: YES user_id=21627 Can you explain wh unixccompiler is used? cygwincompiler should be used instead... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=718049&group_id=5470 From noreply@sourceforge.net Fri Apr 18 19:57:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 11:57:24 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 09:14 Message generated for change (Comment added) made by herron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Fredrik Lundh (effbot) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- >Comment By: Gary Herron (herron) Date: 2003-04-18 18:57 Message: Logged In: YES user_id=395736 I copied all the (8) sre files from the 2.3 branch to the release22-maint branch and compiled and ran the test. It worked flawlessly with the single exception that module init functions are declared as type DL_EXPORT(void) -- in 2.2 and as type PyMODINIT_FUNC -- in 2.3 If there are no considerations other than getting the tests to run successfully, then I'll declare success and produce a patch and submit it. OK? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-15 18:41 Message: Logged In: YES user_id=6380 The Python 2.2 maintenance branch is labeled with the CVS tag 'release22-maint'. I hope you know or can find out about working with CVS branches. Good luck! ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-15 16:50 Message: Logged In: YES user_id=395736 Sure, I'll port it to Python2.2. I'm surprised it dod not apply cleanly there, but then I don't know the history of previous patches (like when lastmark_restore was introduced). I guess copying all sre code will be the first thing to try. How do I get a dev version of Python 2.2? Yes, the *? code is all Greg Chapman's. He sent it to me the day I announced my volunteering to maintain the sre code. I wrote the test cases for it, and used it as a great way to learn my way through the code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 19:50 Message: Logged In: YES user_id=6380 Gary, I wonder if you could rework your fix for Python 2.2? The patch doesn't apply cleanly there; one of the problems is that lastmark_restore() doesn't exist. I wonder if maybe all of the _sre.c code should simply be copied to the 2.2 branch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 18:15 Message: Logged In: YES user_id=6380 Looks cool; I've checked this in unchanged, except changing one comment: the comment about the test for bug 545855 said it would generate errors during matching, while when I try it, the pattern generates a TypeError during compilation. I don't feel capable to review the code you added to _sre.c; I'll assign it to Fredrik, but I don't expect him to have time to look at it. It seems you haven't broken his requirement for this code to work back to Python 1.5.2. I'll backport to Python 2.2 as well. Do I understand correctly that the .*? addition is all Greg Chapman's work? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 16:46 Message: Logged In: YES user_id=6380 Will look at this ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Fri Apr 18 20:06:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 12:06:49 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 05:14 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Fredrik Lundh (effbot) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 15:06 Message: Logged In: YES user_id=6380 Great! Sounds like a plan. ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-18 14:57 Message: Logged In: YES user_id=395736 I copied all the (8) sre files from the 2.3 branch to the release22-maint branch and compiled and ran the test. It worked flawlessly with the single exception that module init functions are declared as type DL_EXPORT(void) -- in 2.2 and as type PyMODINIT_FUNC -- in 2.3 If there are no considerations other than getting the tests to run successfully, then I'll declare success and produce a patch and submit it. OK? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-15 14:41 Message: Logged In: YES user_id=6380 The Python 2.2 maintenance branch is labeled with the CVS tag 'release22-maint'. I hope you know or can find out about working with CVS branches. Good luck! ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-15 12:50 Message: Logged In: YES user_id=395736 Sure, I'll port it to Python2.2. I'm surprised it dod not apply cleanly there, but then I don't know the history of previous patches (like when lastmark_restore was introduced). I guess copying all sre code will be the first thing to try. How do I get a dev version of Python 2.2? Yes, the *? code is all Greg Chapman's. He sent it to me the day I announced my volunteering to maintain the sre code. I wrote the test cases for it, and used it as a great way to learn my way through the code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 15:50 Message: Logged In: YES user_id=6380 Gary, I wonder if you could rework your fix for Python 2.2? The patch doesn't apply cleanly there; one of the problems is that lastmark_restore() doesn't exist. I wonder if maybe all of the _sre.c code should simply be copied to the 2.2 branch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 14:15 Message: Logged In: YES user_id=6380 Looks cool; I've checked this in unchanged, except changing one comment: the comment about the test for bug 545855 said it would generate errors during matching, while when I try it, the pattern generates a TypeError during compilation. I don't feel capable to review the code you added to _sre.c; I'll assign it to Fredrik, but I don't expect him to have time to look at it. It seems you haven't broken his requirement for this code to work back to Python 1.5.2. I'll backport to Python 2.2 as well. Do I understand correctly that the .*? addition is all Greg Chapman's work? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 12:46 Message: Logged In: YES user_id=6380 Will look at this ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Fri Apr 18 21:15:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 13:15:32 -0700 Subject: [Patches] [ python-Patches-722839 ] HAVE_GAI_STRERROR typo fix Message-ID: Patches item #722839, was opened at 2003-04-17 01:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Martin v. Löwis (loewis) Summary: HAVE_GAI_STRERROR typo fix Initial Comment: This patch fixes a typo in getaddrinfo.c. The #ifdef doesn't match the define in pyconfig.h ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 22:15 Message: Logged In: YES user_id=21627 What specifically is the typo you are referring to? I cannot see any ifdef at all, and your patch does not correct any ifdef. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 From noreply@sourceforge.net Fri Apr 18 21:32:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 13:32:18 -0700 Subject: [Patches] [ python-Patches-711902 ] Cause pydoc to show data descriptor __doc__ strings Message-ID: Patches item #711902, was opened at 2003-03-29 20:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711902&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Martin v. Löwis (loewis) Summary: Cause pydoc to show data descriptor __doc__ strings Initial Comment: Data descriptors (descriptors having both a __get__ and a __set__ method) often have __doc__ strings. Pydoc displays these for descriptors of type property, but not for other types (e.g., getsets). The attached patch will display __doc__ strings for data descriptors (if available) in the "Data and non-method functions" section of the type description. This patch is intended to be a minimal change. It's possible that inspect.classify_class_attrs should return a new kind for data descriptors (or possibly the "property" kind should include all data descriptors (not just properties)), which could then be handled differently from other non-classified data. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 22:32 Message: Logged In: YES user_id=21627 The patch looks fine. Can you please also provide a patch for the documentation (libinspect.tex), and the test suite (test_inspect.py)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711902&group_id=5470 From noreply@sourceforge.net Fri Apr 18 22:03:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 14:03:00 -0700 Subject: [Patches] [ python-Patches-722839 ] HAVE_GAI_STRERROR typo fix Message-ID: Patches item #722839, was opened at 2003-04-16 23:59 Message generated for change (Comment added) made by bkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Martin v. Löwis (loewis) Summary: HAVE_GAI_STRERROR typo fix Initial Comment: This patch fixes a typo in getaddrinfo.c. The #ifdef doesn't match the define in pyconfig.h ---------------------------------------------------------------------- >Comment By: Brad Clements (bkc) Date: 2003-04-18 21:03 Message: Logged In: YES user_id=4631 Oops, sorry. The description of this patch is not correct, but it's still needed. pyconfig.h defines "HAVE_GAI_STRERROR" but Modules/getaddrinfo.c doesn't use the #define to control the declaration of gai_strerror() Note that socketmodule.c does use this #define. I'm suggesting that getaddrinfo.c should also use it to NOT define gai_strerror. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 20:15 Message: Logged In: YES user_id=21627 What specifically is the typo you are referring to? I cannot see any ifdef at all, and your patch does not correct any ifdef. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 From noreply@sourceforge.net Fri Apr 18 22:06:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 14:06:27 -0700 Subject: [Patches] [ python-Patches-536883 ] SimpleXMLRPCServer auto-docing subclass Message-ID: Patches item #536883, was opened at 2002-03-29 20:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=536883&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Martin v. Löwis (loewis) Summary: SimpleXMLRPCServer auto-docing subclass Initial Comment: This SimpleXMLRPCServer subclass automatically serves HTML documentation, generated using pydoc, in response to an HTTP GET request (XML-RPC always uses POST). Here are some examples: http://www.sweetapp.com/cgi-bin/xmlrpc-test/rpc1.py http://www.sweetapp.com/cgi-bin/xmlrpc-test/rpc2.py ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 23:06 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as lib.tex 1.220 libdocxmlrpc.tex 1.1 whatsnew23.tex 1.139 DocXMLRPCServer.py 1.1 NEWS 1.734 I think the documentation is fine; I have trimmed it somewhat to avoid repetition (I have also texified it). ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2003-04-03 09:06 Message: Logged In: YES user_id=108973 Module resubmitted with test function. Documentation attached in text format. The documentation doesn't seem terribly good to me so feel free to suggest changes. Will it be clear to the newbie that they should look at SimpleXMLRPCServer for RPC related methods? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 23:30 Message: Logged In: YES user_id=21627 Ok, leave the naming as-is, unless other reviewers comment in one direction or the other. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2003-03-31 11:22 Message: Logged In: YES user_id=108973 Write test function: ok Write documentation: ok >If the module is named, say, DocXMLRPCServer, there is >no need to have the Doc prefix on the class names. Hmmm. If you look at the core BaseHTTPRequestHandler derived classes, each one is prefixed to match the module that it is found in. The only two modules that I can think of with identical class names are cStringIO and StringIO, which theoretically provide identical semantics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 11:07 Message: Logged In: YES user_id=21627 I see. The code is fine, but it needs to come with a test function, to operate the module as a program. I suggest that the test server provides the get_source_code() operation just as your demo client does; the docstring of the class may provide an xmlrpclib fragment that retrieves the source code (AFAICT, the source code is not directly accessible through an URL, is it?) I also recommend that you reconsider renaming the classes: If the module is named, say, DocXMLRPCServer, there is no need to have the Doc prefix on the class names. Instead, they can be named just "XMLRPCServer" etc. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2003-03-31 08:56 Message: Logged In: YES user_id=108973 >I'm not sure how to place this. Is this an extension to >pydoc? No. This module provides subclasses for SimpleXMLRPCServer and CGIXMLRPCServer. These subclasses serve pydoc-style documentation when you point your browser at them - see the examples in the patch summary. > Should it go into Tools, or into Lib, or into some > existing module? The attached file should go into Lib. > If this goes into Lib somewhere, it lacks documentation. Fair enough. Conditional on me writing documentation, is this contribution acceptable as is? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 16:59 Message: Logged In: YES user_id=21627 I'm not sure how to place this. Is this an extension to pydoc? Should it go into Tools, or into Lib, or into some existing module? If this goes into Lib somewhere, it lacks documentation. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2003-02-10 21:25 Message: Logged In: YES user_id=108973 Patch 473586 has been accepted so this patch can be accepted. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2002-04-04 21:26 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about the description: This patch is dependant on patch 473586: [473586] SimpleXMLRPCServer - fixes and CGI So please don't check this in until that patch is accepted. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2002-04-04 19:55 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about the description: This patch is dependant on patch 473586: [473586] SimpleXMLRPCServer - fixes and CGI So please don't check this in until that patch is accepted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-04 19:31 Message: Logged In: YES user_id=6380 Looks cute to me. Fredrik, any problem if I just check this in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=536883&group_id=5470 From noreply@sourceforge.net Fri Apr 18 22:14:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 14:14:04 -0700 Subject: [Patches] [ python-Patches-722839 ] HAVE_GAI_STRERROR typo fix Message-ID: Patches item #722839, was opened at 2003-04-17 01:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Martin v. Löwis (loewis) Summary: HAVE_GAI_STRERROR typo fix Initial Comment: This patch fixes a typo in getaddrinfo.c. The #ifdef doesn't match the define in pyconfig.h ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 23:14 Message: Logged In: YES user_id=21627 Can you please report what problem this is needed on? getaddrinfo.c is only used if you don't have getaddrinfo. However, if you don't have getaddrinfo, you shouldn't have gai_strerror, either. More specifically: What is the precise error that you get that triggered that change? ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2003-04-18 23:03 Message: Logged In: YES user_id=4631 Oops, sorry. The description of this patch is not correct, but it's still needed. pyconfig.h defines "HAVE_GAI_STRERROR" but Modules/getaddrinfo.c doesn't use the #define to control the declaration of gai_strerror() Note that socketmodule.c does use this #define. I'm suggesting that getaddrinfo.c should also use it to NOT define gai_strerror. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 22:15 Message: Logged In: YES user_id=21627 What specifically is the typo you are referring to? I cannot see any ifdef at all, and your patch does not correct any ifdef. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 From noreply@sourceforge.net Fri Apr 18 22:29:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 14:29:55 -0700 Subject: [Patches] [ python-Patches-722839 ] HAVE_GAI_STRERROR typo fix Message-ID: Patches item #722839, was opened at 2003-04-16 23:59 Message generated for change (Comment added) made by bkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Martin v. Löwis (loewis) Summary: HAVE_GAI_STRERROR typo fix Initial Comment: This patch fixes a typo in getaddrinfo.c. The #ifdef doesn't match the define in pyconfig.h ---------------------------------------------------------------------- >Comment By: Brad Clements (bkc) Date: 2003-04-18 21:29 Message: Logged In: YES user_id=4631 ow, it seems I have wasted your time. Sorry, long nights of shoehorning python 2.3a into an 8meg 68K embedded system has taken it's toll. I'm using uClibc and apparently ./configure had, I guess, at one point set HAVE_GAI_STRERROR but not HAVE_GETADDRINFO. I must have gone for the easy fix a few days ago, and then in the course I must have mis-typed GAI as GIA, fixed it later then felt "gee, I should file a patch". Sorry, I should have realized obvious problems like this wouldn't likely. (btw, I have statically linked Python 2.3 to uClibc, libxml2 and libxslt producing a 2.5 meg exe that runs medusa .. a bit slow on a 48 mhz M5272 chip) I wish to retract this patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 21:14 Message: Logged In: YES user_id=21627 Can you please report what problem this is needed on? getaddrinfo.c is only used if you don't have getaddrinfo. However, if you don't have getaddrinfo, you shouldn't have gai_strerror, either. More specifically: What is the precise error that you get that triggered that change? ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2003-04-18 21:03 Message: Logged In: YES user_id=4631 Oops, sorry. The description of this patch is not correct, but it's still needed. pyconfig.h defines "HAVE_GAI_STRERROR" but Modules/getaddrinfo.c doesn't use the #define to control the declaration of gai_strerror() Note that socketmodule.c does use this #define. I'm suggesting that getaddrinfo.c should also use it to NOT define gai_strerror. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 20:15 Message: Logged In: YES user_id=21627 What specifically is the typo you are referring to? I cannot see any ifdef at all, and your patch does not correct any ifdef. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 From noreply@sourceforge.net Fri Apr 18 22:53:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 14:53:03 -0700 Subject: [Patches] [ python-Patches-722839 ] HAVE_GAI_STRERROR typo fix Message-ID: Patches item #722839, was opened at 2003-04-17 01:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Martin v. Löwis (loewis) Summary: HAVE_GAI_STRERROR typo fix Initial Comment: This patch fixes a typo in getaddrinfo.c. The #ifdef doesn't match the define in pyconfig.h ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 23:53 Message: Logged In: YES user_id=21627 No need to worry at all; it's better to find problems with patches at review time than finding them after the release. Rejecting this patch at request of submitter. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2003-04-18 23:29 Message: Logged In: YES user_id=4631 ow, it seems I have wasted your time. Sorry, long nights of shoehorning python 2.3a into an 8meg 68K embedded system has taken it's toll. I'm using uClibc and apparently ./configure had, I guess, at one point set HAVE_GAI_STRERROR but not HAVE_GETADDRINFO. I must have gone for the easy fix a few days ago, and then in the course I must have mis-typed GAI as GIA, fixed it later then felt "gee, I should file a patch". Sorry, I should have realized obvious problems like this wouldn't likely. (btw, I have statically linked Python 2.3 to uClibc, libxml2 and libxslt producing a 2.5 meg exe that runs medusa .. a bit slow on a 48 mhz M5272 chip) I wish to retract this patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 23:14 Message: Logged In: YES user_id=21627 Can you please report what problem this is needed on? getaddrinfo.c is only used if you don't have getaddrinfo. However, if you don't have getaddrinfo, you shouldn't have gai_strerror, either. More specifically: What is the precise error that you get that triggered that change? ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2003-04-18 23:03 Message: Logged In: YES user_id=4631 Oops, sorry. The description of this patch is not correct, but it's still needed. pyconfig.h defines "HAVE_GAI_STRERROR" but Modules/getaddrinfo.c doesn't use the #define to control the declaration of gai_strerror() Note that socketmodule.c does use this #define. I'm suggesting that getaddrinfo.c should also use it to NOT define gai_strerror. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 22:15 Message: Logged In: YES user_id=21627 What specifically is the typo you are referring to? I cannot see any ifdef at all, and your patch does not correct any ifdef. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722839&group_id=5470 From noreply@sourceforge.net Fri Apr 18 23:22:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 15:22:11 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-26 00:16 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all .() occurances. What and are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where resulted in an (old-style) instance, and one where resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 02:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 02:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 01:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-26 00:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Fri Apr 18 23:48:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 15:48:54 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-26 00:16 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:48 Message: Logged In: YES user_id=34209 Oops, that patch contained a C++-ism, ceval.c:3504 and 3505 needed to be swapped. Uploaded a new version. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all .() occurances. What and are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where resulted in an (old-style) instance, and one where resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 02:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 02:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 01:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-26 00:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Sat Apr 19 00:15:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 16:15:26 -0700 Subject: [Patches] [ python-Patches-723940 ] Backport of recent sre fixes. Message-ID: Patches item #723940, was opened at 2003-04-18 23:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Nobody/Anonymous (nobody) Summary: Backport of recent sre fixes. Initial Comment: This patch should reproduce, in the release22-maint branch, an exact copy of the sre code currently in the 2.3 branch, with the single exception of the declaration of the module init function. All future patches should apply cleanly to both 2.3 and 2.2 branches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 From noreply@sourceforge.net Sat Apr 19 00:16:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 16:16:55 -0700 Subject: [Patches] [ python-Patches-723940 ] Backport of recent sre fixes. Message-ID: Patches item #723940, was opened at 2003-04-18 23:15 Message generated for change (Settings changed) made by herron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) >Assigned to: Guido van Rossum (gvanrossum) Summary: Backport of recent sre fixes. Initial Comment: This patch should reproduce, in the release22-maint branch, an exact copy of the sre code currently in the 2.3 branch, with the single exception of the declaration of the module init function. All future patches should apply cleanly to both 2.3 and 2.2 branches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 From noreply@sourceforge.net Sat Apr 19 01:22:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 17:22:11 -0700 Subject: [Patches] [ python-Patches-714348 ] Guard against segfaults in debug code Message-ID: Patches item #714348, was opened at 2003-04-03 13:14 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714348&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Invalid Priority: 3 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Guard against segfaults in debug code Initial Comment: When dumping invalid objects, we may as well avoid segfaults if possible. This allows us to extract as much information as possible before dieing, which may be handy in release builds etc. Trivial patch just to get started (as I actually hit this block!). Assign back if you are OK with it, or I will be OK with you not wanting to start this slippery slope. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-04-19 10:22 Message: Logged In: YES user_id=14198 Yeah, it is kinda pointless I agree :) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-08 07:44 Message: Logged In: YES user_id=31435 Do you think this helps? I'm OK with it either way. Normally, this routine doesn't exist in a release build, and in the debug build if we didn't segfault we'd end up calling Py_FatalError() after it returned. BTW. since we're on Windows, would it be simpler to call the Win32 IsBadReadPtr()? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-04-03 13:16 Message: Logged In: YES user_id=14198 Attaching patch. It indents a couple of blocks, so FYI, a --ignore-all-space diff is: RCS file: /cvsroot/python/python/dist/src/Objects/obmalloc.c,v retrieving revision 2.50 diff -w -r2.50 obmalloc.c 1126a1127 > int tail_reachable = 0; /* can we dereference tail without segfault */ 1163a1165,1175 > #ifdef MS_WINDOWS > _try { > #endif /* MS_WINDOWS */ > tail_reachable = *tail ? 1 : 1; /* if we don't die, it is reachable! */ > #ifdef MS_WINDOWS > } _except(1) { > /* tail_reachable remains 0 */ > } > #endif /* MS_WINDOWS */ > > if (tail_reachable) { 1185a1198,1200 > } else { > fprintf(stderr, "INVALID\n"); > } 1197c1212 < if (q < tail) { --- > if (q < tail && tail_reachable) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=714348&group_id=5470 From noreply@sourceforge.net Sat Apr 19 02:47:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 18:47:41 -0700 Subject: [Patches] [ python-Patches-684256 ] AutoThreadState implementation Message-ID: Patches item #684256, was opened at 2003-02-11 10:02 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684256&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: AutoThreadState implementation Initial Comment: An implementation of the AutoThreadState API, mainly for discussion purposes at this point. To be a PEP soon. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-04-19 11:47 Message: Logged In: YES user_id=14198 Attaching a new patch. This corrects the clearing of the threadstate, and uses the new names PyGILState_*. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-03-05 04:44 Message: Logged In: YES user_id=86307 It appears to me that PyAutoThreadState_Release calls PyThreadState_Clear after releasing the GIL (if the thread state was created by PyAutoThreadState_Ensure, then old state will be UNLOCKED, so PyEval_ReleaseThread will be called). It looks to me that, if the thread state is going to be deleted, the call to Clear it should be moved up to just before ReleaseThread, i.e.: if (oldstate == PyAutoThreadState_UNLOCKED) { if (tcur->autothreadstate_counter == 1) PyThreadState_Clear(tcur); PyEval_ReleaseThread(tcur); } ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-02-14 00:05 Message: Logged In: YES user_id=14198 Attaching a new patch that works perfectly. 2 checks remain in the code that will be debug only, but apart from that, it is pretty good. No changes at all to existing semantics. Tested on Linux and Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684256&group_id=5470 From noreply@sourceforge.net Sat Apr 19 02:56:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Apr 2003 18:56:21 -0700 Subject: [Patches] [ python-Patches-720468 ] nntplib file output for multiline commands Message-ID: Patches item #720468, was opened at 2003-04-13 00:34 Message generated for change (Comment added) made by tcarroll You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720468&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Terry Carroll (tcarroll) Assigned to: Guido van Rossum (gvanrossum) Summary: nntplib file output for multiline commands Initial Comment: This patch extends the support for file output, currently supported only for the body() method (added by Travers Naran in patch 462628) to all the other methods that invoke NNTP commands that produce multiline output; in particular: newgroups(), newnews(), list(), help(), xhdr(), xgtitle() and xover(). Many of these commands, especially list(), newgroups() and xhdr(), produce a large amount of output, and requiring that the output be maintained in memory, as in the present implementation, may impair performance of the application or the entire system, in limited-resource configurations. Routing the output to a file avoids this (and, if the file object is actually a subclass of the file class, the programmer can supply a write method that processes the NNTP command output as it is produced). The file parameter added by this patch is consistent with its present use in the body() method, specifying either a string containing a file name, or an open file object. ---------------------------------------------------------------------- >Comment By: Terry Carroll (tcarroll) Date: 2003-04-19 01:56 Message: Logged In: YES user_id=755895 Thanks, Guido. I'd have saved time if I implemented your second comment first :-) Changes made (dropping the guard makes the "File == None" v. "File is None" issue moot) and tested. I get an error trying to delete the previously uploaded nntplib diff. The one commented "nntplib code diff" is the right one. The other can be deleted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 16:18 Message: Logged In: YES user_id=6380 Two comments: - Instead of "if file == None" you should test for "if file is None". - In several routines you added "if file == None" guards around a for loop over the lines returned by self.longcmd(...). But self.longcmd() returns an empty list if given a file argument, so the for loop would execute zero times. I think it's better to drop the guard and simply let the empty loop take care of things. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720468&group_id=5470 From noreply@sourceforge.net Sat Apr 19 08:47:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 00:47:26 -0700 Subject: [Patches] [ python-Patches-716969 ] fix thread bug in 2.2.2 and later Message-ID: Patches item #716969, was opened at 2003-04-07 22:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg Klanderman (gregklanderman) Assigned to: Martin v. Löwis (loewis) Summary: fix thread bug in 2.2.2 and later Initial Comment: in at least 2.2.2 and later (and probably earlier), the pthread implementation of thread.create_new_thread() is no longer handling the inability to create a new thread properly - it returns as though a new thread was created but in fact no thread was started. the bug seems to have been introduced here: Python/thread_pthread.h: > revision 2.35 > date: 2001/10/16 21:13:49; author: gvanrossum; ... > Partial patch from SF #452266, by Jason Petrone. > > This changes Pythread_start_thread() to return the thread ID, or -1 > for an error. (It's technically an incompatible API change, but I > doubt anyone calls it.) it apepars that the same bug may exist in the nt and solaris thread implementations though i was not able to test this hypothesis. here's a test script to run import thread, time, traceback def foo(i): time.sleep(10) print "thread %3d finished" % (i,) for i in range(3000): try: v = thread.start_new_thread(foo, (i,)) print "started thread %d --> %s" % (i, v) except thread.error, e: print "thread limit reached: %d" % (i,) traceback.print_exc() break time.sleep(30) you'll notice that on 1.5.2, after around 256 threads are created, an error is raised, and that all the threads prior to this then complete a few seconds later. in 2.2.2, an error is never raised, but only about 1000 threads have actually been successfully created. patch is attached. i've taken the liberty of renaming one of the variables for clarity. greg gak@klanderman.net ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 09:47 Message: Logged In: YES user_id=21627 Thanks for the patch. I believe you are right about Solaris threads, and have applied the "obvious" fix; committed everything as thread_pthread.h 2.46 thread_solaris.h 2.19 thread_pthread.h 2.36.8.4 thread_solaris.h 2.16.10.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 From noreply@sourceforge.net Sat Apr 19 08:54:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 00:54:29 -0700 Subject: [Patches] [ python-Patches-679383 ] xmlrpclib: better string encoding in responce package Message-ID: Patches item #679383, was opened at 2003-02-03 10:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679383&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Mike D. Rozhnov (mrozhnov) Assigned to: Fredrik Lundh (effbot) Summary: xmlrpclib: better string encoding in responce package Initial Comment: ServerProxy class has optional 'encoding' argument. For now, this argument is used for packet encoding. 8-bit strings in the data structure are assumed to use this encoding, unicode strings converted to this encoding. But Unmarshaller class, that process response, use '_stringify' function for converting 7-bit strings to Python strings, 8-bit strings remains as unicode Python strings. It seems more logicaly to convert strings in responce package to Python strings with encoding which used in ServerProxy constructor. This patch adds optional 'encoding' argument to Unmarshaller class, Transport class and loads function. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 09:54 Message: Logged In: YES user_id=21627 The patch is out of date: Support for an optional encoding argument was implemented in xmlrpclib.py 1.19. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679383&group_id=5470 From noreply@sourceforge.net Sat Apr 19 08:57:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 00:57:51 -0700 Subject: [Patches] [ python-Patches-679392 ] SimpleXMLRPCServer: optional 'encoding' argument Message-ID: Patches item #679392, was opened at 2003-02-03 10:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679392&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike D. Rozhnov (mrozhnov) Assigned to: Fredrik Lundh (effbot) Summary: SimpleXMLRPCServer: optional 'encoding' argument Initial Comment: Note: this patch depend on xmlrpclib patch #679383 This patch allow encode unicode strings to 8-bit strings using 'encoding' parameter. This can be usefull if XML-RPC server process strings in non ASCII encodings. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 09:57 Message: Logged In: YES user_id=21627 This patch is incomplete: it should include a patch for the documentation as well (using \versionadded where appropriate). Please make sure you develop and test the patch with the latest Python CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679392&group_id=5470 From noreply@sourceforge.net Sat Apr 19 08:58:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 00:58:10 -0700 Subject: [Patches] [ python-Patches-679392 ] SimpleXMLRPCServer: optional 'encoding' argument Message-ID: Patches item #679392, was opened at 2003-02-03 10:47 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679392&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike D. Rozhnov (mrozhnov) >Assigned to: Martin v. Löwis (loewis) Summary: SimpleXMLRPCServer: optional 'encoding' argument Initial Comment: Note: this patch depend on xmlrpclib patch #679383 This patch allow encode unicode strings to 8-bit strings using 'encoding' parameter. This can be usefull if XML-RPC server process strings in non ASCII encodings. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 09:57 Message: Logged In: YES user_id=21627 This patch is incomplete: it should include a patch for the documentation as well (using \versionadded where appropriate). Please make sure you develop and test the patch with the latest Python CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679392&group_id=5470 From noreply@sourceforge.net Sat Apr 19 09:01:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 01:01:00 -0700 Subject: [Patches] [ python-Patches-628208 ] xmlrpclib: Optional 'nil' support Message-ID: Patches item #628208, was opened at 2002-10-24 21:33 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: A.M. Kuchling (akuchling) Summary: xmlrpclib: Optional 'nil' support Initial Comment: This patch doesn't include documentation or test suite updates yet, and only touches the < The extension is defined at http://ontosys.com/xml-rpc/extensions.html. Outstanding questions: * To generate , an option must be explicitly supplied to dumps(). is always accepted, and it can't be turned off. Is this OK? * Similarly, allow_none is on or off for a ServerProxy; you can't turn it on for just one method. (Seems a reasonable limitation...) * Should the parameter to enable it be named allow_none (Python term) or allow_nil (XML-RPC term)? * When allow_none is false and a None is encountered, this patch raises a ValueError. Is that the right exception, or should it use xmlrpclib.Error? Can anyone suggest a better message for the exception? * The FastMarshaller accelerator would also need to be updated. * Are we ever likely to change the default for allow_none to True? If so, how should we arrange things so we can warn people? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 10:01 Message: Logged In: YES user_id=21627 Since /F seems unresponsive, I'll accept the patch, on the provision that it is integrated before Python 2.3b1 (or after Python 2.3 is released), and that a documentation change is also committed. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-10-29 17:44 Message: Logged In: YES user_id=11375 Updated version of the patch: raises TypeError instead of ValueError, and uses Martin's suggested wording; thanks! Now it's up to /F to accept, decline, or request revisions to this patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 21:50 Message: Logged In: YES user_id=21627 On the exception: Currently, you get TypeError: cannot marshal objects and TypeError seems to be the right thing. The message might read cannot marshal None unless allow_none is enabled On allowing None by default: I'd assume that you would want to disable None only for "strictly-conforming" operation, so I'd expect to see an option strict (which then defaults to False). I don't know in what other ways we'd reasonably deviate from the spec. If that ever happens, I don't think a transitional warning is needed: existing applications continue to work. In general, in cases that produce an exception now, we don't need a transition procedure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 From noreply@sourceforge.net Sat Apr 19 09:40:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 01:40:45 -0700 Subject: [Patches] [ python-Patches-681152 ] Tiny patch for bug 612074: sre unicode escapes Message-ID: Patches item #681152, was opened at 2003-02-05 20:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681152&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fredrik Lundh (effbot) Summary: Tiny patch for bug 612074: sre unicode escapes Initial Comment: Bug report 612074 points out that this raises an exception: import re a = unichr(0x2039) b = u"["+re.escape(a)+u"]" re.compile(b) The exception is raised by an unnecessary call to str in sre_parse.py (in the function _class_escape); str (u'\u2039') raises a UnicodeError. The call is unnecessary because (for example) u'1' == '1', so no type conversion is necessary to test for membership in OCTDIGITS. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 10:40 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as sre_parse.py 1.57 test_sre.py 1.40 sre_parse.py 1.51.6.1 test_sre.py 1.35.6.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681152&group_id=5470 From noreply@sourceforge.net Sat Apr 19 09:50:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 01:50:58 -0700 Subject: [Patches] [ python-Patches-572936 ] (?(id/name)yes|no) re implementation Message-ID: Patches item #572936, was opened at 2002-06-24 03:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Fredrik Lundh (effbot) Summary: (?(id/name)yes|no) re implementation Initial Comment: This patch implements a regular expression feature, which allows some interesting patterns, in the same way as implemented in perl. For example, (?(1)yes|no) matches with "yes" if group "1" exists, and with "no", if it doesn't. Without this feature, the regular expression must be duplicated to get the same results. In addition to perl's feature, it will also accept a Python named group as argument. Here's an example: (<)?\w+@\w+(\.\w+)+(?(1)>) This is a poor email matching regular expression, which will match with or without the "<>" symbols. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 10:50 Message: Logged In: YES user_id=21627 If you add new opcodes, you should also change SRE_MAGIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 From noreply@sourceforge.net Sat Apr 19 10:40:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 02:40:49 -0700 Subject: [Patches] [ python-Patches-724135 ] remove tiny anomaly re bool() Message-ID: Patches item #724135, was opened at 2003-04-19 11:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724135&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: remove tiny anomaly re bool() Initial Comment: builtin types called without arguments -- int(), long(), float(), list(), dict(), tuple() -- return the false value of that type. bool() called without arguments raises an exception instead. This patch makes bool behave like the other builtin types, and adds tests for this "call type without arguments" behavior (for bool AND the other six builtin types). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724135&group_id=5470 From noreply@sourceforge.net Sat Apr 19 16:45:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 08:45:12 -0700 Subject: [Patches] [ python-Patches-684256 ] AutoThreadState implementation Message-ID: Patches item #684256, was opened at 2003-02-11 10:02 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684256&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: AutoThreadState implementation Initial Comment: An implementation of the AutoThreadState API, mainly for discussion purposes at this point. To be a PEP soon. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-04-20 01:45 Message: Logged In: YES user_id=14198 Checking in Include/pystate.h; new revision: 2.24; previous revision: 2.23 Checking in Include/pythread.h; new revision: 2.21; previous revision: 2.20 Checking in Lib/test/test_capi.py; new revision: 1.5; previous revision: 1.4 Checking in Modules/_testcapimodule.c; new revision: 1.22; previous revision: 1.21 Checking in Modules/posixmodule.c; new revision: 2.295; previous revision: 2.294 Checking in Python/ceval.c; new revision: 2.359; previous revision: 2.358 Checking in Python/pystate.c; new revision: 2.26; previous revision: 2.25 Checking in Python/pythonrun.c; new revision: 2.191; previous revision: 2.190 Checking in Python/thread.c; new revision: 2.46; previous revision: 2.45 Checking in Python/thread_sgi.h; new revision: 2.17; previous revision: 2.16 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-04-19 11:47 Message: Logged In: YES user_id=14198 Attaching a new patch. This corrects the clearing of the threadstate, and uses the new names PyGILState_*. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-03-05 04:44 Message: Logged In: YES user_id=86307 It appears to me that PyAutoThreadState_Release calls PyThreadState_Clear after releasing the GIL (if the thread state was created by PyAutoThreadState_Ensure, then old state will be UNLOCKED, so PyEval_ReleaseThread will be called). It looks to me that, if the thread state is going to be deleted, the call to Clear it should be moved up to just before ReleaseThread, i.e.: if (oldstate == PyAutoThreadState_UNLOCKED) { if (tcur->autothreadstate_counter == 1) PyThreadState_Clear(tcur); PyEval_ReleaseThread(tcur); } ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-02-14 00:05 Message: Logged In: YES user_id=14198 Attaching a new patch that works perfectly. 2 checks remain in the code that will be debug only, but apart from that, it is pretty good. No changes at all to existing semantics. Tested on Linux and Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684256&group_id=5470 From noreply@sourceforge.net Sat Apr 19 18:28:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 10:28:12 -0700 Subject: [Patches] [ python-Patches-658327 ] Add inet_pton and inet_ntop to socket Message-ID: Patches item #658327, was opened at 2002-12-24 16:00 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Neal Norwitz (nnorwitz) Summary: Add inet_pton and inet_ntop to socket Initial Comment: Patch is against current CVS and adds two socket module functions, inet_pton and inet_ntop. Both of these should be available on all platforms (because of other dependancies in the code) so I don't think portability is a problem. inet_ntop converts a packed IP address to a human-readable '.' or ':' separated string representation of the IP. inet_pton performs the reverse operation. (Potential) problems: inet_pton sets errno to ENOSPC, which may lead to a confusing error message. ---------------------------------------------------------------------- >Comment By: Jp Calderone (kuran) Date: 2003-04-19 13:28 Message: Logged In: YES user_id=366566 Based on the discussion, I've uploaded a new version of the patch. This one does the following: if HAVE_INET_PTON is defined, has_ipv6 is added to the socket module as True, socket_inet_pton and socket_inet_ntop are defined and added to the module, and use the underlying functions to perform the work, only AF_INET and AF_INET6 are supported and where appropriate, input lengths are checked against in_addr and in6_addr. Otherwise, has_ipv6 is added to the socket module as False and no other changes are made. No checks against IPV6_ENABLED are made, because AF_INET6 is always defined and only the platform functions are used to handle values passed to the functions. The patch also updates libsocket.tex, ACKS, NEWS, the socket.py module docstring, and adds tests for inet_pton, inet_ntop, inet_ntoa, and inet_aton to test_socket. Guido, I'm assigning this to you as per your suggestions on python-dev, and because Neal has told me in private correspondance that he doesn't think he'll have a chance to get to it before 2.3b1 comes out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-04 02:05 Message: Logged In: YES user_id=21627 My two suggestions aren't exclusive: If you have the native inet_pton, you can *always* support IPv6 addresses with that, regardless of whether --enable-ipv6 was passed to configure or not. If that is done, it will be a legitime test failure for inet_pton not to support IPv6 - after all, the primary reason to define this function was to support IPv6, so if the native function fails to do so, there is clearly a bug in the system. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 22:41 Message: Logged In: YES user_id=33168 I added the #ifdef, but that doesn't address the testing problem. If the platform has inet_pton, but doesn't have IPv6 ENABLED. The inet_pton will be exported, but there's no good way to tell if you can pass an IPv6 address. The only way to test if IPv6 is enabled would be to call inet_pton with AF_INET6, catch a socket.error and check if the exception message is "unknown address family". Since this is really a testing issue, perhaps that's best after all? Do you agree this should be done? * Remove has_ipv6 * Export inet_pton & inet_ntop only if defined for platform * Only try to test inet_pton/ntop if defined for platform * Modify the tests to pass a valid IPv6 test, catch socket.error, if the error message is "unknown address family", don't test ipv6 any further, if the error message is different, raise TestFailed, if no exception, test all IPv6 addresses ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 17:25 Message: Logged In: YES user_id=33168 As I recall, yes, has_ipv6 is only for tests. There was no way to distinguish if python was built with IPv6 support, since AF_INET6 was always defined. Your second approach sounds like it will work. I need to review the code, though. I've forgotten how it works. :-( ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 05:15 Message: Logged In: YES user_id=21627 The has_ipv6 test is only there for the tests? In that case, drop it, and just perform AF_INET6 conversions unconditionally. OTOH, I think we should not expose the emulated inet_pton: it doesn't set errno correctly, and offers no advantage over inet_addr. So wrap the entire code with HAVE_INET_PTON, and only perform the tests if the function is supported. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 21:40 Message: Logged In: YES user_id=33168 I was just about to check this in, but then I ran into a problem. IPv6 may not be enabled, even if the constant AF_INET6 exists. The cleanest way I saw to address this in the test was to add a has_ipv6 boolean constant to the socket module. Martin, do you think this is acceptable? Attached is a complete patch which should be safe (based on the discussion below), includes tests and doc changes. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:04 Message: Logged In: YES user_id=366566 Yea, testing for the proper input length is definitely something that should be done. The patch looks good, but for one thing. If the specified address family is neither AF_INET nor AF_INET6, the length won't be tested and the underlying inet_ntop will be called. This isn't a problem now (afaik) because only those two address families are support, but in a future libc version with more supported address families, it might open a similar hole to the one you've fixed. Perhaps the + } else { + PyErr_SetString(socket_error, "unknown address family"); + return NULL; + } should be moved up from the second if-grouping to follow the first if-grouping. Everything else looks good to me. Thanks for taking the time to look at this :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 22:49 Message: Logged In: YES user_id=33168 JP, do you agree with my comment on 2002-12-30 about the checks? I have attached an updated patch. Please review and verify this is correct. Thank you for the additional tests. Feel free to submit patches with additional tests for any and all modules! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-31 11:52 Message: Logged In: YES user_id=366566 Doc, NEWS, and test_socket patch attached. I didn't notice any inet_aton/inet_ntoa tests in the module so I added a couple for those as well (I excluded a test for inet_ntoa('255.255.255.255') ;) Also included are a couple IPv6 tests. I'm not sure if these are appropriate, since many systems may still lack the required support for them to pass. I'll leave it up to you to decide whether they should be commented out or removed or whatever. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 08:17 Message: Logged In: YES user_id=21627 I agree that such a change should be added. Neal, you have given this patch more attention than I did - please check it in when you consider it complete. I just like to point out that it is missing documentation changes (libsocket.tex), a NEWS entry, and a test case. kuran, please provide those as a single patch file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-30 19:11 Message: Logged In: YES user_id=33168 ISTM that in socket_inet_ntop() you need to verify the size of the packed value passed in. If the user passes an empty string, inet_ntop() could read beyond the buffer passed in, potentially causing a core dump. The checks could be something like this: if (af == AF_INET && len != sizeof(struct in_addr)) else if (af == AF_INET6 && len != sizeof(struct in6_addr)) Do this make sense? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-27 10:39 Message: Logged In: YES user_id=366566 The use case I have for it at the moment is a DNS server (Twisted.names). inet_pton allows me to handle IPv6 addresses, so it allows me to support AAAA and A6 records. I believe an IPv6 capable socks proxy would find this useful as well. Basically, low level network stuff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-27 05:23 Message: Logged In: YES user_id=21627 What is the rationale for providing this functionality? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-26 13:32 Message: Logged In: YES user_id=366566 Ooops, I made two, and uploaded the wrong one >:O Sorry. Dunno if it's still helpful, but here's the unified diff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 13:10 Message: Logged In: YES user_id=33168 Next time, please use context or unified diff. -c or -u option to cvs diff: cvs diff -c ... ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-24 16:05 Message: Logged In: YES user_id=366566 Sourceforge decided not to attach the file the first time... Here it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 From noreply@sourceforge.net Sat Apr 19 18:29:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 10:29:46 -0700 Subject: [Patches] [ python-Patches-658327 ] Add inet_pton and inet_ntop to socket Message-ID: Patches item #658327, was opened at 2002-12-24 16:00 Message generated for change (Settings changed) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Jp Calderone (kuran) >Assigned to: Guido van Rossum (gvanrossum) Summary: Add inet_pton and inet_ntop to socket Initial Comment: Patch is against current CVS and adds two socket module functions, inet_pton and inet_ntop. Both of these should be available on all platforms (because of other dependancies in the code) so I don't think portability is a problem. inet_ntop converts a packed IP address to a human-readable '.' or ':' separated string representation of the IP. inet_pton performs the reverse operation. (Potential) problems: inet_pton sets errno to ENOSPC, which may lead to a confusing error message. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-04-19 13:28 Message: Logged In: YES user_id=366566 Based on the discussion, I've uploaded a new version of the patch. This one does the following: if HAVE_INET_PTON is defined, has_ipv6 is added to the socket module as True, socket_inet_pton and socket_inet_ntop are defined and added to the module, and use the underlying functions to perform the work, only AF_INET and AF_INET6 are supported and where appropriate, input lengths are checked against in_addr and in6_addr. Otherwise, has_ipv6 is added to the socket module as False and no other changes are made. No checks against IPV6_ENABLED are made, because AF_INET6 is always defined and only the platform functions are used to handle values passed to the functions. The patch also updates libsocket.tex, ACKS, NEWS, the socket.py module docstring, and adds tests for inet_pton, inet_ntop, inet_ntoa, and inet_aton to test_socket. Guido, I'm assigning this to you as per your suggestions on python-dev, and because Neal has told me in private correspondance that he doesn't think he'll have a chance to get to it before 2.3b1 comes out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-04 02:05 Message: Logged In: YES user_id=21627 My two suggestions aren't exclusive: If you have the native inet_pton, you can *always* support IPv6 addresses with that, regardless of whether --enable-ipv6 was passed to configure or not. If that is done, it will be a legitime test failure for inet_pton not to support IPv6 - after all, the primary reason to define this function was to support IPv6, so if the native function fails to do so, there is clearly a bug in the system. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 22:41 Message: Logged In: YES user_id=33168 I added the #ifdef, but that doesn't address the testing problem. If the platform has inet_pton, but doesn't have IPv6 ENABLED. The inet_pton will be exported, but there's no good way to tell if you can pass an IPv6 address. The only way to test if IPv6 is enabled would be to call inet_pton with AF_INET6, catch a socket.error and check if the exception message is "unknown address family". Since this is really a testing issue, perhaps that's best after all? Do you agree this should be done? * Remove has_ipv6 * Export inet_pton & inet_ntop only if defined for platform * Only try to test inet_pton/ntop if defined for platform * Modify the tests to pass a valid IPv6 test, catch socket.error, if the error message is "unknown address family", don't test ipv6 any further, if the error message is different, raise TestFailed, if no exception, test all IPv6 addresses ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 17:25 Message: Logged In: YES user_id=33168 As I recall, yes, has_ipv6 is only for tests. There was no way to distinguish if python was built with IPv6 support, since AF_INET6 was always defined. Your second approach sounds like it will work. I need to review the code, though. I've forgotten how it works. :-( ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 05:15 Message: Logged In: YES user_id=21627 The has_ipv6 test is only there for the tests? In that case, drop it, and just perform AF_INET6 conversions unconditionally. OTOH, I think we should not expose the emulated inet_pton: it doesn't set errno correctly, and offers no advantage over inet_addr. So wrap the entire code with HAVE_INET_PTON, and only perform the tests if the function is supported. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 21:40 Message: Logged In: YES user_id=33168 I was just about to check this in, but then I ran into a problem. IPv6 may not be enabled, even if the constant AF_INET6 exists. The cleanest way I saw to address this in the test was to add a has_ipv6 boolean constant to the socket module. Martin, do you think this is acceptable? Attached is a complete patch which should be safe (based on the discussion below), includes tests and doc changes. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:04 Message: Logged In: YES user_id=366566 Yea, testing for the proper input length is definitely something that should be done. The patch looks good, but for one thing. If the specified address family is neither AF_INET nor AF_INET6, the length won't be tested and the underlying inet_ntop will be called. This isn't a problem now (afaik) because only those two address families are support, but in a future libc version with more supported address families, it might open a similar hole to the one you've fixed. Perhaps the + } else { + PyErr_SetString(socket_error, "unknown address family"); + return NULL; + } should be moved up from the second if-grouping to follow the first if-grouping. Everything else looks good to me. Thanks for taking the time to look at this :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 22:49 Message: Logged In: YES user_id=33168 JP, do you agree with my comment on 2002-12-30 about the checks? I have attached an updated patch. Please review and verify this is correct. Thank you for the additional tests. Feel free to submit patches with additional tests for any and all modules! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-31 11:52 Message: Logged In: YES user_id=366566 Doc, NEWS, and test_socket patch attached. I didn't notice any inet_aton/inet_ntoa tests in the module so I added a couple for those as well (I excluded a test for inet_ntoa('255.255.255.255') ;) Also included are a couple IPv6 tests. I'm not sure if these are appropriate, since many systems may still lack the required support for them to pass. I'll leave it up to you to decide whether they should be commented out or removed or whatever. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 08:17 Message: Logged In: YES user_id=21627 I agree that such a change should be added. Neal, you have given this patch more attention than I did - please check it in when you consider it complete. I just like to point out that it is missing documentation changes (libsocket.tex), a NEWS entry, and a test case. kuran, please provide those as a single patch file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-30 19:11 Message: Logged In: YES user_id=33168 ISTM that in socket_inet_ntop() you need to verify the size of the packed value passed in. If the user passes an empty string, inet_ntop() could read beyond the buffer passed in, potentially causing a core dump. The checks could be something like this: if (af == AF_INET && len != sizeof(struct in_addr)) else if (af == AF_INET6 && len != sizeof(struct in6_addr)) Do this make sense? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-27 10:39 Message: Logged In: YES user_id=366566 The use case I have for it at the moment is a DNS server (Twisted.names). inet_pton allows me to handle IPv6 addresses, so it allows me to support AAAA and A6 records. I believe an IPv6 capable socks proxy would find this useful as well. Basically, low level network stuff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-27 05:23 Message: Logged In: YES user_id=21627 What is the rationale for providing this functionality? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-26 13:32 Message: Logged In: YES user_id=366566 Ooops, I made two, and uploaded the wrong one >:O Sorry. Dunno if it's still helpful, but here's the unified diff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 13:10 Message: Logged In: YES user_id=33168 Next time, please use context or unified diff. -c or -u option to cvs diff: cvs diff -c ... ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-24 16:05 Message: Logged In: YES user_id=366566 Sourceforge decided not to attach the file the first time... Here it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 From noreply@sourceforge.net Sat Apr 19 18:53:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 10:53:24 -0700 Subject: [Patches] [ python-Patches-658327 ] Add inet_pton and inet_ntop to socket Message-ID: Patches item #658327, was opened at 2002-12-24 16:00 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: Jp Calderone (kuran) >Assigned to: Nobody/Anonymous (nobody) Summary: Add inet_pton and inet_ntop to socket Initial Comment: Patch is against current CVS and adds two socket module functions, inet_pton and inet_ntop. Both of these should be available on all platforms (because of other dependancies in the code) so I don't think portability is a problem. inet_ntop converts a packed IP address to a human-readable '.' or ':' separated string representation of the IP. inet_pton performs the reverse operation. (Potential) problems: inet_pton sets errno to ENOSPC, which may lead to a confusing error message. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 13:53 Message: Logged In: YES user_id=6380 I reject this patch on account of the fact that it clearly hasn't been tested: there's a call to memset() with 2 instead of 3 arguments. Given this lack of care I'm lowering the priority. Also note that there was a patch to test_heapq.py in the patch set. Poster is free to submit a new patch, but I can't guarantee that it'll make it into 2.3b1. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-04-19 13:28 Message: Logged In: YES user_id=366566 Based on the discussion, I've uploaded a new version of the patch. This one does the following: if HAVE_INET_PTON is defined, has_ipv6 is added to the socket module as True, socket_inet_pton and socket_inet_ntop are defined and added to the module, and use the underlying functions to perform the work, only AF_INET and AF_INET6 are supported and where appropriate, input lengths are checked against in_addr and in6_addr. Otherwise, has_ipv6 is added to the socket module as False and no other changes are made. No checks against IPV6_ENABLED are made, because AF_INET6 is always defined and only the platform functions are used to handle values passed to the functions. The patch also updates libsocket.tex, ACKS, NEWS, the socket.py module docstring, and adds tests for inet_pton, inet_ntop, inet_ntoa, and inet_aton to test_socket. Guido, I'm assigning this to you as per your suggestions on python-dev, and because Neal has told me in private correspondance that he doesn't think he'll have a chance to get to it before 2.3b1 comes out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-04 02:05 Message: Logged In: YES user_id=21627 My two suggestions aren't exclusive: If you have the native inet_pton, you can *always* support IPv6 addresses with that, regardless of whether --enable-ipv6 was passed to configure or not. If that is done, it will be a legitime test failure for inet_pton not to support IPv6 - after all, the primary reason to define this function was to support IPv6, so if the native function fails to do so, there is clearly a bug in the system. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 22:41 Message: Logged In: YES user_id=33168 I added the #ifdef, but that doesn't address the testing problem. If the platform has inet_pton, but doesn't have IPv6 ENABLED. The inet_pton will be exported, but there's no good way to tell if you can pass an IPv6 address. The only way to test if IPv6 is enabled would be to call inet_pton with AF_INET6, catch a socket.error and check if the exception message is "unknown address family". Since this is really a testing issue, perhaps that's best after all? Do you agree this should be done? * Remove has_ipv6 * Export inet_pton & inet_ntop only if defined for platform * Only try to test inet_pton/ntop if defined for platform * Modify the tests to pass a valid IPv6 test, catch socket.error, if the error message is "unknown address family", don't test ipv6 any further, if the error message is different, raise TestFailed, if no exception, test all IPv6 addresses ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 17:25 Message: Logged In: YES user_id=33168 As I recall, yes, has_ipv6 is only for tests. There was no way to distinguish if python was built with IPv6 support, since AF_INET6 was always defined. Your second approach sounds like it will work. I need to review the code, though. I've forgotten how it works. :-( ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 05:15 Message: Logged In: YES user_id=21627 The has_ipv6 test is only there for the tests? In that case, drop it, and just perform AF_INET6 conversions unconditionally. OTOH, I think we should not expose the emulated inet_pton: it doesn't set errno correctly, and offers no advantage over inet_addr. So wrap the entire code with HAVE_INET_PTON, and only perform the tests if the function is supported. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 21:40 Message: Logged In: YES user_id=33168 I was just about to check this in, but then I ran into a problem. IPv6 may not be enabled, even if the constant AF_INET6 exists. The cleanest way I saw to address this in the test was to add a has_ipv6 boolean constant to the socket module. Martin, do you think this is acceptable? Attached is a complete patch which should be safe (based on the discussion below), includes tests and doc changes. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:04 Message: Logged In: YES user_id=366566 Yea, testing for the proper input length is definitely something that should be done. The patch looks good, but for one thing. If the specified address family is neither AF_INET nor AF_INET6, the length won't be tested and the underlying inet_ntop will be called. This isn't a problem now (afaik) because only those two address families are support, but in a future libc version with more supported address families, it might open a similar hole to the one you've fixed. Perhaps the + } else { + PyErr_SetString(socket_error, "unknown address family"); + return NULL; + } should be moved up from the second if-grouping to follow the first if-grouping. Everything else looks good to me. Thanks for taking the time to look at this :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 22:49 Message: Logged In: YES user_id=33168 JP, do you agree with my comment on 2002-12-30 about the checks? I have attached an updated patch. Please review and verify this is correct. Thank you for the additional tests. Feel free to submit patches with additional tests for any and all modules! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-31 11:52 Message: Logged In: YES user_id=366566 Doc, NEWS, and test_socket patch attached. I didn't notice any inet_aton/inet_ntoa tests in the module so I added a couple for those as well (I excluded a test for inet_ntoa('255.255.255.255') ;) Also included are a couple IPv6 tests. I'm not sure if these are appropriate, since many systems may still lack the required support for them to pass. I'll leave it up to you to decide whether they should be commented out or removed or whatever. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 08:17 Message: Logged In: YES user_id=21627 I agree that such a change should be added. Neal, you have given this patch more attention than I did - please check it in when you consider it complete. I just like to point out that it is missing documentation changes (libsocket.tex), a NEWS entry, and a test case. kuran, please provide those as a single patch file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-30 19:11 Message: Logged In: YES user_id=33168 ISTM that in socket_inet_ntop() you need to verify the size of the packed value passed in. If the user passes an empty string, inet_ntop() could read beyond the buffer passed in, potentially causing a core dump. The checks could be something like this: if (af == AF_INET && len != sizeof(struct in_addr)) else if (af == AF_INET6 && len != sizeof(struct in6_addr)) Do this make sense? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-27 10:39 Message: Logged In: YES user_id=366566 The use case I have for it at the moment is a DNS server (Twisted.names). inet_pton allows me to handle IPv6 addresses, so it allows me to support AAAA and A6 records. I believe an IPv6 capable socks proxy would find this useful as well. Basically, low level network stuff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-27 05:23 Message: Logged In: YES user_id=21627 What is the rationale for providing this functionality? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-26 13:32 Message: Logged In: YES user_id=366566 Ooops, I made two, and uploaded the wrong one >:O Sorry. Dunno if it's still helpful, but here's the unified diff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 13:10 Message: Logged In: YES user_id=33168 Next time, please use context or unified diff. -c or -u option to cvs diff: cvs diff -c ... ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-24 16:05 Message: Logged In: YES user_id=366566 Sourceforge decided not to attach the file the first time... Here it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 From noreply@sourceforge.net Sat Apr 19 19:05:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 11:05:42 -0700 Subject: [Patches] [ python-Patches-720468 ] nntplib file output for multiline commands Message-ID: Patches item #720468, was opened at 2003-04-12 20:34 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720468&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Terry Carroll (tcarroll) Assigned to: Guido van Rossum (gvanrossum) Summary: nntplib file output for multiline commands Initial Comment: This patch extends the support for file output, currently supported only for the body() method (added by Travers Naran in patch 462628) to all the other methods that invoke NNTP commands that produce multiline output; in particular: newgroups(), newnews(), list(), help(), xhdr(), xgtitle() and xover(). Many of these commands, especially list(), newgroups() and xhdr(), produce a large amount of output, and requiring that the output be maintained in memory, as in the present implementation, may impair performance of the application or the entire system, in limited-resource configurations. Routing the output to a file avoids this (and, if the file object is actually a subclass of the file class, the programmer can supply a write method that processes the NNTP command output as it is produced). The file parameter added by this patch is consistent with its present use in the body() method, specifying either a string containing a file name, or an open file object. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 14:05 Message: Logged In: YES user_id=6380 Thanks, Terry! All checked in. ---------------------------------------------------------------------- Comment By: Terry Carroll (tcarroll) Date: 2003-04-18 21:56 Message: Logged In: YES user_id=755895 Thanks, Guido. I'd have saved time if I implemented your second comment first :-) Changes made (dropping the guard makes the "File == None" v. "File is None" issue moot) and tested. I get an error trying to delete the previously uploaded nntplib diff. The one commented "nntplib code diff" is the right one. The other can be deleted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 12:18 Message: Logged In: YES user_id=6380 Two comments: - Instead of "if file == None" you should test for "if file is None". - In several routines you added "if file == None" guards around a for loop over the lines returned by self.longcmd(...). But self.longcmd() returns an empty list if given a file argument, so the for loop would execute zero times. I think it's better to drop the guard and simply let the empty loop take care of things. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720468&group_id=5470 From noreply@sourceforge.net Sat Apr 19 19:08:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 11:08:41 -0700 Subject: [Patches] [ python-Patches-724135 ] remove tiny anomaly re bool() Message-ID: Patches item #724135, was opened at 2003-04-19 05:40 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724135&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Alex Martelli (aleax) >Assigned to: Guido van Rossum (gvanrossum) Summary: remove tiny anomaly re bool() Initial Comment: builtin types called without arguments -- int(), long(), float(), list(), dict(), tuple() -- return the false value of that type. bool() called without arguments raises an exception instead. This patch makes bool behave like the other builtin types, and adds tests for this "call type without arguments" behavior (for bool AND the other six builtin types). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 14:08 Message: Logged In: YES user_id=6380 I'll check this in, because I like the idea. I note there's a flaw in the execution: after ok = (x != NULL) && PyObject_IsTrue(x); the following line if (ok < 0) makes no sense; C's && doesn't work like Python's 'and', it always returns either 0 or 1. I'll fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724135&group_id=5470 From noreply@sourceforge.net Sat Apr 19 19:14:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 11:14:12 -0700 Subject: [Patches] [ python-Patches-658327 ] Add inet_pton and inet_ntop to socket Message-ID: Patches item #658327, was opened at 2002-12-24 16:00 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Add inet_pton and inet_ntop to socket Initial Comment: Patch is against current CVS and adds two socket module functions, inet_pton and inet_ntop. Both of these should be available on all platforms (because of other dependancies in the code) so I don't think portability is a problem. inet_ntop converts a packed IP address to a human-readable '.' or ':' separated string representation of the IP. inet_pton performs the reverse operation. (Potential) problems: inet_pton sets errno to ENOSPC, which may lead to a confusing error message. ---------------------------------------------------------------------- >Comment By: Jp Calderone (kuran) Date: 2003-04-19 14:14 Message: Logged In: YES user_id=366566 Once again I've screwed up and uploaded the wrong .diff. Here is the correct one, which I just applied to a clean CVS checkout and ran the regression tests for, just to be sure. One test does fail (test_tzset), but also fails on a clean CVS checkout. Additionally, as a correct to my last post, has_ipv6 is set based on the definition of IPV6_ENABLED, not HAVE_INET_PTON. My apologies for your wasted time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 13:53 Message: Logged In: YES user_id=6380 I reject this patch on account of the fact that it clearly hasn't been tested: there's a call to memset() with 2 instead of 3 arguments. Given this lack of care I'm lowering the priority. Also note that there was a patch to test_heapq.py in the patch set. Poster is free to submit a new patch, but I can't guarantee that it'll make it into 2.3b1. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-04-19 13:28 Message: Logged In: YES user_id=366566 Based on the discussion, I've uploaded a new version of the patch. This one does the following: if HAVE_INET_PTON is defined, has_ipv6 is added to the socket module as True, socket_inet_pton and socket_inet_ntop are defined and added to the module, and use the underlying functions to perform the work, only AF_INET and AF_INET6 are supported and where appropriate, input lengths are checked against in_addr and in6_addr. Otherwise, has_ipv6 is added to the socket module as False and no other changes are made. No checks against IPV6_ENABLED are made, because AF_INET6 is always defined and only the platform functions are used to handle values passed to the functions. The patch also updates libsocket.tex, ACKS, NEWS, the socket.py module docstring, and adds tests for inet_pton, inet_ntop, inet_ntoa, and inet_aton to test_socket. Guido, I'm assigning this to you as per your suggestions on python-dev, and because Neal has told me in private correspondance that he doesn't think he'll have a chance to get to it before 2.3b1 comes out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-04 02:05 Message: Logged In: YES user_id=21627 My two suggestions aren't exclusive: If you have the native inet_pton, you can *always* support IPv6 addresses with that, regardless of whether --enable-ipv6 was passed to configure or not. If that is done, it will be a legitime test failure for inet_pton not to support IPv6 - after all, the primary reason to define this function was to support IPv6, so if the native function fails to do so, there is clearly a bug in the system. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 22:41 Message: Logged In: YES user_id=33168 I added the #ifdef, but that doesn't address the testing problem. If the platform has inet_pton, but doesn't have IPv6 ENABLED. The inet_pton will be exported, but there's no good way to tell if you can pass an IPv6 address. The only way to test if IPv6 is enabled would be to call inet_pton with AF_INET6, catch a socket.error and check if the exception message is "unknown address family". Since this is really a testing issue, perhaps that's best after all? Do you agree this should be done? * Remove has_ipv6 * Export inet_pton & inet_ntop only if defined for platform * Only try to test inet_pton/ntop if defined for platform * Modify the tests to pass a valid IPv6 test, catch socket.error, if the error message is "unknown address family", don't test ipv6 any further, if the error message is different, raise TestFailed, if no exception, test all IPv6 addresses ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 17:25 Message: Logged In: YES user_id=33168 As I recall, yes, has_ipv6 is only for tests. There was no way to distinguish if python was built with IPv6 support, since AF_INET6 was always defined. Your second approach sounds like it will work. I need to review the code, though. I've forgotten how it works. :-( ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 05:15 Message: Logged In: YES user_id=21627 The has_ipv6 test is only there for the tests? In that case, drop it, and just perform AF_INET6 conversions unconditionally. OTOH, I think we should not expose the emulated inet_pton: it doesn't set errno correctly, and offers no advantage over inet_addr. So wrap the entire code with HAVE_INET_PTON, and only perform the tests if the function is supported. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 21:40 Message: Logged In: YES user_id=33168 I was just about to check this in, but then I ran into a problem. IPv6 may not be enabled, even if the constant AF_INET6 exists. The cleanest way I saw to address this in the test was to add a has_ipv6 boolean constant to the socket module. Martin, do you think this is acceptable? Attached is a complete patch which should be safe (based on the discussion below), includes tests and doc changes. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:04 Message: Logged In: YES user_id=366566 Yea, testing for the proper input length is definitely something that should be done. The patch looks good, but for one thing. If the specified address family is neither AF_INET nor AF_INET6, the length won't be tested and the underlying inet_ntop will be called. This isn't a problem now (afaik) because only those two address families are support, but in a future libc version with more supported address families, it might open a similar hole to the one you've fixed. Perhaps the + } else { + PyErr_SetString(socket_error, "unknown address family"); + return NULL; + } should be moved up from the second if-grouping to follow the first if-grouping. Everything else looks good to me. Thanks for taking the time to look at this :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 22:49 Message: Logged In: YES user_id=33168 JP, do you agree with my comment on 2002-12-30 about the checks? I have attached an updated patch. Please review and verify this is correct. Thank you for the additional tests. Feel free to submit patches with additional tests for any and all modules! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-31 11:52 Message: Logged In: YES user_id=366566 Doc, NEWS, and test_socket patch attached. I didn't notice any inet_aton/inet_ntoa tests in the module so I added a couple for those as well (I excluded a test for inet_ntoa('255.255.255.255') ;) Also included are a couple IPv6 tests. I'm not sure if these are appropriate, since many systems may still lack the required support for them to pass. I'll leave it up to you to decide whether they should be commented out or removed or whatever. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 08:17 Message: Logged In: YES user_id=21627 I agree that such a change should be added. Neal, you have given this patch more attention than I did - please check it in when you consider it complete. I just like to point out that it is missing documentation changes (libsocket.tex), a NEWS entry, and a test case. kuran, please provide those as a single patch file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-30 19:11 Message: Logged In: YES user_id=33168 ISTM that in socket_inet_ntop() you need to verify the size of the packed value passed in. If the user passes an empty string, inet_ntop() could read beyond the buffer passed in, potentially causing a core dump. The checks could be something like this: if (af == AF_INET && len != sizeof(struct in_addr)) else if (af == AF_INET6 && len != sizeof(struct in6_addr)) Do this make sense? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-27 10:39 Message: Logged In: YES user_id=366566 The use case I have for it at the moment is a DNS server (Twisted.names). inet_pton allows me to handle IPv6 addresses, so it allows me to support AAAA and A6 records. I believe an IPv6 capable socks proxy would find this useful as well. Basically, low level network stuff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-27 05:23 Message: Logged In: YES user_id=21627 What is the rationale for providing this functionality? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-26 13:32 Message: Logged In: YES user_id=366566 Ooops, I made two, and uploaded the wrong one >:O Sorry. Dunno if it's still helpful, but here's the unified diff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 13:10 Message: Logged In: YES user_id=33168 Next time, please use context or unified diff. -c or -u option to cvs diff: cvs diff -c ... ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-24 16:05 Message: Logged In: YES user_id=366566 Sourceforge decided not to attach the file the first time... Here it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 From noreply@sourceforge.net Sat Apr 19 19:15:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 11:15:16 -0700 Subject: [Patches] [ python-Patches-724135 ] remove tiny anomaly re bool() Message-ID: Patches item #724135, was opened at 2003-04-19 05:40 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724135&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Guido van Rossum (gvanrossum) Summary: remove tiny anomaly re bool() Initial Comment: builtin types called without arguments -- int(), long(), float(), list(), dict(), tuple() -- return the false value of that type. bool() called without arguments raises an exception instead. This patch makes bool behave like the other builtin types, and adds tests for this "call type without arguments" behavior (for bool AND the other six builtin types). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 14:15 Message: Logged In: YES user_id=6380 Checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 14:08 Message: Logged In: YES user_id=6380 I'll check this in, because I like the idea. I note there's a flaw in the execution: after ok = (x != NULL) && PyObject_IsTrue(x); the following line if (ok < 0) makes no sense; C's && doesn't work like Python's 'and', it always returns either 0 or 1. I'll fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724135&group_id=5470 From noreply@sourceforge.net Sat Apr 19 19:38:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 11:38:21 -0700 Subject: [Patches] [ python-Patches-553171 ] optionally make shelve less surprising Message-ID: Patches item #553171, was opened at 2002-05-07 10:13 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Alex Martelli (aleax) >Assigned to: Guido van Rossum (gvanrossum) Summary: optionally make shelve less surprising Initial Comment: shelve has highly surprising behavior wrt modifiable values: s = shelve.open('she.dat','c') s['ciao'] = range(3) s['ciao'].append(4) # doesn't "TAKE"! Explaining to beginners that s['ciao'] is returning a temporary object and the modification is done on the temporary thus "silently ignored" is hard indeed. It also makes shelve far less convenient than it could be (whenever modifiable values must be shelved). Having s keep track of all values it has returned may perhaps break some existing program (due to extra memory consumption and/or to lack of "implicit copy"/"snapshot" behavior) so I've made the 'caching' change optional and by default off. However it's now at least possible to obtain nonsurprising behavior: s = shelve.open('she.dat','c',smart=1) s['ciao'] = range(3) s['ciao'].append(4) # no surprises any more I suspect the 'smart=1' should be made the default, but, if we at least put it in now, then perhaps we can migrate to having it as the default very slowly and gradually. Alex ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-04-19 20:38 Message: Logged In: YES user_id=60314 done -- uploading the patch to code, test and docs, with the optional parameter renamed to writeback; docs specifying the issue, possible workaround w/o writeback, and writeback's performance-hit risks; and following raymond's suggestions. Not sure what "a NEWS entry" as martin requires should be a patch TO, though...? So I didn't do that yet -- lemme know!!! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 07:15 Message: Logged In: YES user_id=21627 dannu's code is currently unavailable... I see no reason to add yet another layer of indirection, and no other application of such a wrapper within Python. The trickiest aspect of this educational: If the default behaviour does not change (as it shouldn't), how can unsuspecting users avoid running into the trap? So this is much more a documentation problem than a code problem. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-03-30 23:59 Message: Logged In: YES user_id=60314 sure, but along what lines -- my previous patch's, or dannu's? let me know, and I'll get to work on it as soon as I'm back from Python-UK & short following trip (i..e around Apr 12) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-30 23:56 Message: Logged In: YES user_id=80475 The issue has arisen a couple of times of comp.lang.python. I think this patch would be helpful. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 23:43 Message: Logged In: YES user_id=21627 Would you then be willing to provide a complete patch (documentation, NEWS entry, test case)? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-03-30 23:26 Message: Logged In: YES user_id=60314 Yes, Martin, I'm still quite convinced shelve's behavior is generally surprising and often problematic, and even though the fixed suggested by both me and dannu are each imperfect (given the impossibility to find out, in general, whether an object has been modified), I think one or the other would still be better than the current situation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 23:18 Message: Logged In: YES user_id=21627 Alex, do you still think this should be implemented, in some form or other? ---------------------------------------------------------------------- Comment By: Holger P. Krekel (dannu) Date: 2002-05-10 02:47 Message: Logged In: YES user_id=83092 I'd suggest not changing shelve at all but providing a "cache-commit" dictionary (ccdict) which can wrap a shelf-instance (or any other simple dictish instance) and provides the 'non-surprising' behaviour. Some proof of concept code for the following properties is provided here http://home.trillke.net/~hpk/ccdict.py Current properties are: - ccdict wraps a dictionary-like object which in turn only needs to provide __getitem__, __setitem__, __delitem__,has_key - on first access of an element ccdict makes a lookup on the underlying dict and caches the item. - the next accesses work with the cached thing. Unsurprising dict-semantics are provided. - deleting an item is deferred and actually happens on commit() time. deleting an item and later on assigning to it works as expected (i.e. the assignment takes preference). - commit() transfers the items in the cache to the underlying dict and clears the cache.Prior to issuing commit no writeback to the underlying dict happens. - deleting an ccdict-instance does *not* commit any changes. You have to explicitely call commit(). If you want to work readonly, don't call commit. - clear() only cleares the cache and not the underlying dict - you can explicitely prune the cache (via cache.keys() etc.) before calling commit(). This lets you avoid writing back unmodified objects if this is an issue. It seems quite impossible to figure out automagically which objects have been modified and so the solution is to do it explicitely (or don't commit for readonly). holger ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 22:55 Message: Logged In: YES user_id=80475 A few more thoughts: Please change the "except:" lines to specify the exception being caught. Also, if GvR shows interest in the patch, we should update the library reference and add unittests. The docstring should also mention that the cache is kept in memory -- besides persistence, one of the forces for shelving is memory conservation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 20:43 Message: Logged In: YES user_id=80475 Nicely done! The code is clean and runs in the smart mode without problems on my existing programs. I agree that the patch solves a real world problem. The solution is clean, but a little expensive. If there were a way to be able to tell if an entry had been altered, it would save the 100% writeback. Unfortunately, I can't think of a way. The docstring could read more smoothly and plainly. Also, it should be clear that the cost of setting smart=1 is that 100% of the entries get rewritten on close. Two microscopically minor thoughts on the coding (feel free to disregard). Can some of the try/except blocks be replaced by something akin to 'if self.smart:'? For the writeback loop, consider 'for k,v in cache.iteritems()' as it takes less memory and saves a lookup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 18:38 Message: Logged In: YES user_id=21627 Even more important than the backwards compatibility might be the issue that it writes back all accessed objects on close, which might be expensive if there have been many read-only accesses. So I think the option name could be also 'slow'; although 'writeback' might be more technical. Also, I wonder whether write-back should be attempted if the shelve was opened read-only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 From noreply@sourceforge.net Sat Apr 19 19:42:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 11:42:47 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-25 18:16 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 14:42 Message: Logged In: YES user_id=6380 Alas, like others, I see a tiny slowdown on pystone (maybe 3 percent). This is with the default version of patch version 4 (fixed). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 18:48 Message: Logged In: YES user_id=34209 Oops, that patch contained a C++-ism, ceval.c:3504 and 3505 needed to be swapped. Uploaded a new version. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 18:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all .() occurances. What and are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where resulted in an (old-style) instance, and one where resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-17 20:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-17 20:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-17 19:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-25 18:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Sat Apr 19 19:51:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 11:51:47 -0700 Subject: [Patches] [ python-Patches-553171 ] optionally make shelve less surprising Message-ID: Patches item #553171, was opened at 2002-05-07 04:13 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 7 Submitted By: Alex Martelli (aleax) >Assigned to: Nobody/Anonymous (nobody) Summary: optionally make shelve less surprising Initial Comment: shelve has highly surprising behavior wrt modifiable values: s = shelve.open('she.dat','c') s['ciao'] = range(3) s['ciao'].append(4) # doesn't "TAKE"! Explaining to beginners that s['ciao'] is returning a temporary object and the modification is done on the temporary thus "silently ignored" is hard indeed. It also makes shelve far less convenient than it could be (whenever modifiable values must be shelved). Having s keep track of all values it has returned may perhaps break some existing program (due to extra memory consumption and/or to lack of "implicit copy"/"snapshot" behavior) so I've made the 'caching' change optional and by default off. However it's now at least possible to obtain nonsurprising behavior: s = shelve.open('she.dat','c',smart=1) s['ciao'] = range(3) s['ciao'].append(4) # no surprises any more I suspect the 'smart=1' should be made the default, but, if we at least put it in now, then perhaps we can migrate to having it as the default very slowly and gradually. Alex ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 14:51 Message: Logged In: YES user_id=6380 Looks good to me. Martin or Raymond, can you check it in? (Or should we just give Alex commit perms?) One unrelated note: the 'binary' parameter should really be upgraded to 'protocol' to match changes to the pickle module. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-19 14:38 Message: Logged In: YES user_id=60314 done -- uploading the patch to code, test and docs, with the optional parameter renamed to writeback; docs specifying the issue, possible workaround w/o writeback, and writeback's performance-hit risks; and following raymond's suggestions. Not sure what "a NEWS entry" as martin requires should be a patch TO, though...? So I didn't do that yet -- lemme know!!! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 00:15 Message: Logged In: YES user_id=21627 dannu's code is currently unavailable... I see no reason to add yet another layer of indirection, and no other application of such a wrapper within Python. The trickiest aspect of this educational: If the default behaviour does not change (as it shouldn't), how can unsuspecting users avoid running into the trap? So this is much more a documentation problem than a code problem. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-03-30 16:59 Message: Logged In: YES user_id=60314 sure, but along what lines -- my previous patch's, or dannu's? let me know, and I'll get to work on it as soon as I'm back from Python-UK & short following trip (i..e around Apr 12) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-30 16:56 Message: Logged In: YES user_id=80475 The issue has arisen a couple of times of comp.lang.python. I think this patch would be helpful. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 16:43 Message: Logged In: YES user_id=21627 Would you then be willing to provide a complete patch (documentation, NEWS entry, test case)? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-03-30 16:26 Message: Logged In: YES user_id=60314 Yes, Martin, I'm still quite convinced shelve's behavior is generally surprising and often problematic, and even though the fixed suggested by both me and dannu are each imperfect (given the impossibility to find out, in general, whether an object has been modified), I think one or the other would still be better than the current situation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 16:18 Message: Logged In: YES user_id=21627 Alex, do you still think this should be implemented, in some form or other? ---------------------------------------------------------------------- Comment By: Holger P. Krekel (dannu) Date: 2002-05-09 20:47 Message: Logged In: YES user_id=83092 I'd suggest not changing shelve at all but providing a "cache-commit" dictionary (ccdict) which can wrap a shelf-instance (or any other simple dictish instance) and provides the 'non-surprising' behaviour. Some proof of concept code for the following properties is provided here http://home.trillke.net/~hpk/ccdict.py Current properties are: - ccdict wraps a dictionary-like object which in turn only needs to provide __getitem__, __setitem__, __delitem__,has_key - on first access of an element ccdict makes a lookup on the underlying dict and caches the item. - the next accesses work with the cached thing. Unsurprising dict-semantics are provided. - deleting an item is deferred and actually happens on commit() time. deleting an item and later on assigning to it works as expected (i.e. the assignment takes preference). - commit() transfers the items in the cache to the underlying dict and clears the cache.Prior to issuing commit no writeback to the underlying dict happens. - deleting an ccdict-instance does *not* commit any changes. You have to explicitely call commit(). If you want to work readonly, don't call commit. - clear() only cleares the cache and not the underlying dict - you can explicitely prune the cache (via cache.keys() etc.) before calling commit(). This lets you avoid writing back unmodified objects if this is an issue. It seems quite impossible to figure out automagically which objects have been modified and so the solution is to do it explicitely (or don't commit for readonly). holger ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 16:55 Message: Logged In: YES user_id=80475 A few more thoughts: Please change the "except:" lines to specify the exception being caught. Also, if GvR shows interest in the patch, we should update the library reference and add unittests. The docstring should also mention that the cache is kept in memory -- besides persistence, one of the forces for shelving is memory conservation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 14:43 Message: Logged In: YES user_id=80475 Nicely done! The code is clean and runs in the smart mode without problems on my existing programs. I agree that the patch solves a real world problem. The solution is clean, but a little expensive. If there were a way to be able to tell if an entry had been altered, it would save the 100% writeback. Unfortunately, I can't think of a way. The docstring could read more smoothly and plainly. Also, it should be clear that the cost of setting smart=1 is that 100% of the entries get rewritten on close. Two microscopically minor thoughts on the coding (feel free to disregard). Can some of the try/except blocks be replaced by something akin to 'if self.smart:'? For the writeback loop, consider 'for k,v in cache.iteritems()' as it takes less memory and saves a lookup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 12:38 Message: Logged In: YES user_id=21627 Even more important than the backwards compatibility might be the issue that it writes back all accessed objects on close, which might be expensive if there have been many read-only accesses. So I think the option name could be also 'slow'; although 'writeback' might be more technical. Also, I wonder whether write-back should be attempted if the shelve was opened read-only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 From noreply@sourceforge.net Sat Apr 19 20:54:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 12:54:55 -0700 Subject: [Patches] [ python-Patches-553171 ] optionally make shelve less surprising Message-ID: Patches item #553171, was opened at 2002-05-07 03:13 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 7 Submitted By: Alex Martelli (aleax) >Assigned to: Raymond Hettinger (rhettinger) Summary: optionally make shelve less surprising Initial Comment: shelve has highly surprising behavior wrt modifiable values: s = shelve.open('she.dat','c') s['ciao'] = range(3) s['ciao'].append(4) # doesn't "TAKE"! Explaining to beginners that s['ciao'] is returning a temporary object and the modification is done on the temporary thus "silently ignored" is hard indeed. It also makes shelve far less convenient than it could be (whenever modifiable values must be shelved). Having s keep track of all values it has returned may perhaps break some existing program (due to extra memory consumption and/or to lack of "implicit copy"/"snapshot" behavior) so I've made the 'caching' change optional and by default off. However it's now at least possible to obtain nonsurprising behavior: s = shelve.open('she.dat','c',smart=1) s['ciao'] = range(3) s['ciao'].append(4) # no surprises any more I suspect the 'smart=1' should be made the default, but, if we at least put it in now, then perhaps we can migrate to having it as the default very slowly and gradually. Alex ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 13:51 Message: Logged In: YES user_id=6380 Looks good to me. Martin or Raymond, can you check it in? (Or should we just give Alex commit perms?) One unrelated note: the 'binary' parameter should really be upgraded to 'protocol' to match changes to the pickle module. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-19 13:38 Message: Logged In: YES user_id=60314 done -- uploading the patch to code, test and docs, with the optional parameter renamed to writeback; docs specifying the issue, possible workaround w/o writeback, and writeback's performance-hit risks; and following raymond's suggestions. Not sure what "a NEWS entry" as martin requires should be a patch TO, though...? So I didn't do that yet -- lemme know!!! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 00:15 Message: Logged In: YES user_id=21627 dannu's code is currently unavailable... I see no reason to add yet another layer of indirection, and no other application of such a wrapper within Python. The trickiest aspect of this educational: If the default behaviour does not change (as it shouldn't), how can unsuspecting users avoid running into the trap? So this is much more a documentation problem than a code problem. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-03-30 16:59 Message: Logged In: YES user_id=60314 sure, but along what lines -- my previous patch's, or dannu's? let me know, and I'll get to work on it as soon as I'm back from Python-UK & short following trip (i..e around Apr 12) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-30 16:56 Message: Logged In: YES user_id=80475 The issue has arisen a couple of times of comp.lang.python. I think this patch would be helpful. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 16:43 Message: Logged In: YES user_id=21627 Would you then be willing to provide a complete patch (documentation, NEWS entry, test case)? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-03-30 16:26 Message: Logged In: YES user_id=60314 Yes, Martin, I'm still quite convinced shelve's behavior is generally surprising and often problematic, and even though the fixed suggested by both me and dannu are each imperfect (given the impossibility to find out, in general, whether an object has been modified), I think one or the other would still be better than the current situation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 16:18 Message: Logged In: YES user_id=21627 Alex, do you still think this should be implemented, in some form or other? ---------------------------------------------------------------------- Comment By: Holger P. Krekel (dannu) Date: 2002-05-09 19:47 Message: Logged In: YES user_id=83092 I'd suggest not changing shelve at all but providing a "cache-commit" dictionary (ccdict) which can wrap a shelf-instance (or any other simple dictish instance) and provides the 'non-surprising' behaviour. Some proof of concept code for the following properties is provided here http://home.trillke.net/~hpk/ccdict.py Current properties are: - ccdict wraps a dictionary-like object which in turn only needs to provide __getitem__, __setitem__, __delitem__,has_key - on first access of an element ccdict makes a lookup on the underlying dict and caches the item. - the next accesses work with the cached thing. Unsurprising dict-semantics are provided. - deleting an item is deferred and actually happens on commit() time. deleting an item and later on assigning to it works as expected (i.e. the assignment takes preference). - commit() transfers the items in the cache to the underlying dict and clears the cache.Prior to issuing commit no writeback to the underlying dict happens. - deleting an ccdict-instance does *not* commit any changes. You have to explicitely call commit(). If you want to work readonly, don't call commit. - clear() only cleares the cache and not the underlying dict - you can explicitely prune the cache (via cache.keys() etc.) before calling commit(). This lets you avoid writing back unmodified objects if this is an issue. It seems quite impossible to figure out automagically which objects have been modified and so the solution is to do it explicitely (or don't commit for readonly). holger ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 15:55 Message: Logged In: YES user_id=80475 A few more thoughts: Please change the "except:" lines to specify the exception being caught. Also, if GvR shows interest in the patch, we should update the library reference and add unittests. The docstring should also mention that the cache is kept in memory -- besides persistence, one of the forces for shelving is memory conservation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 13:43 Message: Logged In: YES user_id=80475 Nicely done! The code is clean and runs in the smart mode without problems on my existing programs. I agree that the patch solves a real world problem. The solution is clean, but a little expensive. If there were a way to be able to tell if an entry had been altered, it would save the 100% writeback. Unfortunately, I can't think of a way. The docstring could read more smoothly and plainly. Also, it should be clear that the cost of setting smart=1 is that 100% of the entries get rewritten on close. Two microscopically minor thoughts on the coding (feel free to disregard). Can some of the try/except blocks be replaced by something akin to 'if self.smart:'? For the writeback loop, consider 'for k,v in cache.iteritems()' as it takes less memory and saves a lookup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 11:38 Message: Logged In: YES user_id=21627 Even more important than the backwards compatibility might be the issue that it writes back all accessed objects on close, which might be expensive if there have been many read-only accesses. So I think the option name could be also 'slow'; although 'writeback' might be more technical. Also, I wonder whether write-back should be attempted if the shelve was opened read-only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 From noreply@sourceforge.net Sat Apr 19 22:02:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 14:02:59 -0700 Subject: [Patches] [ python-Patches-553171 ] optionally make shelve less surprising Message-ID: Patches item #553171, was opened at 2002-05-07 10:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Alex Martelli (aleax) >Assigned to: Martin v. Löwis (loewis) Summary: optionally make shelve less surprising Initial Comment: shelve has highly surprising behavior wrt modifiable values: s = shelve.open('she.dat','c') s['ciao'] = range(3) s['ciao'].append(4) # doesn't "TAKE"! Explaining to beginners that s['ciao'] is returning a temporary object and the modification is done on the temporary thus "silently ignored" is hard indeed. It also makes shelve far less convenient than it could be (whenever modifiable values must be shelved). Having s keep track of all values it has returned may perhaps break some existing program (due to extra memory consumption and/or to lack of "implicit copy"/"snapshot" behavior) so I've made the 'caching' change optional and by default off. However it's now at least possible to obtain nonsurprising behavior: s = shelve.open('she.dat','c',smart=1) s['ciao'] = range(3) s['ciao'].append(4) # no surprises any more I suspect the 'smart=1' should be made the default, but, if we at least put it in now, then perhaps we can migrate to having it as the default very slowly and gradually. Alex ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 23:02 Message: Logged In: YES user_id=21627 I have committed the patch as libshelve.tex 1.20 shelve.py 1.21 test_shelve.py 1.4 NEWS 1.737 In these changes, the binary parameter got upgraded to protocol; binary was added after writeback for compatibility and pendingly deprecated. The test case usage of binary was mainly preserved, and protocol 2 test cases added. Alex: NEWS is Misc/NEWS; any non-bug fix change is listed there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 20:51 Message: Logged In: YES user_id=6380 Looks good to me. Martin or Raymond, can you check it in? (Or should we just give Alex commit perms?) One unrelated note: the 'binary' parameter should really be upgraded to 'protocol' to match changes to the pickle module. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-19 20:38 Message: Logged In: YES user_id=60314 done -- uploading the patch to code, test and docs, with the optional parameter renamed to writeback; docs specifying the issue, possible workaround w/o writeback, and writeback's performance-hit risks; and following raymond's suggestions. Not sure what "a NEWS entry" as martin requires should be a patch TO, though...? So I didn't do that yet -- lemme know!!! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 07:15 Message: Logged In: YES user_id=21627 dannu's code is currently unavailable... I see no reason to add yet another layer of indirection, and no other application of such a wrapper within Python. The trickiest aspect of this educational: If the default behaviour does not change (as it shouldn't), how can unsuspecting users avoid running into the trap? So this is much more a documentation problem than a code problem. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-03-30 23:59 Message: Logged In: YES user_id=60314 sure, but along what lines -- my previous patch's, or dannu's? let me know, and I'll get to work on it as soon as I'm back from Python-UK & short following trip (i..e around Apr 12) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-30 23:56 Message: Logged In: YES user_id=80475 The issue has arisen a couple of times of comp.lang.python. I think this patch would be helpful. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 23:43 Message: Logged In: YES user_id=21627 Would you then be willing to provide a complete patch (documentation, NEWS entry, test case)? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-03-30 23:26 Message: Logged In: YES user_id=60314 Yes, Martin, I'm still quite convinced shelve's behavior is generally surprising and often problematic, and even though the fixed suggested by both me and dannu are each imperfect (given the impossibility to find out, in general, whether an object has been modified), I think one or the other would still be better than the current situation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 23:18 Message: Logged In: YES user_id=21627 Alex, do you still think this should be implemented, in some form or other? ---------------------------------------------------------------------- Comment By: Holger P. Krekel (dannu) Date: 2002-05-10 02:47 Message: Logged In: YES user_id=83092 I'd suggest not changing shelve at all but providing a "cache-commit" dictionary (ccdict) which can wrap a shelf-instance (or any other simple dictish instance) and provides the 'non-surprising' behaviour. Some proof of concept code for the following properties is provided here http://home.trillke.net/~hpk/ccdict.py Current properties are: - ccdict wraps a dictionary-like object which in turn only needs to provide __getitem__, __setitem__, __delitem__,has_key - on first access of an element ccdict makes a lookup on the underlying dict and caches the item. - the next accesses work with the cached thing. Unsurprising dict-semantics are provided. - deleting an item is deferred and actually happens on commit() time. deleting an item and later on assigning to it works as expected (i.e. the assignment takes preference). - commit() transfers the items in the cache to the underlying dict and clears the cache.Prior to issuing commit no writeback to the underlying dict happens. - deleting an ccdict-instance does *not* commit any changes. You have to explicitely call commit(). If you want to work readonly, don't call commit. - clear() only cleares the cache and not the underlying dict - you can explicitely prune the cache (via cache.keys() etc.) before calling commit(). This lets you avoid writing back unmodified objects if this is an issue. It seems quite impossible to figure out automagically which objects have been modified and so the solution is to do it explicitely (or don't commit for readonly). holger ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 22:55 Message: Logged In: YES user_id=80475 A few more thoughts: Please change the "except:" lines to specify the exception being caught. Also, if GvR shows interest in the patch, we should update the library reference and add unittests. The docstring should also mention that the cache is kept in memory -- besides persistence, one of the forces for shelving is memory conservation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 20:43 Message: Logged In: YES user_id=80475 Nicely done! The code is clean and runs in the smart mode without problems on my existing programs. I agree that the patch solves a real world problem. The solution is clean, but a little expensive. If there were a way to be able to tell if an entry had been altered, it would save the 100% writeback. Unfortunately, I can't think of a way. The docstring could read more smoothly and plainly. Also, it should be clear that the cost of setting smart=1 is that 100% of the entries get rewritten on close. Two microscopically minor thoughts on the coding (feel free to disregard). Can some of the try/except blocks be replaced by something akin to 'if self.smart:'? For the writeback loop, consider 'for k,v in cache.iteritems()' as it takes less memory and saves a lookup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 18:38 Message: Logged In: YES user_id=21627 Even more important than the backwards compatibility might be the issue that it writes back all accessed objects on close, which might be expensive if there have been many read-only accesses. So I think the option name could be also 'slow'; although 'writeback' might be more technical. Also, I wonder whether write-back should be attempted if the shelve was opened read-only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 From noreply@sourceforge.net Sat Apr 19 22:30:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 14:30:44 -0700 Subject: [Patches] [ python-Patches-572936 ] (?(id/name)yes|no) re implementation Message-ID: Patches item #572936, was opened at 2002-06-24 01:41 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Martin v. Löwis (loewis) Summary: (?(id/name)yes|no) re implementation Initial Comment: This patch implements a regular expression feature, which allows some interesting patterns, in the same way as implemented in perl. For example, (?(1)yes|no) matches with "yes" if group "1" exists, and with "no", if it doesn't. Without this feature, the regular expression must be duplicated to get the same results. In addition to perl's feature, it will also accept a Python named group as argument. Here's an example: (<)?\w+@\w+(\.\w+)+(?(1)>) This is a poor email matching regular expression, which will match with or without the "<>" symbols. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 21:30 Message: Logged In: YES user_id=7887 That patch is around for a long time. Should I work on it, fixing that problem, and apply it? Do you agree with the feature inclusion? I remember that the main reason for implementing this is because it is hard to achieve the same results without it. You have to rewrite the whole match twice inside an or'ed group (e.g. "(<... match email ...>|... match email ...)"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 08:50 Message: Logged In: YES user_id=21627 If you add new opcodes, you should also change SRE_MAGIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 From noreply@sourceforge.net Sun Apr 20 00:53:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 16:53:03 -0700 Subject: [Patches] [ python-Patches-712900 ] sre fixes for lastindex and minimizing repeats+assertions Message-ID: Patches item #712900, was opened at 2003-03-31 19:54 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: sre fixes for lastindex and minimizing repeats+assertions Initial Comment: The attached patch fixes two bugs in _sre.c; it also does a bit of reorganization. First the bugs. 672491 points out that lastindex is calculated differently in 2.3 than in previous versions. This patch restores the previous behavior. Since lastindex cannot be restored (when backtracking) from lastmark alone, it is now saved and restored independently (by the LASTMARK_SAVE and RESTORE macros). The second bug appears when minimizing repeats are combined with assertions: >>> re.match('([ab]*?)(?=(b)?)c', 'abc').groups() ('ab', 'b') The second group should be None, since the 'b' is consumed by the first group. To fix this, it is necessary to save lastmark before attempting to match the tail in OP_MIN_UNTIL and to restore it if the tail fails to match. The reorganization has to do with the handling of the SRE_STATE's lastmark and mark array. The mark array tracks the start and end of capturing groups; lastmark is the highest index in the array so far encountered. Previously, whenever lastmark was restored back to a lower value (in 2.3a2 this is done in the lastmark_restore function), the tail of the mark array was NULLed out (using memset). This patch adopts the rule that all indexes greater than lastmark are invalid, so restoring lastmark does not also require clearing the tail. To ensure that indexes <= lastmark have valid pointers, OP_MARK checks if lastmark is being increased by more than one; if so, it NULLs out the intervening pointers. This rule also required changes to the GROUPREF opcodes and the state_getslice function to ensure that they do not access indexes greater than lastmark. For consistency, lastmark is now initialized to –1, to indicate that no entries in the mark array are valid. Needless to say, the reorganization is not necessary to fix the bugs; it may be a bad idea. It seems to be marginally faster than a version that fixes the bugs but is similar to the current code (including a memset inside the LASTMARK_RESTORE macro). One other thing. I have removed a test for string == Py_None from state_getslice, since I can’t find any way for string to be Py_None at that point (string is always the object providing the text to be searched; if it were Py_None, an exception should be raised by the getstring function called by state_init). Perhaps I missed something? ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:53 Message: Logged In: YES user_id=7887 Greg, this patch doesn't seem to compile in the latest CVS. Are you able to update it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 From noreply@sourceforge.net Sun Apr 20 02:51:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 18:51:22 -0700 Subject: [Patches] [ python-Patches-712900 ] sre fixes for lastindex and minimizing repeats+assertions Message-ID: Patches item #712900, was opened at 2003-03-31 19:54 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: sre fixes for lastindex and minimizing repeats+assertions Initial Comment: The attached patch fixes two bugs in _sre.c; it also does a bit of reorganization. First the bugs. 672491 points out that lastindex is calculated differently in 2.3 than in previous versions. This patch restores the previous behavior. Since lastindex cannot be restored (when backtracking) from lastmark alone, it is now saved and restored independently (by the LASTMARK_SAVE and RESTORE macros). The second bug appears when minimizing repeats are combined with assertions: >>> re.match('([ab]*?)(?=(b)?)c', 'abc').groups() ('ab', 'b') The second group should be None, since the 'b' is consumed by the first group. To fix this, it is necessary to save lastmark before attempting to match the tail in OP_MIN_UNTIL and to restore it if the tail fails to match. The reorganization has to do with the handling of the SRE_STATE's lastmark and mark array. The mark array tracks the start and end of capturing groups; lastmark is the highest index in the array so far encountered. Previously, whenever lastmark was restored back to a lower value (in 2.3a2 this is done in the lastmark_restore function), the tail of the mark array was NULLed out (using memset). This patch adopts the rule that all indexes greater than lastmark are invalid, so restoring lastmark does not also require clearing the tail. To ensure that indexes <= lastmark have valid pointers, OP_MARK checks if lastmark is being increased by more than one; if so, it NULLs out the intervening pointers. This rule also required changes to the GROUPREF opcodes and the state_getslice function to ensure that they do not access indexes greater than lastmark. For consistency, lastmark is now initialized to –1, to indicate that no entries in the mark array are valid. Needless to say, the reorganization is not necessary to fix the bugs; it may be a bad idea. It seems to be marginally faster than a version that fixes the bugs but is similar to the current code (including a memset inside the LASTMARK_RESTORE macro). One other thing. I have removed a test for string == Py_None from state_getslice, since I can’t find any way for string to be Py_None at that point (string is always the object providing the text to be searched; if it were Py_None, an exception should be raised by the getstring function called by state_init). Perhaps I missed something? ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 01:51 Message: Logged In: YES user_id=7887 Greg, thanks for mentioning that. I have fixed the first bug by myself, by backing out some of the changes I made in _sre.c:2.84. Can you please check it out and verify if it has the behavior you'd expect now? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:53 Message: Logged In: YES user_id=7887 Greg, this patch doesn't seem to compile in the latest CVS. Are you able to update it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 From noreply@sourceforge.net Sun Apr 20 03:35:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 19:35:28 -0700 Subject: [Patches] [ python-Patches-712900 ] sre fixes for lastindex and minimizing repeats+assertions Message-ID: Patches item #712900, was opened at 2003-03-31 19:54 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: sre fixes for lastindex and minimizing repeats+assertions Initial Comment: The attached patch fixes two bugs in _sre.c; it also does a bit of reorganization. First the bugs. 672491 points out that lastindex is calculated differently in 2.3 than in previous versions. This patch restores the previous behavior. Since lastindex cannot be restored (when backtracking) from lastmark alone, it is now saved and restored independently (by the LASTMARK_SAVE and RESTORE macros). The second bug appears when minimizing repeats are combined with assertions: >>> re.match('([ab]*?)(?=(b)?)c', 'abc').groups() ('ab', 'b') The second group should be None, since the 'b' is consumed by the first group. To fix this, it is necessary to save lastmark before attempting to match the tail in OP_MIN_UNTIL and to restore it if the tail fails to match. The reorganization has to do with the handling of the SRE_STATE's lastmark and mark array. The mark array tracks the start and end of capturing groups; lastmark is the highest index in the array so far encountered. Previously, whenever lastmark was restored back to a lower value (in 2.3a2 this is done in the lastmark_restore function), the tail of the mark array was NULLed out (using memset). This patch adopts the rule that all indexes greater than lastmark are invalid, so restoring lastmark does not also require clearing the tail. To ensure that indexes <= lastmark have valid pointers, OP_MARK checks if lastmark is being increased by more than one; if so, it NULLs out the intervening pointers. This rule also required changes to the GROUPREF opcodes and the state_getslice function to ensure that they do not access indexes greater than lastmark. For consistency, lastmark is now initialized to –1, to indicate that no entries in the mark array are valid. Needless to say, the reorganization is not necessary to fix the bugs; it may be a bad idea. It seems to be marginally faster than a version that fixes the bugs but is similar to the current code (including a memset inside the LASTMARK_RESTORE macro). One other thing. I have removed a test for string == Py_None from state_getslice, since I can’t find any way for string to be Py_None at that point (string is always the object providing the text to be searched; if it were Py_None, an exception should be raised by the getstring function called by state_init). Perhaps I missed something? ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 02:35 Message: Logged In: YES user_id=7887 Backing out the changes was not enough. I'll evaluate your solution. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 01:51 Message: Logged In: YES user_id=7887 Greg, thanks for mentioning that. I have fixed the first bug by myself, by backing out some of the changes I made in _sre.c:2.84. Can you please check it out and verify if it has the behavior you'd expect now? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:53 Message: Logged In: YES user_id=7887 Greg, this patch doesn't seem to compile in the latest CVS. Are you able to update it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 From spbrjod@peterlink.ru Sun Apr 20 03:51:51 2003 From: spbrjod@peterlink.ru (=?windows-1251?b?0/fl4e376SD25e3y8A==?=) Date: Sun, 20 Apr 2003 02:51:51 +0000 Subject: [Patches] =?windows-1251?b?0+/w7vnl7e3g/yDx6PHy5ezgIO3g6+7j7u7h6+7m5e3o/yAgZQ==?= Message-ID: <200304200251.SH6PBT7P@osuphczgvy.com> Ïðèãëàøàåì Âàñ ïðèíÿòü ó÷àñòèå â ñåìèíàðå "Óïðîùåííàÿ ñèñòåìà íàëîãîîáëîæåíèÿ äëÿ ìàëûõ ïðåäïðèÿòèé. Ïî èòîãàì 1-ãî êâàðòàëà ïðèìåíåíèÿ ÓÑÍ" 23 àïðåëÿ 2003 ã. êîíòàêòíûå òåëåôîíû 207-26-21, 789-81-90, 772-92-46 1. Óïðîùåííàÿ ñèñòåìà íàëîãîîáëîæåíèÿ (ÓÑÍ). Íàëîãè è ñáîðû, èñ÷èñëÿåìûå ïðè ÓÑÍ; â êàêèõ ñëó÷àÿõ îðãàíèçàöèè, ïåðåøåäøèå íà ÓÑÍ, ÿâëÿþòñÿ íàëîãîâûìè àãåíòàìè ïî ÍÄÑ, íàëîãó íà ïðèáûëü è äðóãèì íàëîãàì; ïðåèìóùåñòâà è íåäîñòàòêè íîâîé óïðîùåííîé ñèñòåìû íàëîãîîáëîæåíèÿ. 2. Äîõîäû: ñîñòàâ, äîêóìåíòèðîâàíèå, ïðèçíàíèå, îòðàæåíèå â êíèãå è äðóãèõ íàëîãîâûõ ðåãèñòðàõ. Äîõîäû, íå ó÷èòûâàåìûå äëÿ íàëîãîîáëîæåíèÿ. 3. Ðàñõîäû: ñîñòàâ, äîêóìåíòèðîâàíèå, ïðèçíàíèå, îòðàæåíèå â êíèãå è äðóãèõ íàëîãîâûõ ðåãèñòðàõ. 1) ðàñõîäû íà ïðèîáðåòåíèå îñíîâíûõ ñðåäñòâ; 2) ðàñõîäû íà ïðèîáðåòåíèå íåìàòåðèàëüíûõ àêòèâîâ; 3) ðàñõîäû íà ðåìîíò îñíîâíûõ ñðåäñòâ (â òîì ÷èñëå àðåíäîâàííûõ); 4) àðåíäíûå (â òîì ÷èñëå ëèçèíãîâûå) ïëàòåæè çà àðåíäóåìîå (â òîì ÷èñëå ïðèíÿòîå â ëèçèíã) èìóùåñòâî; 5) ìàòåðèàëüíûå ðàñõîäû; 6) ðàñõîäû íà îïëàòó òðóäà, âûïëàòó ïîñîáèé ïî âðåìåííîé íåòðóäîñïîñîáíîñòè â ñîîòâåòñòâèè ñ çàêîíîäàòåëüñòâîì Ðîññèéñêîé Ôåäåðàöèè; 7) ðàñõîäû íà îáÿçàòåëüíîå ñòðàõîâàíèå ðàáîòíèêîâ è èìóùåñòâà; 8) ñóììû íàëîãà íà äîáàâëåííóþ ñòîèìîñòü ïî ïðèîáðåòàåìûì òîâàðàì (ðàáîòàì è óñëóãàì); 9) ïðîöåíòû, óïëà÷èâàåìûå çà ïðåäîñòàâëåíèå â ïîëüçîâàíèå äåíåæíûõ ñðåäñòâ (êðåäèòîâ, çàéìîâ), à òàêæå ðàñõîäû, ñâÿçàííûå ñ îïëàòîé óñëóã, îêàçûâàåìûõ êðåäèòíûìè îðãàíèçàöèÿìè; 10) ðàñõîäû íà îáåñïå÷åíèå ïîæàðíîé áåçîïàñíîñòè íàëîãîïëàòåëüùèêà, ðàñõîäû íà óñëóãè ïî îõðàíå èìóùåñòâà è ò.ï.; 11) ñóììû òàìîæåííûõ ïëàòåæåé; 12) ðàñõîäû íà ñîäåðæàíèå ñëóæåáíîãî òðàíñïîðòà; 13) ðàñõîäû íà êîìàíäèðîâêè, â ÷àñòíîñòè íà: 14) ïëàòà ãîñóäàðñòâåííîìó è (èëè) ÷àñòíîìó íîòàðèóñó çà íîòàðèàëüíîå îôîðìëåíèå äîêóìåíòîâ; 15) ðàñõîäû íà àóäèòîðñêèå óñëóãè; 16) ðàñõîäû íà ïóáëèêàöèþ áóõãàëòåðñêîé îò÷åòíîñòè; 17) ðàñõîäû íà êàíöåëÿðñêèå òîâàðû; 18) ðàñõîäû íà ïî÷òîâûå, òåëåôîííûå, òåëåãðàôíûå è äðóãèå ïîäîáíûå óñëóãè, ðàñõîäû íà îïëàòó óñëóã ñâÿçè; 19) ðàñõîäû, ñâÿçàííûå ñ ïðèîáðåòåíèåì ïðàâà íà èñïîëüçîâàíèå ïðîãðàìì äëÿ ÝÂÌ è áàç äàííûõ; 20) ðàñõîäû íà ðåêëàìó; 21) ðàñõîäû íà ïîäãîòîâêó è îñâîåíèå íîâûõ ïðîèçâîäñòâ, öåõîâ è àãðåãàòîâ; 22) óïëà÷åííûå ñóììû íàëîãîâ è ñáîðîâ; 23) ðàñõîäû ïî îïëàòå ñòîèìîñòè òîâàðîâ, ïðèîáðåòåííûõ äëÿ äàëüíåéøåé ðåàëèçàöèè. Ðàñõîäû, íå ó÷èòûâàåìûå äëÿ íàëîãîîáëîæåíèÿ. 5. Ïîðÿäîê ðàñ÷åòà íàëîãà è åãî çà÷èñëåíèÿ â áþäæåòû è âíåáþäæåòíûå ôîíäû. 6. Îò÷åòíîñòü îðãàíèçàöèè, ïðèìåíÿþùåé ÓÑÍ. Ïîðÿäîê çàïîëíåíèÿ è ñðîêè ïîäà÷è íàëîãîâîé äåêëàðàöèè. Îò÷åòíîñòü ïî äðóãèì íàëîãàì, â òîì ÷èñëå ïî òåì, ïëàòåëüùèêàìè êîòîðûõ íå ÿâëÿþòñÿ îðãàíèçàöèè, ïðèìåíÿþùèå ÓÑÍ - êîãäà è â êàêîì îáúåìå åå ïîäàâàòü. 7. Îñîáåííîñòè òðóäîâûõ îòíîøåíèé ñ ðàáîòíèêàìè â îðãàíèçàöèè, ïðèìåíÿþùåé ÓÑÍ. Óïëàòà íàëîãà íà äîõîäû ôèçè÷åñêèõ ëèö è âçíîñîâ íà îáÿçàòåëüíîå ïåíñèîííîå ñòðàõîâàíèå. Îáåñïå÷åíèå ðàáîòíèêîâ ïîñîáèÿìè ïî âðåìåííîé íåòðóäîñïîñîáíîñòè. 8. Ñëîæíûå âîïðîñû ïðèìåíåíèÿ ÓÑÍ, â òîì ÷èñëå ïðîáëåìû ïåðåõîäà íà ÓÑÍ; ñïèñàíèÿ ÍÄÑ, îòðàæåííîãî íà ñ÷åòå 19 íà 1.01.03; ïðèçíàíèÿ ðàñõîäîâ íà ïðèîáðåòåíèå îñíîâíûõ ñðåäñòâ; ëèìèòèðóåìûå âèäû ðàñõîäîâ è ò.ä. 9. Îòâåòû íà âîïðîñû. Ñåìèíàð ñîñòîèòñÿ 23 àïðåëÿ (ì.Àêàäåìè÷åñêàÿ), 3 ìèíóòû îò ìåòðî. Ïðè ó÷àñòèè îäíîãî ÷åëîâåêà ñòîèìîñòü ëþáîãî ñåìèíàðà ñîñòàâëÿåò 3 900 ðóá., ñ ó÷åòîì ÍÄÑ.  ñòîèìîñòü ñåìèíàðà âêëþ÷åíû êîôå-ïàóçà, îáåä â ðåñòîðàíå è ðàçäàòî÷íûé ìàòåðèàë. Íà ñåìèíàðå âûñòóïàåò ÊËÈÌÎÂÀ Ìàðèíà Àðêàäüåâíà, ê.ý.í., ïðîôåññèîíàëüíûé áóõãàëòåð, àâòîð êíèã "Íàëîã íà äîõîäû ôèçè÷åñêèõ ëèö", "Êàê ïðàâèëüíî îôîðìèòü ó÷åòíóþ ïîëèòèêó îðãàíèçàöèè", "Äîêóìåíòîîáîðîò â áóõãàëòåðñêîì ó÷åòå", "Òðóäîâîé Êîäåêñ ÐÔ: ïîñòàòåéíûé êîììåíòàðèé", "Çàðàáîòíàÿ ïëàòà: ïðàêòè÷åñêîå ðóêîâîäñòâî", "Óïðîùåííàÿ ñèñòåìà íàëîãîîáëîæåíèÿ" è ìíîãèõ äðóãèõ. Îðãàíèçàòîð ñåìèíàðîâ Ìåæäóíàðîäíûé öåíòð îáó÷åíèÿ. Êîíòàêòíûå òåëåôîíû 207-26-21, 789-81-90, 772-92-46 spet From noreply@sourceforge.net Sun Apr 20 03:53:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 19:53:50 -0700 Subject: [Patches] [ python-Patches-711002 ] new test_urllib and patch for found urllib bug Message-ID: Patches item #711002, was opened at 2003-03-27 13:09 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711002&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Deleted Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: new test_urllib and patch for found urllib bug Initial Comment: Free time at PyCon led to me writing a new test_urllib (happy, Raymond? =). Since I have no guarantee that there would be a net connection (and didn't want to use it without user permission since I view using the 'network' resource as using sockets and not the Net) I wrote all tests using temporary files. And do this found a bug, sort of. The docs and doc string for urlretrieve() says the second value from the returned tuple should be None when a local file is passed as an argument. Well, it wasn't; it was returning an rfc2822.Message object like it does for remote files. So I patched it to match the docs. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-04-19 19:53 Message: Logged In: YES user_id=357491 I am going to delete this patch entirely since I can commit the new tests myself. As for the bug I found, I will wait until I have finished my tests before I submit a final patch to make any and all fixes to urllib. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-11 00:17 Message: Logged In: YES user_id=357491 This is bloody wonderful. Not only is the uploaded test_urllib.py the tet_urllib currently in CVS (i.e., the old one), but I can't find my new version nor can I delete the bad version I have uploaded (why can't SF let the creator of a patch delete files?). At least my patch for urllib.py is still okay. Damn it, now I have to write test_urllib from scratch, *again*. At least I am getting version 2.0 done before 1.0 is even out the door <0.1 wink>. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-03-30 14:06 Message: Logged In: YES user_id=357491 I just noticed that Skip uploaded test_urllibnet.py to test timeouts by connecting to python.org . Is it okay to write tests that connect to the Net when the `network' resourse is enabled? If so then I can add network tests to test_urllib.py . Oh, and the beginning of the 2nd paragraph for my summary should have read "And I did find a bug, sort of" and not the mess of broken grammar rules as I initially typed it in. =) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711002&group_id=5470 From noreply@sourceforge.net Sun Apr 20 03:57:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 19:57:34 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 10:49 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-19 19:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 08:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Sun Apr 20 05:55:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 21:55:39 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 19:14 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Fredrik Lundh (effbot) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-20 14:55 Message: Logged In: YES user_id=250749 This patch has made _sre.c more susceptible to optimisation breakage. The default autoconf optimisation setting for gcc is -O3. When _sre.c is so compiled with gcc 2.95.[34] on FreeBSD 4.[47] and gcc 3.2.1 on OS/2+EMX with this level of optimisation, I get a bus error (sig 10) when running test_sre (a SYS3171 on OS/2, which is the same thing). The bus error is not evident with -O2 for gcc 2.95.[34], or -O for gcc 3.2.1. Unfortunately I don't have any recent version of gcc (3.[12].x) available on FreeBSD yet to evaluate. I have no idea how to introduce a special optimisation setting just for _sre.c in autoconf, but lowering the optimisation for all other files seems a major backward step if its -O3 -> -O; dropping everything from -O3 to -O2 would be tolerable I think. As I'm not using autoconf on OS/2, dealing with this is not a problem there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 05:06 Message: Logged In: YES user_id=6380 Great! Sounds like a plan. ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-19 04:57 Message: Logged In: YES user_id=395736 I copied all the (8) sre files from the 2.3 branch to the release22-maint branch and compiled and ran the test. It worked flawlessly with the single exception that module init functions are declared as type DL_EXPORT(void) -- in 2.2 and as type PyMODINIT_FUNC -- in 2.3 If there are no considerations other than getting the tests to run successfully, then I'll declare success and produce a patch and submit it. OK? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 04:41 Message: Logged In: YES user_id=6380 The Python 2.2 maintenance branch is labeled with the CVS tag 'release22-maint'. I hope you know or can find out about working with CVS branches. Good luck! ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-16 02:50 Message: Logged In: YES user_id=395736 Sure, I'll port it to Python2.2. I'm surprised it dod not apply cleanly there, but then I don't know the history of previous patches (like when lastmark_restore was introduced). I guess copying all sre code will be the first thing to try. How do I get a dev version of Python 2.2? Yes, the *? code is all Greg Chapman's. He sent it to me the day I announced my volunteering to maintain the sre code. I wrote the test cases for it, and used it as a great way to learn my way through the code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-15 05:50 Message: Logged In: YES user_id=6380 Gary, I wonder if you could rework your fix for Python 2.2? The patch doesn't apply cleanly there; one of the problems is that lastmark_restore() doesn't exist. I wonder if maybe all of the _sre.c code should simply be copied to the 2.2 branch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-15 04:15 Message: Logged In: YES user_id=6380 Looks cool; I've checked this in unchanged, except changing one comment: the comment about the test for bug 545855 said it would generate errors during matching, while when I try it, the pattern generates a TypeError during compilation. I don't feel capable to review the code you added to _sre.c; I'll assign it to Fredrik, but I don't expect him to have time to look at it. It seems you haven't broken his requirement for this code to work back to Python 1.5.2. I'll backport to Python 2.2 as well. Do I understand correctly that the .*? addition is all Greg Chapman's work? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-15 02:46 Message: Logged In: YES user_id=6380 Will look at this ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Sun Apr 20 06:08:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 22:08:11 -0700 Subject: [Patches] [ python-Patches-712900 ] sre fixes for lastindex and minimizing repeats+assertions Message-ID: Patches item #712900, was opened at 2003-04-01 05:54 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Gustavo Niemeyer (niemeyer) Summary: sre fixes for lastindex and minimizing repeats+assertions Initial Comment: The attached patch fixes two bugs in _sre.c; it also does a bit of reorganization. First the bugs. 672491 points out that lastindex is calculated differently in 2.3 than in previous versions. This patch restores the previous behavior. Since lastindex cannot be restored (when backtracking) from lastmark alone, it is now saved and restored independently (by the LASTMARK_SAVE and RESTORE macros). The second bug appears when minimizing repeats are combined with assertions: >>> re.match('([ab]*?)(?=(b)?)c', 'abc').groups() ('ab', 'b') The second group should be None, since the 'b' is consumed by the first group. To fix this, it is necessary to save lastmark before attempting to match the tail in OP_MIN_UNTIL and to restore it if the tail fails to match. The reorganization has to do with the handling of the SRE_STATE's lastmark and mark array. The mark array tracks the start and end of capturing groups; lastmark is the highest index in the array so far encountered. Previously, whenever lastmark was restored back to a lower value (in 2.3a2 this is done in the lastmark_restore function), the tail of the mark array was NULLed out (using memset). This patch adopts the rule that all indexes greater than lastmark are invalid, so restoring lastmark does not also require clearing the tail. To ensure that indexes <= lastmark have valid pointers, OP_MARK checks if lastmark is being increased by more than one; if so, it NULLs out the intervening pointers. This rule also required changes to the GROUPREF opcodes and the state_getslice function to ensure that they do not access indexes greater than lastmark. For consistency, lastmark is now initialized to –1, to indicate that no entries in the mark array are valid. Needless to say, the reorganization is not necessary to fix the bugs; it may be a bad idea. It seems to be marginally faster than a version that fixes the bugs but is similar to the current code (including a memset inside the LASTMARK_RESTORE macro). One other thing. I have removed a test for string == Py_None from state_getslice, since I can’t find any way for string to be Py_None at that point (string is always the object providing the text to be searched; if it were Py_None, an exception should be raised by the getstring function called by state_init). Perhaps I missed something? ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-20 15:08 Message: Logged In: YES user_id=250749 Note that Guido checked in patch #720991, which incorporates some of Greg's work (at least that's what patch author Gary Herron notes) on April 14. That checkin makes _sre.c (more) sensitive to optimisation settings for me (see my comment against that patch). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 12:35 Message: Logged In: YES user_id=7887 Backing out the changes was not enough. I'll evaluate your solution. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 11:51 Message: Logged In: YES user_id=7887 Greg, thanks for mentioning that. I have fixed the first bug by myself, by backing out some of the changes I made in _sre.c:2.84. Can you please check it out and verify if it has the behavior you'd expect now? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 09:53 Message: Logged In: YES user_id=7887 Greg, this patch doesn't seem to compile in the latest CVS. Are you able to update it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 From noreply@sourceforge.net Sun Apr 20 07:23:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Apr 2003 23:23:37 -0700 Subject: [Patches] [ python-Patches-572936 ] (?(id/name)yes|no) re implementation Message-ID: Patches item #572936, was opened at 2002-06-24 03:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: (?(id/name)yes|no) re implementation Initial Comment: This patch implements a regular expression feature, which allows some interesting patterns, in the same way as implemented in perl. For example, (?(1)yes|no) matches with "yes" if group "1" exists, and with "no", if it doesn't. Without this feature, the regular expression must be duplicated to get the same results. In addition to perl's feature, it will also accept a Python named group as argument. Here's an example: (<)?\w+@\w+(\.\w+)+(?(1)>) This is a poor email matching regular expression, which will match with or without the "<>" symbols. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 08:23 Message: Logged In: YES user_id=21627 I like the patch in principle, but I have a number of additional concerns: - there are no test cases - the feature is declared experimental in perlre(1). Why? - Shouldn't there be a semantic restriction that the back reference is only allowed if it points to a group that is known to precede? I.e. is (X)|(?(1)Y) valid? If not, the restriction should be atleast documented, but if possible, it should also be implemented. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:30 Message: Logged In: YES user_id=7887 That patch is around for a long time. Should I work on it, fixing that problem, and apply it? Do you agree with the feature inclusion? I remember that the main reason for implementing this is because it is hard to achieve the same results without it. You have to rewrite the whole match twice inside an or'ed group (e.g. "(<... match email ...>|... match email ...)"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 10:50 Message: Logged In: YES user_id=21627 If you add new opcodes, you should also change SRE_MAGIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 From noreply@sourceforge.net Sun Apr 20 08:38:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 00:38:10 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 09:14 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Fredrik Lundh (effbot) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 07:38 Message: Logged In: YES user_id=7887 Gary, have you backported the 2.3 _sre.c to 2.2? If so, we must backport it again, since there are important fixes relative to 2.2 code, and relative to code introduced in 2.3. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-20 04:55 Message: Logged In: YES user_id=250749 This patch has made _sre.c more susceptible to optimisation breakage. The default autoconf optimisation setting for gcc is -O3. When _sre.c is so compiled with gcc 2.95.[34] on FreeBSD 4.[47] and gcc 3.2.1 on OS/2+EMX with this level of optimisation, I get a bus error (sig 10) when running test_sre (a SYS3171 on OS/2, which is the same thing). The bus error is not evident with -O2 for gcc 2.95.[34], or -O for gcc 3.2.1. Unfortunately I don't have any recent version of gcc (3.[12].x) available on FreeBSD yet to evaluate. I have no idea how to introduce a special optimisation setting just for _sre.c in autoconf, but lowering the optimisation for all other files seems a major backward step if its -O3 -> -O; dropping everything from -O3 to -O2 would be tolerable I think. As I'm not using autoconf on OS/2, dealing with this is not a problem there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 19:06 Message: Logged In: YES user_id=6380 Great! Sounds like a plan. ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-18 18:57 Message: Logged In: YES user_id=395736 I copied all the (8) sre files from the 2.3 branch to the release22-maint branch and compiled and ran the test. It worked flawlessly with the single exception that module init functions are declared as type DL_EXPORT(void) -- in 2.2 and as type PyMODINIT_FUNC -- in 2.3 If there are no considerations other than getting the tests to run successfully, then I'll declare success and produce a patch and submit it. OK? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-15 18:41 Message: Logged In: YES user_id=6380 The Python 2.2 maintenance branch is labeled with the CVS tag 'release22-maint'. I hope you know or can find out about working with CVS branches. Good luck! ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-15 16:50 Message: Logged In: YES user_id=395736 Sure, I'll port it to Python2.2. I'm surprised it dod not apply cleanly there, but then I don't know the history of previous patches (like when lastmark_restore was introduced). I guess copying all sre code will be the first thing to try. How do I get a dev version of Python 2.2? Yes, the *? code is all Greg Chapman's. He sent it to me the day I announced my volunteering to maintain the sre code. I wrote the test cases for it, and used it as a great way to learn my way through the code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 19:50 Message: Logged In: YES user_id=6380 Gary, I wonder if you could rework your fix for Python 2.2? The patch doesn't apply cleanly there; one of the problems is that lastmark_restore() doesn't exist. I wonder if maybe all of the _sre.c code should simply be copied to the 2.2 branch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 18:15 Message: Logged In: YES user_id=6380 Looks cool; I've checked this in unchanged, except changing one comment: the comment about the test for bug 545855 said it would generate errors during matching, while when I try it, the pattern generates a TypeError during compilation. I don't feel capable to review the code you added to _sre.c; I'll assign it to Fredrik, but I don't expect him to have time to look at it. It seems you haven't broken his requirement for this code to work back to Python 1.5.2. I'll backport to Python 2.2 as well. Do I understand correctly that the .*? addition is all Greg Chapman's work? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 16:46 Message: Logged In: YES user_id=6380 Will look at this ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Sun Apr 20 08:47:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 00:47:37 -0700 Subject: [Patches] [ python-Patches-712900 ] sre fixes for lastindex and minimizing repeats+assertions Message-ID: Patches item #712900, was opened at 2003-03-31 19:54 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Nobody/Anonymous (nobody) Summary: sre fixes for lastindex and minimizing repeats+assertions Initial Comment: The attached patch fixes two bugs in _sre.c; it also does a bit of reorganization. First the bugs. 672491 points out that lastindex is calculated differently in 2.3 than in previous versions. This patch restores the previous behavior. Since lastindex cannot be restored (when backtracking) from lastmark alone, it is now saved and restored independently (by the LASTMARK_SAVE and RESTORE macros). The second bug appears when minimizing repeats are combined with assertions: >>> re.match('([ab]*?)(?=(b)?)c', 'abc').groups() ('ab', 'b') The second group should be None, since the 'b' is consumed by the first group. To fix this, it is necessary to save lastmark before attempting to match the tail in OP_MIN_UNTIL and to restore it if the tail fails to match. The reorganization has to do with the handling of the SRE_STATE's lastmark and mark array. The mark array tracks the start and end of capturing groups; lastmark is the highest index in the array so far encountered. Previously, whenever lastmark was restored back to a lower value (in 2.3a2 this is done in the lastmark_restore function), the tail of the mark array was NULLed out (using memset). This patch adopts the rule that all indexes greater than lastmark are invalid, so restoring lastmark does not also require clearing the tail. To ensure that indexes <= lastmark have valid pointers, OP_MARK checks if lastmark is being increased by more than one; if so, it NULLs out the intervening pointers. This rule also required changes to the GROUPREF opcodes and the state_getslice function to ensure that they do not access indexes greater than lastmark. For consistency, lastmark is now initialized to –1, to indicate that no entries in the mark array are valid. Needless to say, the reorganization is not necessary to fix the bugs; it may be a bad idea. It seems to be marginally faster than a version that fixes the bugs but is similar to the current code (including a memset inside the LASTMARK_RESTORE macro). One other thing. I have removed a test for string == Py_None from state_getslice, since I can’t find any way for string to be Py_None at that point (string is always the object providing the text to be searched; if it were Py_None, an exception should be raised by the getstring function called by state_init). Perhaps I missed something? ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 07:47 Message: Logged In: YES user_id=7887 Greg, thank you very much for the patch. I've included the fixes without introducing the reorganization mentioned, for the sake of stability. Also, the second fix mentioned in your report don't fix the mentioned problem anymore, because of the change introduced by patch #720991. The new fix wasn't complicated though, and is included as well. About the reorganization, I don't have a strong opinion about it, and I'm also not sure about the real impact the new "mark reset" code will cause in the module. IMO we need to test it further. Andrew, that explains why the second fix greg mentions doesn't work anymore. Thanks for mentioning it. The changes were applied as: Modules/_sre.c: 2.91 Lib/test/re_tests.py: 1.35 Lib/test/test_sre.py: 1.41 ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-20 05:08 Message: Logged In: YES user_id=250749 Note that Guido checked in patch #720991, which incorporates some of Greg's work (at least that's what patch author Gary Herron notes) on April 14. That checkin makes _sre.c (more) sensitive to optimisation settings for me (see my comment against that patch). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 02:35 Message: Logged In: YES user_id=7887 Backing out the changes was not enough. I'll evaluate your solution. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 01:51 Message: Logged In: YES user_id=7887 Greg, thanks for mentioning that. I have fixed the first bug by myself, by backing out some of the changes I made in _sre.c:2.84. Can you please check it out and verify if it has the behavior you'd expect now? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:53 Message: Logged In: YES user_id=7887 Greg, this patch doesn't seem to compile in the latest CVS. Are you able to update it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 From noreply@sourceforge.net Sun Apr 20 09:12:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 01:12:13 -0700 Subject: [Patches] [ python-Patches-572936 ] (?(id/name)yes|no) re implementation Message-ID: Patches item #572936, was opened at 2002-06-24 01:41 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: (?(id/name)yes|no) re implementation Initial Comment: This patch implements a regular expression feature, which allows some interesting patterns, in the same way as implemented in perl. For example, (?(1)yes|no) matches with "yes" if group "1" exists, and with "no", if it doesn't. Without this feature, the regular expression must be duplicated to get the same results. In addition to perl's feature, it will also accept a Python named group as argument. Here's an example: (<)?\w+@\w+(\.\w+)+(?(1)>) This is a poor email matching regular expression, which will match with or without the "<>" symbols. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 08:12 Message: Logged In: YES user_id=7887 About the test cases, they're missing indeed. I can write some while applying the patch. About being experimental, IIRC, it is listed like experimental in the Perl documentation for several years, and will probably stay like this forever. :-) Anyway, IMO this shouldn't affect our evaluation of the importance of that feature for Python's sre. About semantic restriction, do you mean check if the backreference is lesser than the current group? Should be doable. OTOH, I don't understand your example. In "(X)|(?(1)Y)", there's no sense in using (?(1), as it will always be false. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 06:23 Message: Logged In: YES user_id=21627 I like the patch in principle, but I have a number of additional concerns: - there are no test cases - the feature is declared experimental in perlre(1). Why? - Shouldn't there be a semantic restriction that the back reference is only allowed if it points to a group that is known to precede? I.e. is (X)|(?(1)Y) valid? If not, the restriction should be atleast documented, but if possible, it should also be implemented. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 21:30 Message: Logged In: YES user_id=7887 That patch is around for a long time. Should I work on it, fixing that problem, and apply it? Do you agree with the feature inclusion? I remember that the main reason for implementing this is because it is hard to achieve the same results without it. You have to rewrite the whole match twice inside an or'ed group (e.g. "(<... match email ...>|... match email ...)"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 08:50 Message: Logged In: YES user_id=21627 If you add new opcodes, you should also change SRE_MAGIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 From noreply@sourceforge.net Sun Apr 20 11:47:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 03:47:50 -0700 Subject: [Patches] [ python-Patches-720991 ] Some bug fixes for regular ex code. Message-ID: Patches item #720991, was opened at 2003-04-14 01:14 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Fredrik Lundh (effbot) Summary: Some bug fixes for regular ex code. Initial Comment: A small fix for bug #545855 and Greg Chapman's addition of op code SRE_OP_MIN_REPEAT_ONE for eliminating recursion on simple uses of pattern '*?' on a long string. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-04-20 02:47 Message: Logged In: YES user_id=86307 Andrew, I used some block-scoped locals in the MIN_REPEAT_ONE branch (matchmax and c). I wonder if removing those would fix the optimization problem. I have a patch against the latest CVS version (2.91) which I can send you if you'd like. (The patch just moves the test for 65535 into the while statement and reuses i to hold the result of SRE_COUNT). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:38 Message: Logged In: YES user_id=7887 Gary, have you backported the 2.3 _sre.c to 2.2? If so, we must backport it again, since there are important fixes relative to 2.2 code, and relative to code introduced in 2.3. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-19 20:55 Message: Logged In: YES user_id=250749 This patch has made _sre.c more susceptible to optimisation breakage. The default autoconf optimisation setting for gcc is -O3. When _sre.c is so compiled with gcc 2.95.[34] on FreeBSD 4.[47] and gcc 3.2.1 on OS/2+EMX with this level of optimisation, I get a bus error (sig 10) when running test_sre (a SYS3171 on OS/2, which is the same thing). The bus error is not evident with -O2 for gcc 2.95.[34], or -O for gcc 3.2.1. Unfortunately I don't have any recent version of gcc (3.[12].x) available on FreeBSD yet to evaluate. I have no idea how to introduce a special optimisation setting just for _sre.c in autoconf, but lowering the optimisation for all other files seems a major backward step if its -O3 -> -O; dropping everything from -O3 to -O2 would be tolerable I think. As I'm not using autoconf on OS/2, dealing with this is not a problem there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 11:06 Message: Logged In: YES user_id=6380 Great! Sounds like a plan. ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-18 10:57 Message: Logged In: YES user_id=395736 I copied all the (8) sre files from the 2.3 branch to the release22-maint branch and compiled and ran the test. It worked flawlessly with the single exception that module init functions are declared as type DL_EXPORT(void) -- in 2.2 and as type PyMODINIT_FUNC -- in 2.3 If there are no considerations other than getting the tests to run successfully, then I'll declare success and produce a patch and submit it. OK? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-15 10:41 Message: Logged In: YES user_id=6380 The Python 2.2 maintenance branch is labeled with the CVS tag 'release22-maint'. I hope you know or can find out about working with CVS branches. Good luck! ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-15 08:50 Message: Logged In: YES user_id=395736 Sure, I'll port it to Python2.2. I'm surprised it dod not apply cleanly there, but then I don't know the history of previous patches (like when lastmark_restore was introduced). I guess copying all sre code will be the first thing to try. How do I get a dev version of Python 2.2? Yes, the *? code is all Greg Chapman's. He sent it to me the day I announced my volunteering to maintain the sre code. I wrote the test cases for it, and used it as a great way to learn my way through the code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 11:50 Message: Logged In: YES user_id=6380 Gary, I wonder if you could rework your fix for Python 2.2? The patch doesn't apply cleanly there; one of the problems is that lastmark_restore() doesn't exist. I wonder if maybe all of the _sre.c code should simply be copied to the 2.2 branch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 10:15 Message: Logged In: YES user_id=6380 Looks cool; I've checked this in unchanged, except changing one comment: the comment about the test for bug 545855 said it would generate errors during matching, while when I try it, the pattern generates a TypeError during compilation. I don't feel capable to review the code you added to _sre.c; I'll assign it to Fredrik, but I don't expect him to have time to look at it. It seems you haven't broken his requirement for this code to work back to Python 1.5.2. I'll backport to Python 2.2 as well. Do I understand correctly that the .*? addition is all Greg Chapman's work? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 08:46 Message: Logged In: YES user_id=6380 Will look at this ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720991&group_id=5470 From noreply@sourceforge.net Sun Apr 20 13:33:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 05:33:09 -0700 Subject: [Patches] [ python-Patches-712900 ] sre fixes for lastindex and minimizing repeats+assertions Message-ID: Patches item #712900, was opened at 2003-03-31 10:54 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: sre fixes for lastindex and minimizing repeats+assertions Initial Comment: The attached patch fixes two bugs in _sre.c; it also does a bit of reorganization. First the bugs. 672491 points out that lastindex is calculated differently in 2.3 than in previous versions. This patch restores the previous behavior. Since lastindex cannot be restored (when backtracking) from lastmark alone, it is now saved and restored independently (by the LASTMARK_SAVE and RESTORE macros). The second bug appears when minimizing repeats are combined with assertions: >>> re.match('([ab]*?)(?=(b)?)c', 'abc').groups() ('ab', 'b') The second group should be None, since the 'b' is consumed by the first group. To fix this, it is necessary to save lastmark before attempting to match the tail in OP_MIN_UNTIL and to restore it if the tail fails to match. The reorganization has to do with the handling of the SRE_STATE's lastmark and mark array. The mark array tracks the start and end of capturing groups; lastmark is the highest index in the array so far encountered. Previously, whenever lastmark was restored back to a lower value (in 2.3a2 this is done in the lastmark_restore function), the tail of the mark array was NULLed out (using memset). This patch adopts the rule that all indexes greater than lastmark are invalid, so restoring lastmark does not also require clearing the tail. To ensure that indexes <= lastmark have valid pointers, OP_MARK checks if lastmark is being increased by more than one; if so, it NULLs out the intervening pointers. This rule also required changes to the GROUPREF opcodes and the state_getslice function to ensure that they do not access indexes greater than lastmark. For consistency, lastmark is now initialized to –1, to indicate that no entries in the mark array are valid. Needless to say, the reorganization is not necessary to fix the bugs; it may be a bad idea. It seems to be marginally faster than a version that fixes the bugs but is similar to the current code (including a memset inside the LASTMARK_RESTORE macro). One other thing. I have removed a test for string == Py_None from state_getslice, since I can’t find any way for string to be Py_None at that point (string is always the object providing the text to be searched; if it were Py_None, an exception should be raised by the getstring function called by state_init). Perhaps I missed something? ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2003-04-20 04:33 Message: Logged In: YES user_id=86307 Gustavo, thanks for reworking and applying the patch. And thanks for catching the bug in the MIN_REPEAT_ONE where I was not calling lastmark_restore in the right place; it does need to be inside the loop (though I think it could be at the bottom -- it's not necessary if SRE_COUNT returns 0). I note in your checkin message you are concerned about whether all calls to SRE_MATCH need to be protected by LASTMATCH_SAVE/RESTORE. These should only be necessary where SRE_MATCH returns 0 but nevertheless matching continues (i.e., a backtrack point or an alternative). So they are clearly not necessary for ASSERT and REPEAT. ASSERT_NOT is an interesting case. Right now, a capturing group (inside the negative assertion) which matches before the subpattern fails is reported as having matched; this is the way Perl works. You could argue that it would be more consistent for these groups always to report as unmatched (Jeffrey Friedl implies as much in the first edition of his book), in which case the ASSERT_NOT should be surrounded by LASTMARK_SAVE/RESTORE. Anyway, it should not be necessary to protect the first part of the MAX_UNTIL and MIN_UNTIL opcodes (the part which assures the repeat has matched the minimum number of times); if this part fails, it causes this invocation of SRE_MATCH to return 0. I note that you have protected this part of MAX_UNTIL but not MIN_UNTIL. We should probably be consistent here and remove the protection from MAX_UNTIL. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:47 Message: Logged In: YES user_id=7887 Greg, thank you very much for the patch. I've included the fixes without introducing the reorganization mentioned, for the sake of stability. Also, the second fix mentioned in your report don't fix the mentioned problem anymore, because of the change introduced by patch #720991. The new fix wasn't complicated though, and is included as well. About the reorganization, I don't have a strong opinion about it, and I'm also not sure about the real impact the new "mark reset" code will cause in the module. IMO we need to test it further. Andrew, that explains why the second fix greg mentions doesn't work anymore. Thanks for mentioning it. The changes were applied as: Modules/_sre.c: 2.91 Lib/test/re_tests.py: 1.35 Lib/test/test_sre.py: 1.41 ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-19 21:08 Message: Logged In: YES user_id=250749 Note that Guido checked in patch #720991, which incorporates some of Greg's work (at least that's what patch author Gary Herron notes) on April 14. That checkin makes _sre.c (more) sensitive to optimisation settings for me (see my comment against that patch). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 18:35 Message: Logged In: YES user_id=7887 Backing out the changes was not enough. I'll evaluate your solution. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 17:51 Message: Logged In: YES user_id=7887 Greg, thanks for mentioning that. I have fixed the first bug by myself, by backing out some of the changes I made in _sre.c:2.84. Can you please check it out and verify if it has the behavior you'd expect now? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 15:53 Message: Logged In: YES user_id=7887 Greg, this patch doesn't seem to compile in the latest CVS. Are you able to update it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 From noreply@sourceforge.net Sun Apr 20 17:17:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 09:17:01 -0700 Subject: [Patches] [ python-Patches-711448 ] Warn about inter-module assignments shadowing builtins Message-ID: Patches item #711448, was opened at 2003-03-28 17:12 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Guido van Rossum (gvanrossum) Summary: Warn about inter-module assignments shadowing builtins Initial Comment: The attached patch modifies module tp_setattro to warn about code that adds a name to the globals of another module that shadows a builtin. Unfortunately, there are other ways to modify module globals (e.g. using vars() and mutating the dictionary). There are a few issues with module objects that I'm not clear about. For example, do modules always have a md_dict that is a PyDictObject? ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-04-20 16:17 Message: Logged In: YES user_id=35752 Is it okay if I move the list to the bltinmodule as a non-static variable? That would make it easier for the compiler to use the list if or when it was changed to optimize builtin lookup. Also, is the basic idea of this patch sound? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 19:01 Message: Logged In: YES user_id=6380 Hm, it's kind of ugly to list all built-in names explicitly; this list will be out of sync whenever a new built-in is added. Can't you access the __builtin__ module and use its keys? (One way to get the __builtin__ module is to use PySys_GetObject("modules"), which should give you sys.modules, and take it from there; you can count on __builtin__ to be there, and if it's not, forget the whole thing.) ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-03-28 17:15 Message: Logged In: YES user_id=35752 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 From noreply@sourceforge.net Sun Apr 20 20:06:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 12:06:51 -0700 Subject: [Patches] [ python-Patches-628208 ] xmlrpclib: Optional 'nil' support Message-ID: Patches item #628208, was opened at 2002-10-24 15:33 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: xmlrpclib: Optional 'nil' support Initial Comment: This patch doesn't include documentation or test suite updates yet, and only touches the < The extension is defined at http://ontosys.com/xml-rpc/extensions.html. Outstanding questions: * To generate , an option must be explicitly supplied to dumps(). is always accepted, and it can't be turned off. Is this OK? * Similarly, allow_none is on or off for a ServerProxy; you can't turn it on for just one method. (Seems a reasonable limitation...) * Should the parameter to enable it be named allow_none (Python term) or allow_nil (XML-RPC term)? * When allow_none is false and a None is encountered, this patch raises a ValueError. Is that the right exception, or should it use xmlrpclib.Error? Can anyone suggest a better message for the exception? * The FastMarshaller accelerator would also need to be updated. * Are we ever likely to change the default for allow_none to True? If so, how should we arrange things so we can warn people? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-04-20 15:06 Message: Logged In: YES user_id=11375 Should I leave the name of the 'allow_none' parameter alone, or should I change it to 'strict' and default it to True? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 04:01 Message: Logged In: YES user_id=21627 Since /F seems unresponsive, I'll accept the patch, on the provision that it is integrated before Python 2.3b1 (or after Python 2.3 is released), and that a documentation change is also committed. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-10-29 11:44 Message: Logged In: YES user_id=11375 Updated version of the patch: raises TypeError instead of ValueError, and uses Martin's suggested wording; thanks! Now it's up to /F to accept, decline, or request revisions to this patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 15:50 Message: Logged In: YES user_id=21627 On the exception: Currently, you get TypeError: cannot marshal objects and TypeError seems to be the right thing. The message might read cannot marshal None unless allow_none is enabled On allowing None by default: I'd assume that you would want to disable None only for "strictly-conforming" operation, so I'd expect to see an option strict (which then defaults to False). I don't know in what other ways we'd reasonably deviate from the spec. If that ever happens, I don't think a transitional warning is needed: existing applications continue to work. In general, in cases that produce an exception now, we don't need a transition procedure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 From noreply@sourceforge.net Sun Apr 20 21:09:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 13:09:16 -0700 Subject: [Patches] [ python-Patches-723940 ] Backport of recent sre fixes. Message-ID: Patches item #723940, was opened at 2003-04-18 19:15 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: Backport of recent sre fixes. Initial Comment: This patch should reproduce, in the release22-maint branch, an exact copy of the sre code currently in the 2.3 branch, with the single exception of the declaration of the module init function. All future patches should apply cleanly to both 2.3 and 2.2 branches. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-20 16:09 Message: Logged In: YES user_id=6380 Assigning this to Gustavo Niemeyer, who found some problems with this code in 2.3. Gustavo, would you mind working with Gary on backporting this properly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 From noreply@sourceforge.net Sun Apr 20 22:20:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 14:20:36 -0700 Subject: [Patches] [ python-Patches-711448 ] Warn about inter-module assignments shadowing builtins Message-ID: Patches item #711448, was opened at 2003-03-28 12:12 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Warn about inter-module assignments shadowing builtins Initial Comment: The attached patch modifies module tp_setattro to warn about code that adds a name to the globals of another module that shadows a builtin. Unfortunately, there are other ways to modify module globals (e.g. using vars() and mutating the dictionary). There are a few issues with module objects that I'm not clear about. For example, do modules always have a md_dict that is a PyDictObject? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-20 17:20 Message: Logged In: YES user_id=6380 The basic idea of the patch is sound. Why can't you check whether the name is in __builtin__.__dict__ ? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-04-20 12:17 Message: Logged In: YES user_id=35752 Is it okay if I move the list to the bltinmodule as a non-static variable? That would make it easier for the compiler to use the list if or when it was changed to optimize builtin lookup. Also, is the basic idea of this patch sound? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 15:01 Message: Logged In: YES user_id=6380 Hm, it's kind of ugly to list all built-in names explicitly; this list will be out of sync whenever a new built-in is added. Can't you access the __builtin__ module and use its keys? (One way to get the __builtin__ module is to use PySys_GetObject("modules"), which should give you sys.modules, and take it from there; you can count on __builtin__ to be there, and if it's not, forget the whole thing.) ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-03-28 12:15 Message: Logged In: YES user_id=35752 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711448&group_id=5470 From noreply@sourceforge.net Sun Apr 20 22:57:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 14:57:55 -0700 Subject: [Patches] [ python-Patches-572936 ] (?(id/name)yes|no) re implementation Message-ID: Patches item #572936, was opened at 2002-06-24 03:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: (?(id/name)yes|no) re implementation Initial Comment: This patch implements a regular expression feature, which allows some interesting patterns, in the same way as implemented in perl. For example, (?(1)yes|no) matches with "yes" if group "1" exists, and with "no", if it doesn't. Without this feature, the regular expression must be duplicated to get the same results. In addition to perl's feature, it will also accept a Python named group as argument. Here's an example: (<)?\w+@\w+(\.\w+)+(?(1)>) This is a poor email matching regular expression, which will match with or without the "<>" symbols. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 23:57 Message: Logged In: YES user_id=21627 Exactly: My example makes no sense, it will always be false since the reference is to an alternative that cannot be simultaneously be taken. Therefore, I think this should be an error. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 10:12 Message: Logged In: YES user_id=7887 About the test cases, they're missing indeed. I can write some while applying the patch. About being experimental, IIRC, it is listed like experimental in the Perl documentation for several years, and will probably stay like this forever. :-) Anyway, IMO this shouldn't affect our evaluation of the importance of that feature for Python's sre. About semantic restriction, do you mean check if the backreference is lesser than the current group? Should be doable. OTOH, I don't understand your example. In "(X)|(?(1)Y)", there's no sense in using (?(1), as it will always be false. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 08:23 Message: Logged In: YES user_id=21627 I like the patch in principle, but I have a number of additional concerns: - there are no test cases - the feature is declared experimental in perlre(1). Why? - Shouldn't there be a semantic restriction that the back reference is only allowed if it points to a group that is known to precede? I.e. is (X)|(?(1)Y) valid? If not, the restriction should be atleast documented, but if possible, it should also be implemented. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:30 Message: Logged In: YES user_id=7887 That patch is around for a long time. Should I work on it, fixing that problem, and apply it? Do you agree with the feature inclusion? I remember that the main reason for implementing this is because it is hard to achieve the same results without it. You have to rewrite the whole match twice inside an or'ed group (e.g. "(<... match email ...>|... match email ...)"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 10:50 Message: Logged In: YES user_id=21627 If you add new opcodes, you should also change SRE_MAGIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 From noreply@sourceforge.net Sun Apr 20 22:59:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 14:59:47 -0700 Subject: [Patches] [ python-Patches-723940 ] Backport of recent sre fixes. Message-ID: Patches item #723940, was opened at 2003-04-18 23:15 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Backport of recent sre fixes. Initial Comment: This patch should reproduce, in the release22-maint branch, an exact copy of the sre code currently in the 2.3 branch, with the single exception of the declaration of the module init function. All future patches should apply cleanly to both 2.3 and 2.2 branches. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 21:59 Message: Logged In: YES user_id=7887 No problems. I'll check the patch and workout any issues with Gary. Thanks for pointing me this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-20 20:09 Message: Logged In: YES user_id=6380 Assigning this to Gustavo Niemeyer, who found some problems with this code in 2.3. Gustavo, would you mind working with Gary on backporting this properly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 From noreply@sourceforge.net Sun Apr 20 23:00:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 15:00:12 -0700 Subject: [Patches] [ python-Patches-723940 ] Backport of recent sre fixes. Message-ID: Patches item #723940, was opened at 2003-04-19 01:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Backport of recent sre fixes. Initial Comment: This patch should reproduce, in the release22-maint branch, an exact copy of the sre code currently in the 2.3 branch, with the single exception of the declaration of the module init function. All future patches should apply cleanly to both 2.3 and 2.2 branches. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-21 00:00 Message: Logged In: YES user_id=21627 Why does the patch remove partial history? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 23:59 Message: Logged In: YES user_id=7887 No problems. I'll check the patch and workout any issues with Gary. Thanks for pointing me this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-20 22:09 Message: Logged In: YES user_id=6380 Assigning this to Gustavo Niemeyer, who found some problems with this code in 2.3. Gustavo, would you mind working with Gary on backporting this properly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 From noreply@sourceforge.net Sun Apr 20 23:09:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 15:09:46 -0700 Subject: [Patches] [ python-Patches-572936 ] (?(id/name)yes|no) re implementation Message-ID: Patches item #572936, was opened at 2002-06-24 01:41 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: (?(id/name)yes|no) re implementation Initial Comment: This patch implements a regular expression feature, which allows some interesting patterns, in the same way as implemented in perl. For example, (?(1)yes|no) matches with "yes" if group "1" exists, and with "no", if it doesn't. Without this feature, the regular expression must be duplicated to get the same results. In addition to perl's feature, it will also accept a Python named group as argument. Here's an example: (<)?\w+@\w+(\.\w+)+(?(1)>) This is a poor email matching regular expression, which will match with or without the "<>" symbols. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 22:09 Message: Logged In: YES user_id=7887 I see. I'll try to improve the patch with your suggestions as soon as I get some time to work on it. Thanks for your support. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 21:57 Message: Logged In: YES user_id=21627 Exactly: My example makes no sense, it will always be false since the reference is to an alternative that cannot be simultaneously be taken. Therefore, I think this should be an error. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 08:12 Message: Logged In: YES user_id=7887 About the test cases, they're missing indeed. I can write some while applying the patch. About being experimental, IIRC, it is listed like experimental in the Perl documentation for several years, and will probably stay like this forever. :-) Anyway, IMO this shouldn't affect our evaluation of the importance of that feature for Python's sre. About semantic restriction, do you mean check if the backreference is lesser than the current group? Should be doable. OTOH, I don't understand your example. In "(X)|(?(1)Y)", there's no sense in using (?(1), as it will always be false. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 06:23 Message: Logged In: YES user_id=21627 I like the patch in principle, but I have a number of additional concerns: - there are no test cases - the feature is declared experimental in perlre(1). Why? - Shouldn't there be a semantic restriction that the back reference is only allowed if it points to a group that is known to precede? I.e. is (X)|(?(1)Y) valid? If not, the restriction should be atleast documented, but if possible, it should also be implemented. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 21:30 Message: Logged In: YES user_id=7887 That patch is around for a long time. Should I work on it, fixing that problem, and apply it? Do you agree with the feature inclusion? I remember that the main reason for implementing this is because it is hard to achieve the same results without it. You have to rewrite the whole match twice inside an or'ed group (e.g. "(<... match email ...>|... match email ...)"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 08:50 Message: Logged In: YES user_id=21627 If you add new opcodes, you should also change SRE_MAGIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 00:20:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 16:20:11 -0700 Subject: [Patches] [ python-Patches-723312 ] ability to pass a timeout to underlying socket Message-ID: Patches item #723312, was opened at 2003-04-17 20:03 Message generated for change (Comment added) made by mattruss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 6 Submitted By: Matthew Russell (mattruss) Assigned to: Skip Montanaro (montanaro) Summary: ability to pass a timeout to underlying socket Initial Comment: this patch superceeds an earlier one i posted (#714592) - a bit *too* enthusiastic am afraid (sorry!) classes in modules such as httplib, ftpplib do not currently allow an easy way to take advantage of the new socket timeout feature in 2.3. This patch provides that abilty though one additonal class in socket.py ( socket.NetworkConnection ) and accompying test in test_socket.py (basic though the test is :-s ) As an extra benifit, the patch removes duplicate code, as each connect method in the main class of most modules (FTP, HTTPConnection, Telnet, POP3 etc) are copies of each other. The modules that use sockets are: * ftplib * httplib * telnetlib * poplib * urllib * imaplib * nntplib * xmlrpclib Of these I have only been able to easily refactor NetworkConnection into httplib, ftplib, telnetllib, poplib and smtplib. I did look to see if there were any unittests for theese modules in .Lib/test but found none (? - I appologise if there are some, i am new to the library tests) I did however check that the test() [like] methods at the bottom of each of the afore mentioned modules worked. thanks for your advice again Skip :o) Matt ---------------------------------------------------------------------- >Comment By: Matthew Russell (mattruss) Date: 2003-04-21 00:20 Message: Logged In: YES user_id=737261 Errata: i forgot to mention urlllib2 as modules affected. the line above starting "The modules that use sockets are: " should really read: "classes in the modules stated below would benifit from the ability pass timeouts:" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 From noreply@sourceforge.net Mon Apr 21 02:55:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 18:55:20 -0700 Subject: [Patches] [ python-Patches-723940 ] Backport of recent sre fixes. Message-ID: Patches item #723940, was opened at 2003-04-18 23:15 Message generated for change (Comment added) made by herron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Backport of recent sre fixes. Initial Comment: This patch should reproduce, in the release22-maint branch, an exact copy of the sre code currently in the 2.3 branch, with the single exception of the declaration of the module init function. All future patches should apply cleanly to both 2.3 and 2.2 branches. ---------------------------------------------------------------------- >Comment By: Gary Herron (herron) Date: 2003-04-21 01:55 Message: Logged In: YES user_id=395736 Gustavo, If I understand correctly: * The backport to 2.2 done by just copying the code from 2.3 is not the problem, but merely needs to be repeated in light of changes made, by you and Martin, to 2.3 in that last several days. * The "Greg Chapman's patch" you refer to in the checkin comment of revision of 2.91 of _sre.c is from before I came on-board, and is not the MIN_REPEAT_ONE stuff I got from him and gave to Guido to produce revision 2.88. * That previous patch of Greg's (revision 2.84 of _sre.c) caused some bugs (or at least discrepancies) which you have now resolved in the last day or two. * The MIN_REPEAT_ONE stuff of Greg's is not at issue. * The LASTMARK_SAVE()/LASTMARK_RESTORE() calls were added (quite recently) to fix some bugs, and perhaps are needed in other spots if we were to be clever enough (or unlucky enough) to provoke them. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-20 22:00 Message: Logged In: YES user_id=21627 Why does the patch remove partial history? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 21:59 Message: Logged In: YES user_id=7887 No problems. I'll check the patch and workout any issues with Gary. Thanks for pointing me this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-20 20:09 Message: Logged In: YES user_id=6380 Assigning this to Gustavo Niemeyer, who found some problems with this code in 2.3. Gustavo, would you mind working with Gary on backporting this properly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 From noreply@sourceforge.net Mon Apr 21 07:57:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Apr 2003 23:57:23 -0700 Subject: [Patches] [ python-Patches-723940 ] Backport of recent sre fixes. Message-ID: Patches item #723940, was opened at 2003-04-19 01:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Backport of recent sre fixes. Initial Comment: This patch should reproduce, in the release22-maint branch, an exact copy of the sre code currently in the 2.3 branch, with the single exception of the declaration of the module init function. All future patches should apply cleanly to both 2.3 and 2.2 branches. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-21 08:57 Message: Logged In: YES user_id=21627 I would be careful with copying changes. In particular, they should not be copied if they are not fully understood. sre is a very delicate library: difficult to understand, easy to break, and, if broken, causing harm to many users. Therefore, I think a strict "bug fixes only" policy should be applied when backporting SRE fixes. Unless there is demonstrated breakage that get fixed by applying a patch, no backport of the patch should be made. By this criterion, my changes to use BIGCHARSET in UCS-4 mode should not be backported, as they don't fix a correctness bug (they do improve performance, but at the cost of changing the SRE bytecode interface) ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-04-21 03:55 Message: Logged In: YES user_id=395736 Gustavo, If I understand correctly: * The backport to 2.2 done by just copying the code from 2.3 is not the problem, but merely needs to be repeated in light of changes made, by you and Martin, to 2.3 in that last several days. * The "Greg Chapman's patch" you refer to in the checkin comment of revision of 2.91 of _sre.c is from before I came on-board, and is not the MIN_REPEAT_ONE stuff I got from him and gave to Guido to produce revision 2.88. * That previous patch of Greg's (revision 2.84 of _sre.c) caused some bugs (or at least discrepancies) which you have now resolved in the last day or two. * The MIN_REPEAT_ONE stuff of Greg's is not at issue. * The LASTMARK_SAVE()/LASTMARK_RESTORE() calls were added (quite recently) to fix some bugs, and perhaps are needed in other spots if we were to be clever enough (or unlucky enough) to provoke them. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-21 00:00 Message: Logged In: YES user_id=21627 Why does the patch remove partial history? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 23:59 Message: Logged In: YES user_id=7887 No problems. I'll check the patch and workout any issues with Gary. Thanks for pointing me this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-20 22:09 Message: Logged In: YES user_id=6380 Assigning this to Gustavo Niemeyer, who found some problems with this code in 2.3. Gustavo, would you mind working with Gary on backporting this properly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470 From noreply@sourceforge.net Mon Apr 21 11:33:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 03:33:56 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 12:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 11:34:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 03:34:47 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 12:33 Message generated for change (Settings changed) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Alex Martelli (aleax) >Assigned to: Guido van Rossum (gvanrossum) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 13:21:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 05:21:45 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 06:33 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Alex Martelli (aleax) Assigned to: Guido van Rossum (gvanrossum) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 08:21 Message: Logged In: YES user_id=6380 I have to rethink the idea that sum() should only apply to numbers. The discussion brought up some new good points that I need to ponder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 16:10:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 08:10:57 -0700 Subject: [Patches] [ python-Patches-725024 ] adjust optimisation to deal with bus errors on FreeBSD Message-ID: Patches item #725024, was opened at 2003-04-22 01:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725024&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: adjust optimisation to deal with bus errors on FreeBSD Initial Comment: Since checkin of patch #720991 on April 14, I've not been able to run test_sre (or test_re) on a 2.3-CVS built on FreeBSD 4.7 (gcc 2.95.4, using autoconf default -O3) without getting a bus error. Using less aggressive optimisation works around the issue. I can reproduce the problem with gcc 2.95.3 on FreeBSD 4.4, gcc 3.2.2 on FreeBSD 4.7 built from the FreeBSD ports system, and gcc 3.2.1 for OS/2+EMX. I'm not in a position to do a full investigation of the issue, so I've prepared the attached patch to configure.in which lowers the optimisation for gcc on FreeBSD. For gcc 2.95.x, dropping the optimisation to -O2 is sufficient to get a Python interpreter which doesn't fail test_sre with a bus error. This compiler is the default compiler for FreeBSD 4.x. This change is reduces performance on a VIA C3 800MHz system by about 3-4% (both pystone and pybench) For gcc 3.2.x, the optimisation has to be dropped to -Os for test_sre to pass without a bus error. This compiler is the default compiler for FreeBSD 5.0. On a VIA C3 800MHz system running FreeBSD 4.7, this change reduces performance by 6-7.5% (6% pybench, 7.5% pystone). The EMX port does not use autoconf. Caveats: - I don't yet have a FreeBSD 5.0 system, but have based this patch on the assumption that the 5.0 system compiler will be configured with the same specs as the FreeBSD ports configuration, and therefore have the same behaviour. - a less intrusive workaround would be to only lower optimisation for the affected file (Modules/_sre.c), however that seems impossible with autoconf. - there appear to be no reports of similar issues for gcc on Linux, so I've assumed that the problem is specific to how FreeBSD configures the compilers and/or binutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725024&group_id=5470 From noreply@sourceforge.net Mon Apr 21 16:44:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 08:44:59 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 12:33 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Alex Martelli (aleax) Assigned to: Guido van Rossum (gvanrossum) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-04-21 17:44 Message: Logged In: YES user_id=60314 modified as per GvR's pronouncement on python-dev: now sum([]) returns 0, and it's specifically forbidden for the first item of the argument to be a string (a TypeError is raised and the message tells the user to use ''.join instead). Guido, please do let me know if I should edit the tutorial as well, thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 14:21 Message: Logged In: YES user_id=6380 I have to rethink the idea that sum() should only apply to numbers. The discussion brought up some new good points that I need to ponder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 16:56:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 08:56:46 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 06:33 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Alex Martelli (aleax) >Assigned to: Alex Martelli (aleax) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 11:52 Message: Logged In: YES user_id=6380 I thought we would allow a second argument specifying the starting point, defaulting to 0 (so w is never NULL). See my pseudo code posted to python-dev. (Except if it used +=, ignore that.) Also, I would refrain from mentioning lists or tuples in the docs, since those in fact have the same O(N**2) behavior as strings. better use datetime.timedelta as the example. What would you suggest to modify in the tutorial? Does it even mention reduce()? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 11:44 Message: Logged In: YES user_id=60314 modified as per GvR's pronouncement on python-dev: now sum([]) returns 0, and it's specifically forbidden for the first item of the argument to be a string (a TypeError is raised and the message tells the user to use ''.join instead). Guido, please do let me know if I should edit the tutorial as well, thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 08:21 Message: Logged In: YES user_id=6380 I have to rethink the idea that sum() should only apply to numbers. The discussion brought up some new good points that I need to ponder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 16:52:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 08:52:45 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 06:33 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Alex Martelli (aleax) Assigned to: Guido van Rossum (gvanrossum) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 11:52 Message: Logged In: YES user_id=6380 I thought we would allow a second argument specifying the starting point, defaulting to 0 (so w is never NULL). See my pseudo code posted to python-dev. (Except if it used +=, ignore that.) Also, I would refrain from mentioning lists or tuples in the docs, since those in fact have the same O(N**2) behavior as strings. better use datetime.timedelta as the example. What would you suggest to modify in the tutorial? Does it even mention reduce()? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 11:44 Message: Logged In: YES user_id=60314 modified as per GvR's pronouncement on python-dev: now sum([]) returns 0, and it's specifically forbidden for the first item of the argument to be a string (a TypeError is raised and the message tells the user to use ''.join instead). Guido, please do let me know if I should edit the tutorial as well, thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 08:21 Message: Logged In: YES user_id=6380 I have to rethink the idea that sum() should only apply to numbers. The discussion brought up some new good points that I need to ponder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 17:31:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 09:31:39 -0700 Subject: [Patches] [ python-Patches-711902 ] Cause pydoc to show data descriptor __doc__ strings Message-ID: Patches item #711902, was opened at 2003-03-29 10:01 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711902&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Martin v. Löwis (loewis) Summary: Cause pydoc to show data descriptor __doc__ strings Initial Comment: Data descriptors (descriptors having both a __get__ and a __set__ method) often have __doc__ strings. Pydoc displays these for descriptors of type property, but not for other types (e.g., getsets). The attached patch will display __doc__ strings for data descriptors (if available) in the "Data and non-method functions" section of the type description. This patch is intended to be a minimal change. It's possible that inspect.classify_class_attrs should return a new kind for data descriptors (or possibly the "property" kind should include all data descriptors (not just properties)), which could then be handled differently from other non-classified data. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2003-04-21 08:31 Message: Logged In: YES user_id=86307 Attaching new patch with docs and a couple of tests. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 12:32 Message: Logged In: YES user_id=21627 The patch looks fine. Can you please also provide a patch for the documentation (libinspect.tex), and the test suite (test_inspect.py)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711902&group_id=5470 From noreply@sourceforge.net Mon Apr 21 17:34:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 09:34:20 -0700 Subject: [Patches] [ python-Patches-711902 ] Cause pydoc to show data descriptor __doc__ strings Message-ID: Patches item #711902, was opened at 2003-03-29 10:01 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711902&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Martin v. Löwis (loewis) Summary: Cause pydoc to show data descriptor __doc__ strings Initial Comment: Data descriptors (descriptors having both a __get__ and a __set__ method) often have __doc__ strings. Pydoc displays these for descriptors of type property, but not for other types (e.g., getsets). The attached patch will display __doc__ strings for data descriptors (if available) in the "Data and non-method functions" section of the type description. This patch is intended to be a minimal change. It's possible that inspect.classify_class_attrs should return a new kind for data descriptors (or possibly the "property" kind should include all data descriptors (not just properties)), which could then be handled differently from other non-classified data. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2003-04-21 08:34 Message: Logged In: YES user_id=86307 Apparently, Sourceforge won't let me delete the old patch file (I get a permission denied error), so, to avoid confusion, here is the new patch in a file named pydoc_patch2.txt. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-04-21 08:31 Message: Logged In: YES user_id=86307 Attaching new patch with docs and a couple of tests. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 12:32 Message: Logged In: YES user_id=21627 The patch looks fine. Can you please also provide a patch for the documentation (libinspect.tex), and the test suite (test_inspect.py)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711902&group_id=5470 From noreply@sourceforge.net Mon Apr 21 18:27:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 10:27:00 -0700 Subject: [Patches] [ python-Patches-716969 ] fix thread bug in 2.2.2 and later Message-ID: Patches item #716969, was opened at 2003-04-07 16:04 Message generated for change (Comment added) made by gregklanderman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Greg Klanderman (gregklanderman) Assigned to: Martin v. Löwis (loewis) Summary: fix thread bug in 2.2.2 and later Initial Comment: in at least 2.2.2 and later (and probably earlier), the pthread implementation of thread.create_new_thread() is no longer handling the inability to create a new thread properly - it returns as though a new thread was created but in fact no thread was started. the bug seems to have been introduced here: Python/thread_pthread.h: > revision 2.35 > date: 2001/10/16 21:13:49; author: gvanrossum; ... > Partial patch from SF #452266, by Jason Petrone. > > This changes Pythread_start_thread() to return the thread ID, or -1 > for an error. (It's technically an incompatible API change, but I > doubt anyone calls it.) it apepars that the same bug may exist in the nt and solaris thread implementations though i was not able to test this hypothesis. here's a test script to run import thread, time, traceback def foo(i): time.sleep(10) print "thread %3d finished" % (i,) for i in range(3000): try: v = thread.start_new_thread(foo, (i,)) print "started thread %d --> %s" % (i, v) except thread.error, e: print "thread limit reached: %d" % (i,) traceback.print_exc() break time.sleep(30) you'll notice that on 1.5.2, after around 256 threads are created, an error is raised, and that all the threads prior to this then complete a few seconds later. in 2.2.2, an error is never raised, but only about 1000 threads have actually been successfully created. patch is attached. i've taken the liberty of renaming one of the variables for clarity. greg gak@klanderman.net ---------------------------------------------------------------------- >Comment By: Greg Klanderman (gregklanderman) Date: 2003-04-21 13:27 Message: Logged In: YES user_id=698972 sweet, thanks! thread_nt.h still looks like it has this same problem. i don't know solaris threads but should the FUNCARG struct be freed upon successful thread creation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 03:47 Message: Logged In: YES user_id=21627 Thanks for the patch. I believe you are right about Solaris threads, and have applied the "obvious" fix; committed everything as thread_pthread.h 2.46 thread_solaris.h 2.19 thread_pthread.h 2.36.8.4 thread_solaris.h 2.16.10.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 From noreply@sourceforge.net Mon Apr 21 19:13:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 11:13:23 -0700 Subject: [Patches] [ python-Patches-716969 ] fix thread bug in 2.2.2 and later Message-ID: Patches item #716969, was opened at 2003-04-07 22:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Greg Klanderman (gregklanderman) Assigned to: Martin v. Löwis (loewis) Summary: fix thread bug in 2.2.2 and later Initial Comment: in at least 2.2.2 and later (and probably earlier), the pthread implementation of thread.create_new_thread() is no longer handling the inability to create a new thread properly - it returns as though a new thread was created but in fact no thread was started. the bug seems to have been introduced here: Python/thread_pthread.h: > revision 2.35 > date: 2001/10/16 21:13:49; author: gvanrossum; ... > Partial patch from SF #452266, by Jason Petrone. > > This changes Pythread_start_thread() to return the thread ID, or -1 > for an error. (It's technically an incompatible API change, but I > doubt anyone calls it.) it apepars that the same bug may exist in the nt and solaris thread implementations though i was not able to test this hypothesis. here's a test script to run import thread, time, traceback def foo(i): time.sleep(10) print "thread %3d finished" % (i,) for i in range(3000): try: v = thread.start_new_thread(foo, (i,)) print "started thread %d --> %s" % (i, v) except thread.error, e: print "thread limit reached: %d" % (i,) traceback.print_exc() break time.sleep(30) you'll notice that on 1.5.2, after around 256 threads are created, an error is raised, and that all the threads prior to this then complete a few seconds later. in 2.2.2, an error is never raised, but only about 1000 threads have actually been successfully created. patch is attached. i've taken the liberty of renaming one of the variables for clarity. greg gak@klanderman.net ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-21 20:13 Message: Logged In: YES user_id=21627 Can you produce and test a Win32 patch? (Producing is probably easy; testing is what matters here) The funcarg for Solaris is freed inside new_func. ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-04-21 19:27 Message: Logged In: YES user_id=698972 sweet, thanks! thread_nt.h still looks like it has this same problem. i don't know solaris threads but should the FUNCARG struct be freed upon successful thread creation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 09:47 Message: Logged In: YES user_id=21627 Thanks for the patch. I believe you are right about Solaris threads, and have applied the "obvious" fix; committed everything as thread_pthread.h 2.46 thread_solaris.h 2.19 thread_pthread.h 2.36.8.4 thread_solaris.h 2.16.10.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 From noreply@sourceforge.net Mon Apr 21 19:13:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 11:13:58 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 12:33 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Alex Martelli (aleax) >Assigned to: Guido van Rossum (gvanrossum) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-04-21 20:13 Message: Logged In: YES user_id=60314 OK, changed again as requested. I have forbidden all sequences (not just strings) as the value of start, since, as you mention, performance problems would arise anyway. Yes, the tutorial does cover reduce (specific example is reduce(add,...)) together with the other builtin higher-order functions. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 17:52 Message: Logged In: YES user_id=6380 I thought we would allow a second argument specifying the starting point, defaulting to 0 (so w is never NULL). See my pseudo code posted to python-dev. (Except if it used +=, ignore that.) Also, I would refrain from mentioning lists or tuples in the docs, since those in fact have the same O(N**2) behavior as strings. better use datetime.timedelta as the example. What would you suggest to modify in the tutorial? Does it even mention reduce()? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 17:44 Message: Logged In: YES user_id=60314 modified as per GvR's pronouncement on python-dev: now sum([]) returns 0, and it's specifically forbidden for the first item of the argument to be a string (a TypeError is raised and the message tells the user to use ''.join instead). Guido, please do let me know if I should edit the tutorial as well, thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 14:21 Message: Logged In: YES user_id=6380 I have to rethink the idea that sum() should only apply to numbers. The discussion brought up some new good points that I need to ponder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 19:27:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 11:27:03 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 06:33 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Alex Martelli (aleax) >Assigned to: Alex Martelli (aleax) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 14:27 Message: Logged In: YES user_id=6380 Hm... What if someone defines a Vector class which defines __add__ as elementwise addition, but also supports sequence behavior to access the vector items? You couldn't use a Vector as the start value, so you couldn't sum Vectors. I would either specifically disallow list and tuple, or not bother beyond disallowing strings (which probably captures 95% of the mistates anyway). Also, "result = PyInt_FromLong(0);" is missing error checking (though it is unlikely to fail). Since the concept of higher order functions is useful in the tutorial, perhaps all you need to add is a statement at the end of the section on reduce() saying something like "don't use this example; because summing numbers is so common, a built-in function sum() that works like this is provided". With a \versionadded{2.3} marker. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 14:13 Message: Logged In: YES user_id=60314 OK, changed again as requested. I have forbidden all sequences (not just strings) as the value of start, since, as you mention, performance problems would arise anyway. Yes, the tutorial does cover reduce (specific example is reduce(add,...)) together with the other builtin higher-order functions. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 11:52 Message: Logged In: YES user_id=6380 I thought we would allow a second argument specifying the starting point, defaulting to 0 (so w is never NULL). See my pseudo code posted to python-dev. (Except if it used +=, ignore that.) Also, I would refrain from mentioning lists or tuples in the docs, since those in fact have the same O(N**2) behavior as strings. better use datetime.timedelta as the example. What would you suggest to modify in the tutorial? Does it even mention reduce()? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 11:44 Message: Logged In: YES user_id=60314 modified as per GvR's pronouncement on python-dev: now sum([]) returns 0, and it's specifically forbidden for the first item of the argument to be a string (a TypeError is raised and the message tells the user to use ''.join instead). Guido, please do let me know if I should edit the tutorial as well, thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 08:21 Message: Logged In: YES user_id=6380 I have to rethink the idea that sum() should only apply to numbers. The discussion brought up some new good points that I need to ponder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 20:12:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 12:12:15 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 12:33 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Alex Martelli (aleax) >Assigned to: Guido van Rossum (gvanrossum) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-04-21 21:12 Message: Logged In: YES user_id=60314 ok, now it only forbids strings, and allows other sequences. Also added a short paragraph to the tutorial as you indicated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 20:27 Message: Logged In: YES user_id=6380 Hm... What if someone defines a Vector class which defines __add__ as elementwise addition, but also supports sequence behavior to access the vector items? You couldn't use a Vector as the start value, so you couldn't sum Vectors. I would either specifically disallow list and tuple, or not bother beyond disallowing strings (which probably captures 95% of the mistates anyway). Also, "result = PyInt_FromLong(0);" is missing error checking (though it is unlikely to fail). Since the concept of higher order functions is useful in the tutorial, perhaps all you need to add is a statement at the end of the section on reduce() saying something like "don't use this example; because summing numbers is so common, a built-in function sum() that works like this is provided". With a \versionadded{2.3} marker. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 20:13 Message: Logged In: YES user_id=60314 OK, changed again as requested. I have forbidden all sequences (not just strings) as the value of start, since, as you mention, performance problems would arise anyway. Yes, the tutorial does cover reduce (specific example is reduce(add,...)) together with the other builtin higher-order functions. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 17:52 Message: Logged In: YES user_id=6380 I thought we would allow a second argument specifying the starting point, defaulting to 0 (so w is never NULL). See my pseudo code posted to python-dev. (Except if it used +=, ignore that.) Also, I would refrain from mentioning lists or tuples in the docs, since those in fact have the same O(N**2) behavior as strings. better use datetime.timedelta as the example. What would you suggest to modify in the tutorial? Does it even mention reduce()? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 17:44 Message: Logged In: YES user_id=60314 modified as per GvR's pronouncement on python-dev: now sum([]) returns 0, and it's specifically forbidden for the first item of the argument to be a string (a TypeError is raised and the message tells the user to use ''.join instead). Guido, please do let me know if I should edit the tutorial as well, thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 14:21 Message: Logged In: YES user_id=6380 I have to rethink the idea that sum() should only apply to numbers. The discussion brought up some new good points that I need to ponder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 20:17:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 12:17:03 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 12:33 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Alex Martelli (aleax) Assigned to: Guido van Rossum (gvanrossum) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-04-21 21:17 Message: Logged In: YES user_id=60314 oops, had forgotten to handle the case of PyInt_FromLong(0) failing -- fixed that. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 21:12 Message: Logged In: YES user_id=60314 ok, now it only forbids strings, and allows other sequences. Also added a short paragraph to the tutorial as you indicated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 20:27 Message: Logged In: YES user_id=6380 Hm... What if someone defines a Vector class which defines __add__ as elementwise addition, but also supports sequence behavior to access the vector items? You couldn't use a Vector as the start value, so you couldn't sum Vectors. I would either specifically disallow list and tuple, or not bother beyond disallowing strings (which probably captures 95% of the mistates anyway). Also, "result = PyInt_FromLong(0);" is missing error checking (though it is unlikely to fail). Since the concept of higher order functions is useful in the tutorial, perhaps all you need to add is a statement at the end of the section on reduce() saying something like "don't use this example; because summing numbers is so common, a built-in function sum() that works like this is provided". With a \versionadded{2.3} marker. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 20:13 Message: Logged In: YES user_id=60314 OK, changed again as requested. I have forbidden all sequences (not just strings) as the value of start, since, as you mention, performance problems would arise anyway. Yes, the tutorial does cover reduce (specific example is reduce(add,...)) together with the other builtin higher-order functions. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 17:52 Message: Logged In: YES user_id=6380 I thought we would allow a second argument specifying the starting point, defaulting to 0 (so w is never NULL). See my pseudo code posted to python-dev. (Except if it used +=, ignore that.) Also, I would refrain from mentioning lists or tuples in the docs, since those in fact have the same O(N**2) behavior as strings. better use datetime.timedelta as the example. What would you suggest to modify in the tutorial? Does it even mention reduce()? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 17:44 Message: Logged In: YES user_id=60314 modified as per GvR's pronouncement on python-dev: now sum([]) returns 0, and it's specifically forbidden for the first item of the argument to be a string (a TypeError is raised and the message tells the user to use ''.join instead). Guido, please do let me know if I should edit the tutorial as well, thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 14:21 Message: Logged In: YES user_id=6380 I have to rethink the idea that sum() should only apply to numbers. The discussion brought up some new good points that I need to ponder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 20:19:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 12:19:27 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 06:33 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Alex Martelli (aleax) >Assigned to: Alex Martelli (aleax) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 15:19 Message: Logged In: YES user_id=6380 OK, looks good. You can check it in yourself -- I've given you commit priviliges! ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 15:17 Message: Logged In: YES user_id=60314 oops, had forgotten to handle the case of PyInt_FromLong(0) failing -- fixed that. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 15:12 Message: Logged In: YES user_id=60314 ok, now it only forbids strings, and allows other sequences. Also added a short paragraph to the tutorial as you indicated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 14:27 Message: Logged In: YES user_id=6380 Hm... What if someone defines a Vector class which defines __add__ as elementwise addition, but also supports sequence behavior to access the vector items? You couldn't use a Vector as the start value, so you couldn't sum Vectors. I would either specifically disallow list and tuple, or not bother beyond disallowing strings (which probably captures 95% of the mistates anyway). Also, "result = PyInt_FromLong(0);" is missing error checking (though it is unlikely to fail). Since the concept of higher order functions is useful in the tutorial, perhaps all you need to add is a statement at the end of the section on reduce() saying something like "don't use this example; because summing numbers is so common, a built-in function sum() that works like this is provided". With a \versionadded{2.3} marker. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 14:13 Message: Logged In: YES user_id=60314 OK, changed again as requested. I have forbidden all sequences (not just strings) as the value of start, since, as you mention, performance problems would arise anyway. Yes, the tutorial does cover reduce (specific example is reduce(add,...)) together with the other builtin higher-order functions. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 11:52 Message: Logged In: YES user_id=6380 I thought we would allow a second argument specifying the starting point, defaulting to 0 (so w is never NULL). See my pseudo code posted to python-dev. (Except if it used +=, ignore that.) Also, I would refrain from mentioning lists or tuples in the docs, since those in fact have the same O(N**2) behavior as strings. better use datetime.timedelta as the example. What would you suggest to modify in the tutorial? Does it even mention reduce()? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 11:44 Message: Logged In: YES user_id=60314 modified as per GvR's pronouncement on python-dev: now sum([]) returns 0, and it's specifically forbidden for the first item of the argument to be a string (a TypeError is raised and the message tells the user to use ''.join instead). Guido, please do let me know if I should edit the tutorial as well, thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 08:21 Message: Logged In: YES user_id=6380 I have to rethink the idea that sum() should only apply to numbers. The discussion brought up some new good points that I need to ponder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Mon Apr 21 20:53:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 12:53:08 -0700 Subject: [Patches] [ python-Patches-716969 ] fix thread bug in 2.2.2 and later Message-ID: Patches item #716969, was opened at 2003-04-07 16:04 Message generated for change (Comment added) made by gregklanderman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Greg Klanderman (gregklanderman) Assigned to: Martin v. Löwis (loewis) Summary: fix thread bug in 2.2.2 and later Initial Comment: in at least 2.2.2 and later (and probably earlier), the pthread implementation of thread.create_new_thread() is no longer handling the inability to create a new thread properly - it returns as though a new thread was created but in fact no thread was started. the bug seems to have been introduced here: Python/thread_pthread.h: > revision 2.35 > date: 2001/10/16 21:13:49; author: gvanrossum; ... > Partial patch from SF #452266, by Jason Petrone. > > This changes Pythread_start_thread() to return the thread ID, or -1 > for an error. (It's technically an incompatible API change, but I > doubt anyone calls it.) it apepars that the same bug may exist in the nt and solaris thread implementations though i was not able to test this hypothesis. here's a test script to run import thread, time, traceback def foo(i): time.sleep(10) print "thread %3d finished" % (i,) for i in range(3000): try: v = thread.start_new_thread(foo, (i,)) print "started thread %d --> %s" % (i, v) except thread.error, e: print "thread limit reached: %d" % (i,) traceback.print_exc() break time.sleep(30) you'll notice that on 1.5.2, after around 256 threads are created, an error is raised, and that all the threads prior to this then complete a few seconds later. in 2.2.2, an error is never raised, but only about 1000 threads have actually been successfully created. patch is attached. i've taken the liberty of renaming one of the variables for clarity. greg gak@klanderman.net ---------------------------------------------------------------------- >Comment By: Greg Klanderman (gregklanderman) Date: 2003-04-21 15:53 Message: Logged In: YES user_id=698972 (un)fortunately i don't have a windows box available.. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-21 14:13 Message: Logged In: YES user_id=21627 Can you produce and test a Win32 patch? (Producing is probably easy; testing is what matters here) The funcarg for Solaris is freed inside new_func. ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-04-21 13:27 Message: Logged In: YES user_id=698972 sweet, thanks! thread_nt.h still looks like it has this same problem. i don't know solaris threads but should the FUNCARG struct be freed upon successful thread creation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-19 03:47 Message: Logged In: YES user_id=21627 Thanks for the patch. I believe you are right about Solaris threads, and have applied the "obvious" fix; committed everything as thread_pthread.h 2.46 thread_solaris.h 2.19 thread_pthread.h 2.36.8.4 thread_solaris.h 2.16.10.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=716969&group_id=5470 From noreply@sourceforge.net Mon Apr 21 23:48:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Apr 2003 15:48:29 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-26 00:16 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2003-04-22 00:48 Message: Logged In: YES user_id=34209 Pystone is not likely to show much speedup, as it contains exactly 2 instances of CALL_ATTR, only barely in the main loop. However, it should not slow down because of CALL_ATTR either; the two CALL_ATTRs are of the most optimized sort, old-style instance methods, and none of the other code paths have changed *at all* (in the fast-and-ugly mode of the patch, which is the default.) There are only two reasons I can think of that explain a slower pystone: code cache and the switch statement layout. This apparently does not influence my (somewhat high-end-ish) test machines, but does yours (and others.) Both are more or less outside my control. They might be fixed by switch reordering or rearranging of the code so the compiler optimizes it better, but that's very platform specific and lacking a proper test-bed for that situation, I can't do it. Alternatively, there may be some funk with regards to bytecode version. If bytecode wasn't properly regenerated, I can imagine not seeing *any* speedup. Have you tried something as simple as ./python timeit.py -s 'class X:' -s ' def spam(self): pass' -s 'x = X()' 'x.spam()' ? This gives a good 30% speedup on my home PC. Bytecode problems wouldn't influence pystone though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 20:42 Message: Logged In: YES user_id=6380 Alas, like others, I see a tiny slowdown on pystone (maybe 3 percent). This is with the default version of patch version 4 (fixed). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:48 Message: Logged In: YES user_id=34209 Oops, that patch contained a C++-ism, ceval.c:3504 and 3505 needed to be swapped. Uploaded a new version. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all .() occurances. What and are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where resulted in an (old-style) instance, and one where resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 02:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 02:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 01:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-26 00:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Tue Apr 22 10:27:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 02:27:47 -0700 Subject: [Patches] [ python-Patches-724936 ] new sum builtin Message-ID: Patches item #724936, was opened at 2003-04-21 12:33 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Alex Martelli (aleax) Assigned to: Alex Martelli (aleax) Summary: new sum builtin Initial Comment: as per discussion on Python-Dev. Note that sum(manystrings), while still FAR faster than reduce(operator.add, manystrings) and the equivalent loop, is now about twice as slow as ''.join(manystrings) -- to support the possibility that "manystrings" may be an iterator, sum must retain the first item and string-concatenate to it the ''.join of the others. I have not mentioned this slight performance hit in the docs (just as the far more severe performance trap with reduce(operator.add, manystrings) is nowhere mentioned). Also, I have not edited the tutorial. Please let me know if you want more editing of such docs, I'll be quite glad to do it, of course! ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-04-22 11:27 Message: Logged In: YES user_id=60314 checked it in (including further fixes suggested by rhettinger -- tx!). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 21:19 Message: Logged In: YES user_id=6380 OK, looks good. You can check it in yourself -- I've given you commit priviliges! ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 21:17 Message: Logged In: YES user_id=60314 oops, had forgotten to handle the case of PyInt_FromLong(0) failing -- fixed that. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 21:12 Message: Logged In: YES user_id=60314 ok, now it only forbids strings, and allows other sequences. Also added a short paragraph to the tutorial as you indicated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 20:27 Message: Logged In: YES user_id=6380 Hm... What if someone defines a Vector class which defines __add__ as elementwise addition, but also supports sequence behavior to access the vector items? You couldn't use a Vector as the start value, so you couldn't sum Vectors. I would either specifically disallow list and tuple, or not bother beyond disallowing strings (which probably captures 95% of the mistates anyway). Also, "result = PyInt_FromLong(0);" is missing error checking (though it is unlikely to fail). Since the concept of higher order functions is useful in the tutorial, perhaps all you need to add is a statement at the end of the section on reduce() saying something like "don't use this example; because summing numbers is so common, a built-in function sum() that works like this is provided". With a \versionadded{2.3} marker. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 20:13 Message: Logged In: YES user_id=60314 OK, changed again as requested. I have forbidden all sequences (not just strings) as the value of start, since, as you mention, performance problems would arise anyway. Yes, the tutorial does cover reduce (specific example is reduce(add,...)) together with the other builtin higher-order functions. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 17:52 Message: Logged In: YES user_id=6380 I thought we would allow a second argument specifying the starting point, defaulting to 0 (so w is never NULL). See my pseudo code posted to python-dev. (Except if it used +=, ignore that.) Also, I would refrain from mentioning lists or tuples in the docs, since those in fact have the same O(N**2) behavior as strings. better use datetime.timedelta as the example. What would you suggest to modify in the tutorial? Does it even mention reduce()? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-04-21 17:44 Message: Logged In: YES user_id=60314 modified as per GvR's pronouncement on python-dev: now sum([]) returns 0, and it's specifically forbidden for the first item of the argument to be a string (a TypeError is raised and the message tells the user to use ''.join instead). Guido, please do let me know if I should edit the tutorial as well, thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-21 14:21 Message: Logged In: YES user_id=6380 I have to rethink the idea that sum() should only apply to numbers. The discussion brought up some new good points that I need to ponder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=724936&group_id=5470 From noreply@sourceforge.net Tue Apr 22 11:33:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 03:33:41 -0700 Subject: [Patches] [ python-Patches-725569 ] Improved output for unittest failUnlessEqual Message-ID: Patches item #725569, was opened at 2003-04-22 10:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Duncan Booth (duncanb) Assigned to: Nobody/Anonymous (nobody) Summary: Improved output for unittest failUnlessEqual Initial Comment: The failUnlessEqual method in unittest.TestCase doesn't handle well the case where the objects being compared have a long string representation. The whole repr for each object is printed no matter how long, and no indication is given of where any differences occur. This patch uses difflib on long representations to provide a short output that highlights where the first difference actually is. It also limits the output for each value to fit on a single line (with the differences indicated on the line following). e.g. FAIL: test_failunlessEqual4 (__main__.Test) ---------------------------------------------------------------------- TestFailed: failUnlessEqual {'A': 65, 'C': 67, ...0, 'P ': 0, 'R': 82, 'U': 85, 'T': 84, 'W': 87, 'V': 8... ... ^^ ^ ... {'A': 65, 'C': 67, ...0, 'S': 83, 'R': 82, 'U': 85, 'T': 84, 'W': 87, 'V': 8... ... ^ ^^ ... File "F:\temp\test.py", line 59, in test_failunlessEqual4 self.failUnlessEqual(d2, d1) ---------------------------------------------------------------------- The attached file contains the changes, assuming that patch "722638 Better output for unittest" has already been applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470 From noreply@sourceforge.net Tue Apr 22 13:20:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 05:20:23 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-25 18:16 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 08:20 Message: Logged In: YES user_id=6380 OK, I did a more realistic benchmark: startup time of Zope3. With more or less current CVS Python 2.3 (but not Raymond H's bytecode optimizations), it took 3.52 seconds. With your patch (and all .pyc files rebuilt) it took 3.47 seconds. That's about a percent and a half. (With Python 2.2 it took 4.08 seconds.) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-21 18:48 Message: Logged In: YES user_id=34209 Pystone is not likely to show much speedup, as it contains exactly 2 instances of CALL_ATTR, only barely in the main loop. However, it should not slow down because of CALL_ATTR either; the two CALL_ATTRs are of the most optimized sort, old-style instance methods, and none of the other code paths have changed *at all* (in the fast-and-ugly mode of the patch, which is the default.) There are only two reasons I can think of that explain a slower pystone: code cache and the switch statement layout. This apparently does not influence my (somewhat high-end-ish) test machines, but does yours (and others.) Both are more or less outside my control. They might be fixed by switch reordering or rearranging of the code so the compiler optimizes it better, but that's very platform specific and lacking a proper test-bed for that situation, I can't do it. Alternatively, there may be some funk with regards to bytecode version. If bytecode wasn't properly regenerated, I can imagine not seeing *any* speedup. Have you tried something as simple as ./python timeit.py -s 'class X:' -s ' def spam(self): pass' -s 'x = X()' 'x.spam()' ? This gives a good 30% speedup on my home PC. Bytecode problems wouldn't influence pystone though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 14:42 Message: Logged In: YES user_id=6380 Alas, like others, I see a tiny slowdown on pystone (maybe 3 percent). This is with the default version of patch version 4 (fixed). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 18:48 Message: Logged In: YES user_id=34209 Oops, that patch contained a C++-ism, ceval.c:3504 and 3505 needed to be swapped. Uploaded a new version. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 18:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all .() occurances. What and are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where resulted in an (old-style) instance, and one where resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-17 20:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-17 20:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-17 19:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-25 18:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Tue Apr 22 13:38:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 05:38:31 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-25 18:16 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 08:38 Message: Logged In: YES user_id=6380 However, you should be proud of yourself nevertheless. On the same Zope3 startup "benchmark", Raymond Hettinger's bytecode optimizations scored 0% improvement. Python -O didn't make any difference either. So it's a touch benchmark! (And yes, I did remove the .pyc/.pyo files each time.) (And no, I can't test -OO because Zope uses the docstrings.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 08:20 Message: Logged In: YES user_id=6380 OK, I did a more realistic benchmark: startup time of Zope3. With more or less current CVS Python 2.3 (but not Raymond H's bytecode optimizations), it took 3.52 seconds. With your patch (and all .pyc files rebuilt) it took 3.47 seconds. That's about a percent and a half. (With Python 2.2 it took 4.08 seconds.) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-21 18:48 Message: Logged In: YES user_id=34209 Pystone is not likely to show much speedup, as it contains exactly 2 instances of CALL_ATTR, only barely in the main loop. However, it should not slow down because of CALL_ATTR either; the two CALL_ATTRs are of the most optimized sort, old-style instance methods, and none of the other code paths have changed *at all* (in the fast-and-ugly mode of the patch, which is the default.) There are only two reasons I can think of that explain a slower pystone: code cache and the switch statement layout. This apparently does not influence my (somewhat high-end-ish) test machines, but does yours (and others.) Both are more or less outside my control. They might be fixed by switch reordering or rearranging of the code so the compiler optimizes it better, but that's very platform specific and lacking a proper test-bed for that situation, I can't do it. Alternatively, there may be some funk with regards to bytecode version. If bytecode wasn't properly regenerated, I can imagine not seeing *any* speedup. Have you tried something as simple as ./python timeit.py -s 'class X:' -s ' def spam(self): pass' -s 'x = X()' 'x.spam()' ? This gives a good 30% speedup on my home PC. Bytecode problems wouldn't influence pystone though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 14:42 Message: Logged In: YES user_id=6380 Alas, like others, I see a tiny slowdown on pystone (maybe 3 percent). This is with the default version of patch version 4 (fixed). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 18:48 Message: Logged In: YES user_id=34209 Oops, that patch contained a C++-ism, ceval.c:3504 and 3505 needed to be swapped. Uploaded a new version. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 18:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all .() occurances. What and are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where resulted in an (old-style) instance, and one where resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-17 20:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-17 20:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-17 19:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-25 18:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Tue Apr 22 15:08:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 07:08:54 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-13 05:15 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Jack Jansen (jackjansen) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-04-22 16:08 Message: Logged In: YES user_id=45365 The problem seems to be gone. I'm running with the default stack size limit (512KB) and the test runs fine. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-12 03:45 Message: Logged In: YES user_id=12800 Yes, I think this problem still exists, but we haven't decided what to do about it. I'm assigning it to Jack for final disposition. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:24 Message: Logged In: YES user_id=33168 Anybody, is this patch still necessary? Have the problems been fixed? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-11 12:52 Message: Logged In: YES user_id=6656 > (Aside: why does this build `python' for 10.1 but > `python.exe' for 10.2?) Because the sf machine has a case sensitive filesystem? I don't see any failures on 10.1.5 (after I ran ulimit, duh). Haven't tried this patch yet... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-11 08:42 Message: Logged In: YES user_id=12800 Ok, I've added the Wouters Elaboration to regrtest.py and verified it works on both 10.1 and 10.2 (the former being the OSX machine on the SF compile farm and the latter being my home machine). Attached is the patch (I hope :). (Aside: why does this build `python' for 10.1 but `python.exe' for 10.2?) I think this patch is fine for Py2.2.2. Today Guido said he'd feel more comfortable with a patch to main.c than a patch to regrtest.py, s?re.py, or site.py (if I understood him correctly). However, I don't think there's time for that for Py2.2.2. Perhaps we should simply commit this simple fix so the test suite passes, and then work out a more comprehensive patch for Py2.3? Note that In addition, here is the output of the regrtest on 10.1 and 10.2. Is it worth spending time trying to fix these for the Py2.2.2 release? 10.1: 170 tests OK. 2 tests failed: test_fcntl test_largefile 21 tests skipped: test_al test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_minidom test_poll test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 3 skips unexpected on darwin: test_sax test_pyexpat test_locale make: *** [test] Error 1 10.2: 171 tests OK. 1 test failed: test_locale 21 tests skipped: test_al test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_minidom test_nis test_poll test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 2 skips unexpected on darwin: test_sax test_pyexpat ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-11 00:38 Message: Logged In: YES user_id=34209 Oh, and the diff is kind of amusing. It seems to be MacBinary, but 'file' on my Debian machine isn't quite sure: /home/thomas/regrtest.diff: MacBinary III data with surprising version number Fortunately it's still readable :-) I guess I should go back to "cool with a Macintosh" too. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-11 00:28 Message: Logged In: YES user_id=34209 I'd suggest adding a min(max, ) to the patch, so that it becomes: soft, hard = resource.getrlimit(resource.RLIMIT_STACK) newsoft = min(hard, max(soft, 1024*2048)) resource.setrlimit(resource.RLIMIT_STACK, newsoft, hard) And if the test suite only triggers this problem, doesn't it make more sense in s?re.py, as Fredrik suggested ? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-10 21:05 Message: Logged In: YES user_id=12800 I can verify the patch works on 10.1, specifically the OSX Server in the SF compile farm. ---------------------------------------------------------------------- Comment By: Steven D. Majewski (sdm7g) Date: 2002-10-10 19:11 Message: Logged In: YES user_id=105602 NOT running as root -- I just tried it again and verified that it works for me. HOWEVER: I haven't yet upgraded to Jaguar/10.2 Maybe that's the difference ? I can post a request on the pythonmac list and ask some others to try it and find out if it's a 10.1.x vs 10.2 thing. -- Steve ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:04 Message: Logged In: YES user_id=44345 Sorry for the bogus updates. Opera 6.0 Beta 1 apparently has file upload problems. Resorting to IE... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 17:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Tue Apr 22 15:20:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 07:20:05 -0700 Subject: [Patches] [ python-Patches-618791 ] [mingw patches] alloca and posixmodule Message-ID: Patches item #618791, was opened at 2002-10-05 01:43 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618791&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 2 Submitted By: Gerhard Häring (ghaering) Assigned to: Gerhard Häring (ghaering) Summary: [mingw patches] alloca and posixmodule Initial Comment: This is the first patch in a series of patching of porting Python to native win32, while still using the autoconf-based build process. The compiler used is mingw, the build environment used is msys, a stripped down Cygwin from the mingw project. This patch does several things: * change _alloca to alloca for both mingw and Visual C++, to avoid unnecessary #ifdef-ing. * Change the makesetup shell script to work for win32, where for some weird reason we have a module 'nt' built from a posixmodule.c file. * Change on occurence of #ifdef MS_WINDOWS in posixmodule.c where it should really have been #ifdef Py_WIN_WIDE_FILENAMES * Change the #ifdefs in posixmodule.c so that it can be built with both MSVC and mingw The result of this patch is that we can build a statically built python.exe with a simple ./configure make under mingw/msys. There's, however, still of additional work to do until we can build a native win32 Python with the autoconf-based build process. Please apply this ASAP, as I want to avoid having a diverging Python tree on my harddisk (this makes patch creation a lot more difficult). ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2003-04-22 16:20 Message: Logged In: YES user_id=163326 This patch is too incomplete to be useful. I'm working on posixmodule.c again right now and will try to come up with something more complete. I'll have to ask on python-dev on how to proceed, anyway. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:31 Message: Logged In: YES user_id=33168 Gerhard, is there any reason to leave this patch open? ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-05 11:35 Message: Logged In: YES user_id=163326 Cool :-) I'm assigning this patch to myself now. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 04:39 Message: Logged In: YES user_id=31435 Welcome, Gerhard! You have commit privileges now. If you need any help with SourceForge mechanics, ask on Python-Dev and you'll get more advice than you can stand . ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-05 01:57 Message: Logged In: YES user_id=163326 Sounds great. I'd have needed advice from python-dev anyway, especially on the parts where autoconf is concerned (I'm relatively green there). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-04 21:04 Message: Logged In: YES user_id=6380 What I'd like to see most is for somebody with CVS commit permission for Python *and* an understanding of mingw to start making the changes in Python's CVS. I'd be willing to give you CVS permission for this, if you're willing to work with python-dev regarding the acceptability of the various changes you're proposing. I presume you'll quickly get a sense for what kind of changes are non-controversional and can be checked in without asking. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-04 15:14 Message: Logged In: YES user_id=163326 Guido, if you think that there should either be one big patch that enables Python to be built with mingw or nothing at all, then please close this as 'rejected' or whatever. There are good reasons for doing so, just as there are arguments for incremental patches, like I described above. I won't feel offended, especially as I know how annoying it is for myself to have a SF entry page full of this kind of patches/bugs :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618791&group_id=5470 From noreply@sourceforge.net Tue Apr 22 16:23:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 08:23:47 -0700 Subject: [Patches] [ python-Patches-712900 ] sre fixes for lastindex and minimizing repeats+assertions Message-ID: Patches item #712900, was opened at 2003-03-31 19:54 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: sre fixes for lastindex and minimizing repeats+assertions Initial Comment: The attached patch fixes two bugs in _sre.c; it also does a bit of reorganization. First the bugs. 672491 points out that lastindex is calculated differently in 2.3 than in previous versions. This patch restores the previous behavior. Since lastindex cannot be restored (when backtracking) from lastmark alone, it is now saved and restored independently (by the LASTMARK_SAVE and RESTORE macros). The second bug appears when minimizing repeats are combined with assertions: >>> re.match('([ab]*?)(?=(b)?)c', 'abc').groups() ('ab', 'b') The second group should be None, since the 'b' is consumed by the first group. To fix this, it is necessary to save lastmark before attempting to match the tail in OP_MIN_UNTIL and to restore it if the tail fails to match. The reorganization has to do with the handling of the SRE_STATE's lastmark and mark array. The mark array tracks the start and end of capturing groups; lastmark is the highest index in the array so far encountered. Previously, whenever lastmark was restored back to a lower value (in 2.3a2 this is done in the lastmark_restore function), the tail of the mark array was NULLed out (using memset). This patch adopts the rule that all indexes greater than lastmark are invalid, so restoring lastmark does not also require clearing the tail. To ensure that indexes <= lastmark have valid pointers, OP_MARK checks if lastmark is being increased by more than one; if so, it NULLs out the intervening pointers. This rule also required changes to the GROUPREF opcodes and the state_getslice function to ensure that they do not access indexes greater than lastmark. For consistency, lastmark is now initialized to –1, to indicate that no entries in the mark array are valid. Needless to say, the reorganization is not necessary to fix the bugs; it may be a bad idea. It seems to be marginally faster than a version that fixes the bugs but is similar to the current code (including a memset inside the LASTMARK_RESTORE macro). One other thing. I have removed a test for string == Py_None from state_getslice, since I can’t find any way for string to be Py_None at that point (string is always the object providing the text to be searched; if it were Py_None, an exception should be raised by the getstring function called by state_init). Perhaps I missed something? ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-22 15:23 Message: Logged In: YES user_id=7887 Greg, what I meant is that I *think* that every SRE_MATCH() recursion with *failing* possibilities should be protected by SAVE/RESTORE(), as it can potentially change lastmark/lastindex before returning, depending on what is being executed. Do you belive the first part of MAX_UNTIL shouldn't be protected, even though it could match a subpattern including marks and fail? If so, can you explain? OTOH, I agree with you that MAX_UNTIL and MIN_UNTIL are not coherent. I'll fix that in the safe side for now, including mark protection in both. If we end up discovering it was not necessary, we simply drop it. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-04-20 12:33 Message: Logged In: YES user_id=86307 Gustavo, thanks for reworking and applying the patch. And thanks for catching the bug in the MIN_REPEAT_ONE where I was not calling lastmark_restore in the right place; it does need to be inside the loop (though I think it could be at the bottom -- it's not necessary if SRE_COUNT returns 0). I note in your checkin message you are concerned about whether all calls to SRE_MATCH need to be protected by LASTMATCH_SAVE/RESTORE. These should only be necessary where SRE_MATCH returns 0 but nevertheless matching continues (i.e., a backtrack point or an alternative). So they are clearly not necessary for ASSERT and REPEAT. ASSERT_NOT is an interesting case. Right now, a capturing group (inside the negative assertion) which matches before the subpattern fails is reported as having matched; this is the way Perl works. You could argue that it would be more consistent for these groups always to report as unmatched (Jeffrey Friedl implies as much in the first edition of his book), in which case the ASSERT_NOT should be surrounded by LASTMARK_SAVE/RESTORE. Anyway, it should not be necessary to protect the first part of the MAX_UNTIL and MIN_UNTIL opcodes (the part which assures the repeat has matched the minimum number of times); if this part fails, it causes this invocation of SRE_MATCH to return 0. I note that you have protected this part of MAX_UNTIL but not MIN_UNTIL. We should probably be consistent here and remove the protection from MAX_UNTIL. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 07:47 Message: Logged In: YES user_id=7887 Greg, thank you very much for the patch. I've included the fixes without introducing the reorganization mentioned, for the sake of stability. Also, the second fix mentioned in your report don't fix the mentioned problem anymore, because of the change introduced by patch #720991. The new fix wasn't complicated though, and is included as well. About the reorganization, I don't have a strong opinion about it, and I'm also not sure about the real impact the new "mark reset" code will cause in the module. IMO we need to test it further. Andrew, that explains why the second fix greg mentions doesn't work anymore. Thanks for mentioning it. The changes were applied as: Modules/_sre.c: 2.91 Lib/test/re_tests.py: 1.35 Lib/test/test_sre.py: 1.41 ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-20 05:08 Message: Logged In: YES user_id=250749 Note that Guido checked in patch #720991, which incorporates some of Greg's work (at least that's what patch author Gary Herron notes) on April 14. That checkin makes _sre.c (more) sensitive to optimisation settings for me (see my comment against that patch). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 02:35 Message: Logged In: YES user_id=7887 Backing out the changes was not enough. I'll evaluate your solution. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 01:51 Message: Logged In: YES user_id=7887 Greg, thanks for mentioning that. I have fixed the first bug by myself, by backing out some of the changes I made in _sre.c:2.84. Can you please check it out and verify if it has the behavior you'd expect now? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:53 Message: Logged In: YES user_id=7887 Greg, this patch doesn't seem to compile in the latest CVS. Are you able to update it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 From noreply@sourceforge.net Tue Apr 22 20:21:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 12:21:46 -0700 Subject: [Patches] [ python-Patches-712900 ] sre fixes for lastindex and minimizing repeats+assertions Message-ID: Patches item #712900, was opened at 2003-03-31 10:54 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: sre fixes for lastindex and minimizing repeats+assertions Initial Comment: The attached patch fixes two bugs in _sre.c; it also does a bit of reorganization. First the bugs. 672491 points out that lastindex is calculated differently in 2.3 than in previous versions. This patch restores the previous behavior. Since lastindex cannot be restored (when backtracking) from lastmark alone, it is now saved and restored independently (by the LASTMARK_SAVE and RESTORE macros). The second bug appears when minimizing repeats are combined with assertions: >>> re.match('([ab]*?)(?=(b)?)c', 'abc').groups() ('ab', 'b') The second group should be None, since the 'b' is consumed by the first group. To fix this, it is necessary to save lastmark before attempting to match the tail in OP_MIN_UNTIL and to restore it if the tail fails to match. The reorganization has to do with the handling of the SRE_STATE's lastmark and mark array. The mark array tracks the start and end of capturing groups; lastmark is the highest index in the array so far encountered. Previously, whenever lastmark was restored back to a lower value (in 2.3a2 this is done in the lastmark_restore function), the tail of the mark array was NULLed out (using memset). This patch adopts the rule that all indexes greater than lastmark are invalid, so restoring lastmark does not also require clearing the tail. To ensure that indexes <= lastmark have valid pointers, OP_MARK checks if lastmark is being increased by more than one; if so, it NULLs out the intervening pointers. This rule also required changes to the GROUPREF opcodes and the state_getslice function to ensure that they do not access indexes greater than lastmark. For consistency, lastmark is now initialized to –1, to indicate that no entries in the mark array are valid. Needless to say, the reorganization is not necessary to fix the bugs; it may be a bad idea. It seems to be marginally faster than a version that fixes the bugs but is similar to the current code (including a memset inside the LASTMARK_RESTORE macro). One other thing. I have removed a test for string == Py_None from state_getslice, since I can’t find any way for string to be Py_None at that point (string is always the object providing the text to be searched; if it were Py_None, an exception should be raised by the getstring function called by state_init). Perhaps I missed something? ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2003-04-22 11:21 Message: Logged In: YES user_id=86307 Gustavo, in my understanding, it doesn't matter if the first part of MAX_UNTIL is protected because if its call to SRE_MATCH returns 0, it (the first part of MAX_UNTIL) simply returns 0 to its caller. If that caller is a backtrack point (a point which may resume matching even though a call to SRE_MATCH returned 0), it should have already saved lastmark, etc. and so should be ready to restore them to its saved values. If that caller is not a backtrack point, it is either the original invocation of SRE_MATCH (in which case it doesn't matter what is in the state since the match has failed) or it is someplace which is going to return 0 to its caller. FYI, I have uploaded a couple of more sre bug reports/patches in the last couple of days; I'd appreciate it if you look at them. http://www.python.org/sf/725106 http://www.python.org/sf/725149 In particular, the second patch changes ASSERT_NOT so that (I hope) it no longer violates the assumptions above. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-22 07:23 Message: Logged In: YES user_id=7887 Greg, what I meant is that I *think* that every SRE_MATCH() recursion with *failing* possibilities should be protected by SAVE/RESTORE(), as it can potentially change lastmark/lastindex before returning, depending on what is being executed. Do you belive the first part of MAX_UNTIL shouldn't be protected, even though it could match a subpattern including marks and fail? If so, can you explain? OTOH, I agree with you that MAX_UNTIL and MIN_UNTIL are not coherent. I'll fix that in the safe side for now, including mark protection in both. If we end up discovering it was not necessary, we simply drop it. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-04-20 04:33 Message: Logged In: YES user_id=86307 Gustavo, thanks for reworking and applying the patch. And thanks for catching the bug in the MIN_REPEAT_ONE where I was not calling lastmark_restore in the right place; it does need to be inside the loop (though I think it could be at the bottom -- it's not necessary if SRE_COUNT returns 0). I note in your checkin message you are concerned about whether all calls to SRE_MATCH need to be protected by LASTMATCH_SAVE/RESTORE. These should only be necessary where SRE_MATCH returns 0 but nevertheless matching continues (i.e., a backtrack point or an alternative). So they are clearly not necessary for ASSERT and REPEAT. ASSERT_NOT is an interesting case. Right now, a capturing group (inside the negative assertion) which matches before the subpattern fails is reported as having matched; this is the way Perl works. You could argue that it would be more consistent for these groups always to report as unmatched (Jeffrey Friedl implies as much in the first edition of his book), in which case the ASSERT_NOT should be surrounded by LASTMARK_SAVE/RESTORE. Anyway, it should not be necessary to protect the first part of the MAX_UNTIL and MIN_UNTIL opcodes (the part which assures the repeat has matched the minimum number of times); if this part fails, it causes this invocation of SRE_MATCH to return 0. I note that you have protected this part of MAX_UNTIL but not MIN_UNTIL. We should probably be consistent here and remove the protection from MAX_UNTIL. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:47 Message: Logged In: YES user_id=7887 Greg, thank you very much for the patch. I've included the fixes without introducing the reorganization mentioned, for the sake of stability. Also, the second fix mentioned in your report don't fix the mentioned problem anymore, because of the change introduced by patch #720991. The new fix wasn't complicated though, and is included as well. About the reorganization, I don't have a strong opinion about it, and I'm also not sure about the real impact the new "mark reset" code will cause in the module. IMO we need to test it further. Andrew, that explains why the second fix greg mentions doesn't work anymore. Thanks for mentioning it. The changes were applied as: Modules/_sre.c: 2.91 Lib/test/re_tests.py: 1.35 Lib/test/test_sre.py: 1.41 ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-19 21:08 Message: Logged In: YES user_id=250749 Note that Guido checked in patch #720991, which incorporates some of Greg's work (at least that's what patch author Gary Herron notes) on April 14. That checkin makes _sre.c (more) sensitive to optimisation settings for me (see my comment against that patch). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 18:35 Message: Logged In: YES user_id=7887 Backing out the changes was not enough. I'll evaluate your solution. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 17:51 Message: Logged In: YES user_id=7887 Greg, thanks for mentioning that. I have fixed the first bug by myself, by backing out some of the changes I made in _sre.c:2.84. Can you please check it out and verify if it has the behavior you'd expect now? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 15:53 Message: Logged In: YES user_id=7887 Greg, this patch doesn't seem to compile in the latest CVS. Are you able to update it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 From noreply@sourceforge.net Tue Apr 22 21:05:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 13:05:52 -0700 Subject: [Patches] [ python-Patches-712900 ] sre fixes for lastindex and minimizing repeats+assertions Message-ID: Patches item #712900, was opened at 2003-03-31 19:54 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: sre fixes for lastindex and minimizing repeats+assertions Initial Comment: The attached patch fixes two bugs in _sre.c; it also does a bit of reorganization. First the bugs. 672491 points out that lastindex is calculated differently in 2.3 than in previous versions. This patch restores the previous behavior. Since lastindex cannot be restored (when backtracking) from lastmark alone, it is now saved and restored independently (by the LASTMARK_SAVE and RESTORE macros). The second bug appears when minimizing repeats are combined with assertions: >>> re.match('([ab]*?)(?=(b)?)c', 'abc').groups() ('ab', 'b') The second group should be None, since the 'b' is consumed by the first group. To fix this, it is necessary to save lastmark before attempting to match the tail in OP_MIN_UNTIL and to restore it if the tail fails to match. The reorganization has to do with the handling of the SRE_STATE's lastmark and mark array. The mark array tracks the start and end of capturing groups; lastmark is the highest index in the array so far encountered. Previously, whenever lastmark was restored back to a lower value (in 2.3a2 this is done in the lastmark_restore function), the tail of the mark array was NULLed out (using memset). This patch adopts the rule that all indexes greater than lastmark are invalid, so restoring lastmark does not also require clearing the tail. To ensure that indexes <= lastmark have valid pointers, OP_MARK checks if lastmark is being increased by more than one; if so, it NULLs out the intervening pointers. This rule also required changes to the GROUPREF opcodes and the state_getslice function to ensure that they do not access indexes greater than lastmark. For consistency, lastmark is now initialized to –1, to indicate that no entries in the mark array are valid. Needless to say, the reorganization is not necessary to fix the bugs; it may be a bad idea. It seems to be marginally faster than a version that fixes the bugs but is similar to the current code (including a memset inside the LASTMARK_RESTORE macro). One other thing. I have removed a test for string == Py_None from state_getslice, since I can’t find any way for string to be Py_None at that point (string is always the object providing the text to be searched; if it were Py_None, an exception should be raised by the getstring function called by state_init). Perhaps I missed something? ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-22 20:05 Message: Logged In: YES user_id=7887 Hummm.. interesting. Indeed, we could use two different strategies. We could either restore marks whenever failling, so that backtrackings don't have to worry about that (it knows it was restored if the recursion failed), or use your approach and protect only when *not* failling. While I was thinking about the first one, the later (your suggestion) seems more logic, and fast. Either way, we clearly have a mix of both today (for example, we have no mark protection in OP_REPEAT), and that's not very smart. I'll study that code further, to make sure that we're really on the right track, and also check your bugs. Thank you very much for explaining and discussing. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-04-22 19:21 Message: Logged In: YES user_id=86307 Gustavo, in my understanding, it doesn't matter if the first part of MAX_UNTIL is protected because if its call to SRE_MATCH returns 0, it (the first part of MAX_UNTIL) simply returns 0 to its caller. If that caller is a backtrack point (a point which may resume matching even though a call to SRE_MATCH returned 0), it should have already saved lastmark, etc. and so should be ready to restore them to its saved values. If that caller is not a backtrack point, it is either the original invocation of SRE_MATCH (in which case it doesn't matter what is in the state since the match has failed) or it is someplace which is going to return 0 to its caller. FYI, I have uploaded a couple of more sre bug reports/patches in the last couple of days; I'd appreciate it if you look at them. http://www.python.org/sf/725106 http://www.python.org/sf/725149 In particular, the second patch changes ASSERT_NOT so that (I hope) it no longer violates the assumptions above. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-22 15:23 Message: Logged In: YES user_id=7887 Greg, what I meant is that I *think* that every SRE_MATCH() recursion with *failing* possibilities should be protected by SAVE/RESTORE(), as it can potentially change lastmark/lastindex before returning, depending on what is being executed. Do you belive the first part of MAX_UNTIL shouldn't be protected, even though it could match a subpattern including marks and fail? If so, can you explain? OTOH, I agree with you that MAX_UNTIL and MIN_UNTIL are not coherent. I'll fix that in the safe side for now, including mark protection in both. If we end up discovering it was not necessary, we simply drop it. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-04-20 12:33 Message: Logged In: YES user_id=86307 Gustavo, thanks for reworking and applying the patch. And thanks for catching the bug in the MIN_REPEAT_ONE where I was not calling lastmark_restore in the right place; it does need to be inside the loop (though I think it could be at the bottom -- it's not necessary if SRE_COUNT returns 0). I note in your checkin message you are concerned about whether all calls to SRE_MATCH need to be protected by LASTMATCH_SAVE/RESTORE. These should only be necessary where SRE_MATCH returns 0 but nevertheless matching continues (i.e., a backtrack point or an alternative). So they are clearly not necessary for ASSERT and REPEAT. ASSERT_NOT is an interesting case. Right now, a capturing group (inside the negative assertion) which matches before the subpattern fails is reported as having matched; this is the way Perl works. You could argue that it would be more consistent for these groups always to report as unmatched (Jeffrey Friedl implies as much in the first edition of his book), in which case the ASSERT_NOT should be surrounded by LASTMARK_SAVE/RESTORE. Anyway, it should not be necessary to protect the first part of the MAX_UNTIL and MIN_UNTIL opcodes (the part which assures the repeat has matched the minimum number of times); if this part fails, it causes this invocation of SRE_MATCH to return 0. I note that you have protected this part of MAX_UNTIL but not MIN_UNTIL. We should probably be consistent here and remove the protection from MAX_UNTIL. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 07:47 Message: Logged In: YES user_id=7887 Greg, thank you very much for the patch. I've included the fixes without introducing the reorganization mentioned, for the sake of stability. Also, the second fix mentioned in your report don't fix the mentioned problem anymore, because of the change introduced by patch #720991. The new fix wasn't complicated though, and is included as well. About the reorganization, I don't have a strong opinion about it, and I'm also not sure about the real impact the new "mark reset" code will cause in the module. IMO we need to test it further. Andrew, that explains why the second fix greg mentions doesn't work anymore. Thanks for mentioning it. The changes were applied as: Modules/_sre.c: 2.91 Lib/test/re_tests.py: 1.35 Lib/test/test_sre.py: 1.41 ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-20 05:08 Message: Logged In: YES user_id=250749 Note that Guido checked in patch #720991, which incorporates some of Greg's work (at least that's what patch author Gary Herron notes) on April 14. That checkin makes _sre.c (more) sensitive to optimisation settings for me (see my comment against that patch). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 02:35 Message: Logged In: YES user_id=7887 Backing out the changes was not enough. I'll evaluate your solution. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 01:51 Message: Logged In: YES user_id=7887 Greg, thanks for mentioning that. I have fixed the first bug by myself, by backing out some of the changes I made in _sre.c:2.84. Can you please check it out and verify if it has the behavior you'd expect now? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:53 Message: Logged In: YES user_id=7887 Greg, this patch doesn't seem to compile in the latest CVS. Are you able to update it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 From noreply@sourceforge.net Tue Apr 22 21:11:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 13:11:00 -0700 Subject: [Patches] [ python-Patches-712900 ] sre fixes for lastindex and minimizing repeats+assertions Message-ID: Patches item #712900, was opened at 2003-03-31 19:54 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: sre fixes for lastindex and minimizing repeats+assertions Initial Comment: The attached patch fixes two bugs in _sre.c; it also does a bit of reorganization. First the bugs. 672491 points out that lastindex is calculated differently in 2.3 than in previous versions. This patch restores the previous behavior. Since lastindex cannot be restored (when backtracking) from lastmark alone, it is now saved and restored independently (by the LASTMARK_SAVE and RESTORE macros). The second bug appears when minimizing repeats are combined with assertions: >>> re.match('([ab]*?)(?=(b)?)c', 'abc').groups() ('ab', 'b') The second group should be None, since the 'b' is consumed by the first group. To fix this, it is necessary to save lastmark before attempting to match the tail in OP_MIN_UNTIL and to restore it if the tail fails to match. The reorganization has to do with the handling of the SRE_STATE's lastmark and mark array. The mark array tracks the start and end of capturing groups; lastmark is the highest index in the array so far encountered. Previously, whenever lastmark was restored back to a lower value (in 2.3a2 this is done in the lastmark_restore function), the tail of the mark array was NULLed out (using memset). This patch adopts the rule that all indexes greater than lastmark are invalid, so restoring lastmark does not also require clearing the tail. To ensure that indexes <= lastmark have valid pointers, OP_MARK checks if lastmark is being increased by more than one; if so, it NULLs out the intervening pointers. This rule also required changes to the GROUPREF opcodes and the state_getslice function to ensure that they do not access indexes greater than lastmark. For consistency, lastmark is now initialized to –1, to indicate that no entries in the mark array are valid. Needless to say, the reorganization is not necessary to fix the bugs; it may be a bad idea. It seems to be marginally faster than a version that fixes the bugs but is similar to the current code (including a memset inside the LASTMARK_RESTORE macro). One other thing. I have removed a test for string == Py_None from state_getslice, since I can’t find any way for string to be Py_None at that point (string is always the object providing the text to be searched; if it were Py_None, an exception should be raised by the getstring function called by state_init). Perhaps I missed something? ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-22 20:11 Message: Logged In: YES user_id=7887 Nevermind about OP_REPEAT. It won't backtrack so it doesn't matter. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-22 20:05 Message: Logged In: YES user_id=7887 Hummm.. interesting. Indeed, we could use two different strategies. We could either restore marks whenever failling, so that backtrackings don't have to worry about that (it knows it was restored if the recursion failed), or use your approach and protect only when *not* failling. While I was thinking about the first one, the later (your suggestion) seems more logic, and fast. Either way, we clearly have a mix of both today (for example, we have no mark protection in OP_REPEAT), and that's not very smart. I'll study that code further, to make sure that we're really on the right track, and also check your bugs. Thank you very much for explaining and discussing. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-04-22 19:21 Message: Logged In: YES user_id=86307 Gustavo, in my understanding, it doesn't matter if the first part of MAX_UNTIL is protected because if its call to SRE_MATCH returns 0, it (the first part of MAX_UNTIL) simply returns 0 to its caller. If that caller is a backtrack point (a point which may resume matching even though a call to SRE_MATCH returned 0), it should have already saved lastmark, etc. and so should be ready to restore them to its saved values. If that caller is not a backtrack point, it is either the original invocation of SRE_MATCH (in which case it doesn't matter what is in the state since the match has failed) or it is someplace which is going to return 0 to its caller. FYI, I have uploaded a couple of more sre bug reports/patches in the last couple of days; I'd appreciate it if you look at them. http://www.python.org/sf/725106 http://www.python.org/sf/725149 In particular, the second patch changes ASSERT_NOT so that (I hope) it no longer violates the assumptions above. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-22 15:23 Message: Logged In: YES user_id=7887 Greg, what I meant is that I *think* that every SRE_MATCH() recursion with *failing* possibilities should be protected by SAVE/RESTORE(), as it can potentially change lastmark/lastindex before returning, depending on what is being executed. Do you belive the first part of MAX_UNTIL shouldn't be protected, even though it could match a subpattern including marks and fail? If so, can you explain? OTOH, I agree with you that MAX_UNTIL and MIN_UNTIL are not coherent. I'll fix that in the safe side for now, including mark protection in both. If we end up discovering it was not necessary, we simply drop it. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-04-20 12:33 Message: Logged In: YES user_id=86307 Gustavo, thanks for reworking and applying the patch. And thanks for catching the bug in the MIN_REPEAT_ONE where I was not calling lastmark_restore in the right place; it does need to be inside the loop (though I think it could be at the bottom -- it's not necessary if SRE_COUNT returns 0). I note in your checkin message you are concerned about whether all calls to SRE_MATCH need to be protected by LASTMATCH_SAVE/RESTORE. These should only be necessary where SRE_MATCH returns 0 but nevertheless matching continues (i.e., a backtrack point or an alternative). So they are clearly not necessary for ASSERT and REPEAT. ASSERT_NOT is an interesting case. Right now, a capturing group (inside the negative assertion) which matches before the subpattern fails is reported as having matched; this is the way Perl works. You could argue that it would be more consistent for these groups always to report as unmatched (Jeffrey Friedl implies as much in the first edition of his book), in which case the ASSERT_NOT should be surrounded by LASTMARK_SAVE/RESTORE. Anyway, it should not be necessary to protect the first part of the MAX_UNTIL and MIN_UNTIL opcodes (the part which assures the repeat has matched the minimum number of times); if this part fails, it causes this invocation of SRE_MATCH to return 0. I note that you have protected this part of MAX_UNTIL but not MIN_UNTIL. We should probably be consistent here and remove the protection from MAX_UNTIL. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 07:47 Message: Logged In: YES user_id=7887 Greg, thank you very much for the patch. I've included the fixes without introducing the reorganization mentioned, for the sake of stability. Also, the second fix mentioned in your report don't fix the mentioned problem anymore, because of the change introduced by patch #720991. The new fix wasn't complicated though, and is included as well. About the reorganization, I don't have a strong opinion about it, and I'm also not sure about the real impact the new "mark reset" code will cause in the module. IMO we need to test it further. Andrew, that explains why the second fix greg mentions doesn't work anymore. Thanks for mentioning it. The changes were applied as: Modules/_sre.c: 2.91 Lib/test/re_tests.py: 1.35 Lib/test/test_sre.py: 1.41 ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-20 05:08 Message: Logged In: YES user_id=250749 Note that Guido checked in patch #720991, which incorporates some of Greg's work (at least that's what patch author Gary Herron notes) on April 14. That checkin makes _sre.c (more) sensitive to optimisation settings for me (see my comment against that patch). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 02:35 Message: Logged In: YES user_id=7887 Backing out the changes was not enough. I'll evaluate your solution. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-20 01:51 Message: Logged In: YES user_id=7887 Greg, thanks for mentioning that. I have fixed the first bug by myself, by backing out some of the changes I made in _sre.c:2.84. Can you please check it out and verify if it has the behavior you'd expect now? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-04-19 23:53 Message: Logged In: YES user_id=7887 Greg, this patch doesn't seem to compile in the latest CVS. Are you able to update it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712900&group_id=5470 From noreply@sourceforge.net Tue Apr 22 21:58:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 13:58:20 -0700 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 21:50 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 >Status: Open Resolution: Fixed >Priority: 7 Submitted By: Matthias Klose (doko) >Assigned to: Jeremy Hylton (jhylton) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-04-22 20:58 Message: Logged In: YES user_id=31392 Rev 1.122 disables bsddb3 support for my build. The apparent problem is that it looks in /usr/include before doing any other search. On my RedHat 7.2 system, /usr/include/db.h is a Berkeley DB 3 header file. I have a valid Berkeley DB 4.1.x install in /usr/local/BerkeleyDB.4.1/ Can we make this work by adding /usr/include to the list of directories that are searched by the normal berkeley db search process? I'll try that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-06 10:25 Message: Logged In: YES user_id=21627 Committed a similar patch as setup.py 1.222. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-23 10:40 Message: Logged In: YES user_id=21627 Can you please try the attached bsd.diff? It should find db.h in the standard include directories, and use it if possible. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-11-01 14:02 Message: Logged In: YES user_id=44345 > so why not use /etc/debian_version? That's fine. I didn't know it existed, having had no previous experience with Debian. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-01 09:41 Message: Logged In: YES user_id=21627 Would you like to update your patch to implement that strategy? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-11-01 07:58 Message: Logged In: YES user_id=60903 so why not use /etc/debian_version? the dpkg thing is useful to determine the correct db version, or you grep the include file for the version number. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-31 22:24 Message: Logged In: YES user_id=44345 I was thinking more along the lines of a file we could look for. For example, on my Mandrake systems I have /etc/mandrake-release. I suspect that pretty much rules out other Linux dialects (though what if someone converts to another version but doesn't format their disks?). Testing the presence of dpkg isn't sufficient either. Other systems can use it. In fact, I have dpkg on my MacOSX system as a side-effect of being a fink user (http://fink.sf.net/). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-31 22:13 Message: Logged In: YES user_id=60903 two possibilities come to mind: dpkg -S /usr/include/db.h prints: libdb4.0-dev: /usr/include/db.h (or libdb3-dev, if the libdb3-dev package is installed). Note that the installation of a libdb-dev package is not required, so this command may return with an error. I'm pretty sure, that dpkg only exists on Debian systems ;-) or else test for the existance of the file /etc/debian_version first. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 15:46 Message: Logged In: YES user_id=44345 It's clear we can't blindly add '/usr/include' to db_try_this['db4']['incdirs'] and 'db' to db_try_this['db4']['libs']. Is there some way to unambiguously detect from setup.py that Python is being built on a Debian system and that we are not dealing with an installation of db1 (which I still refuse to enable without manual intervention)? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 15:12 Message: Logged In: YES user_id=21627 /usr/include/db.h is not a symlink; it is the file itself. You cannot have multiple bsddb development packages (libdbX-dev) installed, because they conflict with each other. /usr/lib/libdb.so exists and is a symlink to the installed shared library. The file in question isn't actually db.h (for current bsddbmodule.c), but db_185.h, of course. As for base+patch: Sure, Debian already uses such a patch. Matthias is the Debian maintainer of Python, and asks us (as upstream) to include his patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 14:39 Message: Logged In: YES user_id=44345 Is /usr/include/db.h a symlink to some other file on Debian which is version-specific? If so, I'd be happy to add that directory to the list searched. How does Debian structure its directories to allow multiple versions of Berkeley db to be installed simultaneously? If /usr/include/db.h is the location of the include file, is /usr/lib/libdb.{so,a} the location of the library? The original (db1) versions of Berkeley DB generally had db.h in /usr/include. This version is, unfortunately, both broken and still in use. Other vendors allow multiple versions of the library to be installed, and use a version-specific directory naming scheme to keep things sorted out. Debian could do the same. No matter how strongly you believe /usr/include should be searched, I'm not going to add it by default and risk the chance that other peoples' installs break (silently) as a result. Please read the comments related to db1 in setup.py. (Search for bsddb.) Final thought here... Doesn't Debian have and base+patch sort of system? To install on Debian, all that would need to be done is develop a Debian-specific patch which adds /usr/include to the incdirs key and something like 'db' to the libs key in the db4 section. Skip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 22:11 Message: Logged In: YES user_id=21627 As a bug report, I would close this as "Won't fix", pointing you to the option of not using setup.py, but compiling the module through Modules/Setup. I'd prefer to get a patch, but that should be one that works on all systems. This one breaks on systems where /usr/include/db.h is not a bsddb 4 header file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 21:54 Message: Logged In: YES user_id=60903 > - Doesn't it cause -I/usr/include be added to the > compilation statement? yes, that's not correct > - Why is that done for db4 and not db3? On Debian only one libdb-dev package can be installed at build time. I assure with the build dependencies that I get the correct one. > - How can we know what bsddb version /usr/include/db.h > belongs to? Guessing that it is db4 is error-prone, so it > might be, in fact, better not to find that file. maybe grep for DB_VERSION_MAJOR in the file? I admit, this issue should be a bug report, not a patch ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 21:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 21:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 13:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Tue Apr 22 22:18:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 14:18:13 -0700 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 16:50 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Fixed >Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Jeremy Hylton (jhylton) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-04-22 16:18 Message: Logged In: YES user_id=44345 Matthias, I don't see a reasonable way this can work. If you have db4 installed, it will still be found first because db4 is checked before db3. The best way to solve this would be to allow you to specify the search order. Would it be okay to set an environment variable to specify the search order? Something like PYBSDDB_VERSIONS=db3:db4 ; export PYBSDDB_VERSIONS If set, it would override the default setting of db_search_order in setup.py. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-04-22 15:58 Message: Logged In: YES user_id=31392 Rev 1.122 disables bsddb3 support for my build. The apparent problem is that it looks in /usr/include before doing any other search. On my RedHat 7.2 system, /usr/include/db.h is a Berkeley DB 3 header file. I have a valid Berkeley DB 4.1.x install in /usr/local/BerkeleyDB.4.1/ Can we make this work by adding /usr/include to the list of directories that are searched by the normal berkeley db search process? I'll try that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-06 04:25 Message: Logged In: YES user_id=21627 Committed a similar patch as setup.py 1.222. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-23 04:40 Message: Logged In: YES user_id=21627 Can you please try the attached bsd.diff? It should find db.h in the standard include directories, and use it if possible. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-11-01 08:02 Message: Logged In: YES user_id=44345 > so why not use /etc/debian_version? That's fine. I didn't know it existed, having had no previous experience with Debian. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-01 03:41 Message: Logged In: YES user_id=21627 Would you like to update your patch to implement that strategy? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-11-01 01:58 Message: Logged In: YES user_id=60903 so why not use /etc/debian_version? the dpkg thing is useful to determine the correct db version, or you grep the include file for the version number. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-31 16:24 Message: Logged In: YES user_id=44345 I was thinking more along the lines of a file we could look for. For example, on my Mandrake systems I have /etc/mandrake-release. I suspect that pretty much rules out other Linux dialects (though what if someone converts to another version but doesn't format their disks?). Testing the presence of dpkg isn't sufficient either. Other systems can use it. In fact, I have dpkg on my MacOSX system as a side-effect of being a fink user (http://fink.sf.net/). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-31 16:13 Message: Logged In: YES user_id=60903 two possibilities come to mind: dpkg -S /usr/include/db.h prints: libdb4.0-dev: /usr/include/db.h (or libdb3-dev, if the libdb3-dev package is installed). Note that the installation of a libdb-dev package is not required, so this command may return with an error. I'm pretty sure, that dpkg only exists on Debian systems ;-) or else test for the existance of the file /etc/debian_version first. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 09:46 Message: Logged In: YES user_id=44345 It's clear we can't blindly add '/usr/include' to db_try_this['db4']['incdirs'] and 'db' to db_try_this['db4']['libs']. Is there some way to unambiguously detect from setup.py that Python is being built on a Debian system and that we are not dealing with an installation of db1 (which I still refuse to enable without manual intervention)? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 09:12 Message: Logged In: YES user_id=21627 /usr/include/db.h is not a symlink; it is the file itself. You cannot have multiple bsddb development packages (libdbX-dev) installed, because they conflict with each other. /usr/lib/libdb.so exists and is a symlink to the installed shared library. The file in question isn't actually db.h (for current bsddbmodule.c), but db_185.h, of course. As for base+patch: Sure, Debian already uses such a patch. Matthias is the Debian maintainer of Python, and asks us (as upstream) to include his patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 08:39 Message: Logged In: YES user_id=44345 Is /usr/include/db.h a symlink to some other file on Debian which is version-specific? If so, I'd be happy to add that directory to the list searched. How does Debian structure its directories to allow multiple versions of Berkeley db to be installed simultaneously? If /usr/include/db.h is the location of the include file, is /usr/lib/libdb.{so,a} the location of the library? The original (db1) versions of Berkeley DB generally had db.h in /usr/include. This version is, unfortunately, both broken and still in use. Other vendors allow multiple versions of the library to be installed, and use a version-specific directory naming scheme to keep things sorted out. Debian could do the same. No matter how strongly you believe /usr/include should be searched, I'm not going to add it by default and risk the chance that other peoples' installs break (silently) as a result. Please read the comments related to db1 in setup.py. (Search for bsddb.) Final thought here... Doesn't Debian have and base+patch sort of system? To install on Debian, all that would need to be done is develop a Debian-specific patch which adds /usr/include to the incdirs key and something like 'db' to the libs key in the db4 section. Skip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 17:11 Message: Logged In: YES user_id=21627 As a bug report, I would close this as "Won't fix", pointing you to the option of not using setup.py, but compiling the module through Modules/Setup. I'd prefer to get a patch, but that should be one that works on all systems. This one breaks on systems where /usr/include/db.h is not a bsddb 4 header file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 16:54 Message: Logged In: YES user_id=60903 > - Doesn't it cause -I/usr/include be added to the > compilation statement? yes, that's not correct > - Why is that done for db4 and not db3? On Debian only one libdb-dev package can be installed at build time. I assure with the build dependencies that I get the correct one. > - How can we know what bsddb version /usr/include/db.h > belongs to? Guessing that it is db4 is error-prone, so it > might be, in fact, better not to find that file. maybe grep for DB_VERSION_MAJOR in the file? I admit, this issue should be a bug report, not a patch ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 16:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 16:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 08:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Tue Apr 22 23:02:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 15:02:51 -0700 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 21:50 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-04-22 22:02 Message: Logged In: YES user_id=31392 I take it back. It looks like the current code works. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-04-22 21:18 Message: Logged In: YES user_id=44345 Matthias, I don't see a reasonable way this can work. If you have db4 installed, it will still be found first because db4 is checked before db3. The best way to solve this would be to allow you to specify the search order. Would it be okay to set an environment variable to specify the search order? Something like PYBSDDB_VERSIONS=db3:db4 ; export PYBSDDB_VERSIONS If set, it would override the default setting of db_search_order in setup.py. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-04-22 20:58 Message: Logged In: YES user_id=31392 Rev 1.122 disables bsddb3 support for my build. The apparent problem is that it looks in /usr/include before doing any other search. On my RedHat 7.2 system, /usr/include/db.h is a Berkeley DB 3 header file. I have a valid Berkeley DB 4.1.x install in /usr/local/BerkeleyDB.4.1/ Can we make this work by adding /usr/include to the list of directories that are searched by the normal berkeley db search process? I'll try that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-06 10:25 Message: Logged In: YES user_id=21627 Committed a similar patch as setup.py 1.222. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-23 10:40 Message: Logged In: YES user_id=21627 Can you please try the attached bsd.diff? It should find db.h in the standard include directories, and use it if possible. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-11-01 14:02 Message: Logged In: YES user_id=44345 > so why not use /etc/debian_version? That's fine. I didn't know it existed, having had no previous experience with Debian. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-01 09:41 Message: Logged In: YES user_id=21627 Would you like to update your patch to implement that strategy? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-11-01 07:58 Message: Logged In: YES user_id=60903 so why not use /etc/debian_version? the dpkg thing is useful to determine the correct db version, or you grep the include file for the version number. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-31 22:24 Message: Logged In: YES user_id=44345 I was thinking more along the lines of a file we could look for. For example, on my Mandrake systems I have /etc/mandrake-release. I suspect that pretty much rules out other Linux dialects (though what if someone converts to another version but doesn't format their disks?). Testing the presence of dpkg isn't sufficient either. Other systems can use it. In fact, I have dpkg on my MacOSX system as a side-effect of being a fink user (http://fink.sf.net/). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-31 22:13 Message: Logged In: YES user_id=60903 two possibilities come to mind: dpkg -S /usr/include/db.h prints: libdb4.0-dev: /usr/include/db.h (or libdb3-dev, if the libdb3-dev package is installed). Note that the installation of a libdb-dev package is not required, so this command may return with an error. I'm pretty sure, that dpkg only exists on Debian systems ;-) or else test for the existance of the file /etc/debian_version first. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 15:46 Message: Logged In: YES user_id=44345 It's clear we can't blindly add '/usr/include' to db_try_this['db4']['incdirs'] and 'db' to db_try_this['db4']['libs']. Is there some way to unambiguously detect from setup.py that Python is being built on a Debian system and that we are not dealing with an installation of db1 (which I still refuse to enable without manual intervention)? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 15:12 Message: Logged In: YES user_id=21627 /usr/include/db.h is not a symlink; it is the file itself. You cannot have multiple bsddb development packages (libdbX-dev) installed, because they conflict with each other. /usr/lib/libdb.so exists and is a symlink to the installed shared library. The file in question isn't actually db.h (for current bsddbmodule.c), but db_185.h, of course. As for base+patch: Sure, Debian already uses such a patch. Matthias is the Debian maintainer of Python, and asks us (as upstream) to include his patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 14:39 Message: Logged In: YES user_id=44345 Is /usr/include/db.h a symlink to some other file on Debian which is version-specific? If so, I'd be happy to add that directory to the list searched. How does Debian structure its directories to allow multiple versions of Berkeley db to be installed simultaneously? If /usr/include/db.h is the location of the include file, is /usr/lib/libdb.{so,a} the location of the library? The original (db1) versions of Berkeley DB generally had db.h in /usr/include. This version is, unfortunately, both broken and still in use. Other vendors allow multiple versions of the library to be installed, and use a version-specific directory naming scheme to keep things sorted out. Debian could do the same. No matter how strongly you believe /usr/include should be searched, I'm not going to add it by default and risk the chance that other peoples' installs break (silently) as a result. Please read the comments related to db1 in setup.py. (Search for bsddb.) Final thought here... Doesn't Debian have and base+patch sort of system? To install on Debian, all that would need to be done is develop a Debian-specific patch which adds /usr/include to the incdirs key and something like 'db' to the libs key in the db4 section. Skip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 22:11 Message: Logged In: YES user_id=21627 As a bug report, I would close this as "Won't fix", pointing you to the option of not using setup.py, but compiling the module through Modules/Setup. I'd prefer to get a patch, but that should be one that works on all systems. This one breaks on systems where /usr/include/db.h is not a bsddb 4 header file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 21:54 Message: Logged In: YES user_id=60903 > - Doesn't it cause -I/usr/include be added to the > compilation statement? yes, that's not correct > - Why is that done for db4 and not db3? On Debian only one libdb-dev package can be installed at build time. I assure with the build dependencies that I get the correct one. > - How can we know what bsddb version /usr/include/db.h > belongs to? Guessing that it is db4 is error-prone, so it > might be, in fact, better not to find that file. maybe grep for DB_VERSION_MAJOR in the file? I admit, this issue should be a bug report, not a patch ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 21:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 21:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 13:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Tue Apr 22 23:27:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 15:27:30 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 15:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Tue Apr 22 23:27:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 15:27:57 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 15:27 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Brett Cannon (bcannon) >Assigned to: Guido van Rossum (gvanrossum) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Tue Apr 22 23:37:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 15:37:20 -0700 Subject: [Patches] [ python-Patches-725904 ] Minor changes to logging Message-ID: Patches item #725904, was opened at 2003-04-22 22:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Nobody/Anonymous (nobody) Summary: Minor changes to logging Initial Comment: __init__.py: 1. Updated version number to 0.4.8 and status to beta. handlers.py: 1. Replaced explicit Python version check with hasattr to determine the running Python's capability. 2. Added Date: header to SMTPHandler 3. Changed HTTPHandler to allow more flexible mapping of a LogRecord to a dictionary to be urlencoded. Regression test ran OK on my system after these changes were made. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 From noreply@sourceforge.net Tue Apr 22 23:39:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 15:39:09 -0700 Subject: [Patches] [ python-Patches-725904 ] Minor changes to logging Message-ID: Patches item #725904, was opened at 2003-04-22 22:37 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 >Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Vinay Sajip (vsajip) >Assigned to: Guido van Rossum (gvanrossum) Summary: Minor changes to logging Initial Comment: __init__.py: 1. Updated version number to 0.4.8 and status to beta. handlers.py: 1. Replaced explicit Python version check with hasattr to determine the running Python's capability. 2. Added Date: header to SMTPHandler 3. Changed HTTPHandler to allow more flexible mapping of a LogRecord to a dictionary to be urlencoded. Regression test ran OK on my system after these changes were made. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 From noreply@sourceforge.net Wed Apr 23 00:52:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 16:52:38 -0700 Subject: [Patches] [ python-Patches-725942 ] Modules/addrinfo.h patch Message-ID: Patches item #725942, was opened at 2003-04-22 23:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725942&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: David Wood (woodd) Assigned to: Nobody/Anonymous (nobody) Summary: Modules/addrinfo.h patch Initial Comment: I've compiled / linked Python 2.2.2 on Solaris 2.6 for both of my Solaris releases (Solaris 2.6 & Solaris 8). Python works fine on Solaris 2.6; however, on Solaris 2.8 I get the following: File "/usr/local/lib/python2.2/SocketServer.py", line 340, in server_bind self.socket.bind(self.server_address) socket.gaierror: (3, 'getaddrinfo failed') Solaris 2.6 does not have getaddrinfo but Solaris 8 does. The failure occurs on Solaris 8 because Python finds getaddrinfo in /usr/lib/libsocket.so before /usr/local/lib/python2.2/lib-dynload/_socket.so. The return code of 3 (EAI_BADFLAGS) is a result of ai_flags mismatch: bsqa1.nyc:/u/woodd > grep 'define.AI_PASSIVE' Python-2.2.2/Modules/addrinfo.h #define AI_PASSIVE 0x00000001 /* get address to use bind() */ bsqa1.nyc:/u/woodd > grep 'define.AI_PASSIVE' /usr/include/netdb.h #define AI_PASSIVE 0x0008 /* intended for bind() + listen() */ The enclosed patch is simple: always "#define getaddrinfo fake_getaddrinfo" if we don't have getaddrinfo. The same applies for getnameinfo. The enclosed patch is against v2.2.2 Modules/addrinfo.h. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725942&group_id=5470 From noreply@sourceforge.net Wed Apr 23 01:25:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 17:25:56 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 18:27 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:25 Message: Logged In: YES user_id=6380 In general fixing the docs is much safet than fixing the code. ;-) If you submit a doc patch here it'll be applied. (Note that the docstring is also lying.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Wed Apr 23 01:27:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 17:27:13 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 18:27 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:27 Message: Logged In: YES user_id=6380 Hm, I don't see you in the list of committers? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:25 Message: Logged In: YES user_id=6380 In general fixing the docs is much safet than fixing the code. ;-) If you submit a doc patch here it'll be applied. (Note that the docstring is also lying.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Wed Apr 23 01:29:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 17:29:41 -0700 Subject: [Patches] [ python-Patches-725904 ] Minor changes to logging Message-ID: Patches item #725904, was opened at 2003-04-22 18:37 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 7 Submitted By: Vinay Sajip (vsajip) >Assigned to: Nobody/Anonymous (nobody) Summary: Minor changes to logging Initial Comment: __init__.py: 1. Updated version number to 0.4.8 and status to beta. handlers.py: 1. Replaced explicit Python version check with hasattr to determine the running Python's capability. 2. Added Date: header to SMTPHandler 3. Changed HTTPHandler to allow more flexible mapping of a LogRecord to a dictionary to be urlencoded. Regression test ran OK on my system after these changes were made. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:29 Message: Logged In: YES user_id=6380 Unassigning and accepting; someone else please apply this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 From noreply@sourceforge.net Wed Apr 23 01:35:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 17:35:36 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 15:27 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-04-22 17:35 Message: Logged In: YES user_id=357491 OK, I will fix the docs (both the library docs and the docstring). And I don't know why the hell I am not listed. I still can't delete items off of tracker items that I have created (this was a problem before I became a committer). Guess I need to email SF tech support and see what they say. I will get the docs changed and close this patch (assuming it lets me) as if it was assigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:27 Message: Logged In: YES user_id=6380 Hm, I don't see you in the list of committers? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:25 Message: Logged In: YES user_id=6380 In general fixing the docs is much safet than fixing the code. ;-) If you submit a doc patch here it'll be applied. (Note that the docstring is also lying.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Wed Apr 23 01:37:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 17:37:03 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 15:27 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-04-22 17:37 Message: Logged In: YES user_id=357491 Should I also backport this to 2.2? I assume yes, but thought I should double-check (maybe subconsciously I don't want to have to deal with learning how to get a commit correct on a tagged branch =). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 17:35 Message: Logged In: YES user_id=357491 OK, I will fix the docs (both the library docs and the docstring). And I don't know why the hell I am not listed. I still can't delete items off of tracker items that I have created (this was a problem before I became a committer). Guess I need to email SF tech support and see what they say. I will get the docs changed and close this patch (assuming it lets me) as if it was assigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:27 Message: Logged In: YES user_id=6380 Hm, I don't see you in the list of committers? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:25 Message: Logged In: YES user_id=6380 In general fixing the docs is much safet than fixing the code. ;-) If you submit a doc patch here it'll be applied. (Note that the docstring is also lying.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Wed Apr 23 01:53:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 17:53:56 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 18:27 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) >Assigned to: Brett Cannon (bcannon) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 20:37 Message: Logged In: YES user_id=357491 Should I also backport this to 2.2? I assume yes, but thought I should double-check (maybe subconsciously I don't want to have to deal with learning how to get a commit correct on a tagged branch =). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 20:35 Message: Logged In: YES user_id=357491 OK, I will fix the docs (both the library docs and the docstring). And I don't know why the hell I am not listed. I still can't delete items off of tracker items that I have created (this was a problem before I became a committer). Guess I need to email SF tech support and see what they say. I will get the docs changed and close this patch (assuming it lets me) as if it was assigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:27 Message: Logged In: YES user_id=6380 Hm, I don't see you in the list of committers? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:25 Message: Logged In: YES user_id=6380 In general fixing the docs is much safet than fixing the code. ;-) If you submit a doc patch here it'll be applied. (Note that the docstring is also lying.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Wed Apr 23 01:54:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 17:54:44 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 18:27 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:54 Message: Logged In: YES user_id=6380 Somehow, tracker permissions have to be updated separately, and some of the SF admin screens are not very clear. I've upgraded your permissions in this tracker now! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 20:37 Message: Logged In: YES user_id=357491 Should I also backport this to 2.2? I assume yes, but thought I should double-check (maybe subconsciously I don't want to have to deal with learning how to get a commit correct on a tagged branch =). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 20:35 Message: Logged In: YES user_id=357491 OK, I will fix the docs (both the library docs and the docstring). And I don't know why the hell I am not listed. I still can't delete items off of tracker items that I have created (this was a problem before I became a committer). Guess I need to email SF tech support and see what they say. I will get the docs changed and close this patch (assuming it lets me) as if it was assigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:27 Message: Logged In: YES user_id=6380 Hm, I don't see you in the list of committers? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:25 Message: Logged In: YES user_id=6380 In general fixing the docs is much safet than fixing the code. ;-) If you submit a doc patch here it'll be applied. (Note that the docstring is also lying.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Wed Apr 23 01:58:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 17:58:41 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 18:27 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:58 Message: Logged In: YES user_id=6380 Backport to 2.2: yes, but it's just a doc issue. The best way to work with 2.2 if you have the disk space and you already have a trunk checkout: 1) make a copy of your trunk checkout 2) in that copy, do "cvs update -r release22-maint" >From now on, the copy works on the branch. Just remember never to do "cvs update -A" there (this resets the sticky tag to the trunk). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:54 Message: Logged In: YES user_id=6380 Somehow, tracker permissions have to be updated separately, and some of the SF admin screens are not very clear. I've upgraded your permissions in this tracker now! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 20:37 Message: Logged In: YES user_id=357491 Should I also backport this to 2.2? I assume yes, but thought I should double-check (maybe subconsciously I don't want to have to deal with learning how to get a commit correct on a tagged branch =). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 20:35 Message: Logged In: YES user_id=357491 OK, I will fix the docs (both the library docs and the docstring). And I don't know why the hell I am not listed. I still can't delete items off of tracker items that I have created (this was a problem before I became a committer). Guess I need to email SF tech support and see what they say. I will get the docs changed and close this patch (assuming it lets me) as if it was assigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:27 Message: Logged In: YES user_id=6380 Hm, I don't see you in the list of committers? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:25 Message: Logged In: YES user_id=6380 In general fixing the docs is much safet than fixing the code. ;-) If you submit a doc patch here it'll be applied. (Note that the docstring is also lying.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Wed Apr 23 04:52:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 20:52:07 -0700 Subject: [Patches] [ python-Patches-725904 ] Minor changes to logging Message-ID: Patches item #725904, was opened at 2003-04-22 18:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Vinay Sajip (vsajip) >Assigned to: Neal Norwitz (nnorwitz) Summary: Minor changes to logging Initial Comment: __init__.py: 1. Updated version number to 0.4.8 and status to beta. handlers.py: 1. Replaced explicit Python version check with hasattr to determine the running Python's capability. 2. Added Date: header to SMTPHandler 3. Changed HTTPHandler to allow more flexible mapping of a LogRecord to a dictionary to be urlencoded. Regression test ran OK on my system after these changes were made. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-22 23:52 Message: Logged In: YES user_id=33168 Checked in as: * Lib/logging/__init__.py: 1.9 * Lib/logging/handlers.py: 1.6 I still have the test failure problem. It's more consistent on Redhat 9. Adding a time.sleep(.1) to the test as the first statement in the finally: in test_main() (line 458) "fixes" the problem. Although this is a hack that I don't want to check in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:29 Message: Logged In: YES user_id=6380 Unassigning and accepting; someone else please apply this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 From noreply@sourceforge.net Wed Apr 23 04:53:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 20:53:49 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Raymond Hettinger (rhettinger) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-22 22:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 12:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 12:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 11:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 18:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Wed Apr 23 04:55:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Apr 2003 20:55:32 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-22 22:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 12:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 12:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 11:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 18:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Wed Apr 23 12:43:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 04:43:36 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-26 00:16 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2003-04-23 13:43 Message: Logged In: YES user_id=34209 I'd not be proud in any case; neither the concept nor most of the implementation was my idea :-) But my questions still stand; the 3% slowdown in pystone is a lot if all you see is a 1.5% gain in Zope3 startup time, but I can't think of any ways to fix that before next friday, or before 2.3 is released. (The problem is either code size or switch length, which can be 'fixed' by culling code, re-ordering the switch again or changing the switch into a computed-goto.) And I'd need to find me a machine with less cache to actually notice the slowdown :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 14:38 Message: Logged In: YES user_id=6380 However, you should be proud of yourself nevertheless. On the same Zope3 startup "benchmark", Raymond Hettinger's bytecode optimizations scored 0% improvement. Python -O didn't make any difference either. So it's a touch benchmark! (And yes, I did remove the .pyc/.pyo files each time.) (And no, I can't test -OO because Zope uses the docstrings.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 14:20 Message: Logged In: YES user_id=6380 OK, I did a more realistic benchmark: startup time of Zope3. With more or less current CVS Python 2.3 (but not Raymond H's bytecode optimizations), it took 3.52 seconds. With your patch (and all .pyc files rebuilt) it took 3.47 seconds. That's about a percent and a half. (With Python 2.2 it took 4.08 seconds.) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-22 00:48 Message: Logged In: YES user_id=34209 Pystone is not likely to show much speedup, as it contains exactly 2 instances of CALL_ATTR, only barely in the main loop. However, it should not slow down because of CALL_ATTR either; the two CALL_ATTRs are of the most optimized sort, old-style instance methods, and none of the other code paths have changed *at all* (in the fast-and-ugly mode of the patch, which is the default.) There are only two reasons I can think of that explain a slower pystone: code cache and the switch statement layout. This apparently does not influence my (somewhat high-end-ish) test machines, but does yours (and others.) Both are more or less outside my control. They might be fixed by switch reordering or rearranging of the code so the compiler optimizes it better, but that's very platform specific and lacking a proper test-bed for that situation, I can't do it. Alternatively, there may be some funk with regards to bytecode version. If bytecode wasn't properly regenerated, I can imagine not seeing *any* speedup. Have you tried something as simple as ./python timeit.py -s 'class X:' -s ' def spam(self): pass' -s 'x = X()' 'x.spam()' ? This gives a good 30% speedup on my home PC. Bytecode problems wouldn't influence pystone though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 20:42 Message: Logged In: YES user_id=6380 Alas, like others, I see a tiny slowdown on pystone (maybe 3 percent). This is with the default version of patch version 4 (fixed). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:48 Message: Logged In: YES user_id=34209 Oops, that patch contained a C++-ism, ceval.c:3504 and 3505 needed to be swapped. Uploaded a new version. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all .() occurances. What and are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where resulted in an (old-style) instance, and one where resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 02:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 02:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 01:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-26 00:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Wed Apr 23 13:03:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 05:03:10 -0700 Subject: [Patches] [ python-Patches-726204 ] help() with readline support Message-ID: Patches item #726204, was opened at 2003-04-23 16:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726204&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: help() with readline support Initial Comment: This is a small patch to the Lib/pydoc.py implementing command line editing capabilities (and optional readline support) for the help() builtin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726204&group_id=5470 From noreply@sourceforge.net Wed Apr 23 18:28:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 10:28:59 -0700 Subject: [Patches] [ python-Patches-685051 ] fix for 680789: reprs in arraymodule Message-ID: Patches item #685051, was opened at 2003-02-11 20:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: logistix (logistix) Assigned to: Raymond Hettinger (rhettinger) Summary: fix for 680789: reprs in arraymodule Initial Comment: arraymodule's repr used "string += ',' + el" for each element in the array. Lists and dicts did a string.join to build the repr. Attached patch builds a tuple of array elements and then joins them. This fixes the time issue, but I don't know enough about how you guys manage memory in each case to tell what impact that'll have on really, really big arrays (although I imagine it takes more memory). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 12:28 Message: Logged In: YES user_id=80475 I substantially re-worked and simplifed the patch and have applied it as: arraymodule 2.87 Thanks for addressing the bug report. Otherwise, this might not have gotten done for Py2.3. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-02-22 15:41 Message: Logged In: YES user_id=699438 As I learn more about the sizeof PyObjects, I don't really like my last patch. It creates too many intermediate PyObjects at at the same time. This patch uses two passes to build the repr, reducing the number of temporary PyObjects at any given time to 4 or five, instead of len(array) + 5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 From noreply@sourceforge.net Wed Apr 23 19:04:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 11:04:35 -0700 Subject: [Patches] [ python-Patches-685051 ] fix for 680789: reprs in arraymodule Message-ID: Patches item #685051, was opened at 2003-02-11 19:45 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: logistix (logistix) Assigned to: Raymond Hettinger (rhettinger) Summary: fix for 680789: reprs in arraymodule Initial Comment: arraymodule's repr used "string += ',' + el" for each element in the array. Lists and dicts did a string.join to build the repr. Attached patch builds a tuple of array elements and then joins them. This fixes the time issue, but I don't know enough about how you guys manage memory in each case to tell what impact that'll have on really, really big arrays (although I imagine it takes more memory). ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2003-04-23 13:04 Message: Logged In: YES user_id=699438 Did you look at the second patch I posted? My concern is that the intermediate list temporarily requires an extra 'sizeof(PyObject) x len(array)', instead of 'sizeof (int/char/whatever) x len(array)' to do a repr now. This is a pretty big multiple, right? Current patch is fine with me if it's fine with you. Just wanted to bring it up. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 12:28 Message: Logged In: YES user_id=80475 I substantially re-worked and simplifed the patch and have applied it as: arraymodule 2.87 Thanks for addressing the bug report. Otherwise, this might not have gotten done for Py2.3. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-02-22 14:41 Message: Logged In: YES user_id=699438 As I learn more about the sizeof PyObjects, I don't really like my last patch. It creates too many intermediate PyObjects at at the same time. This patch uses two passes to build the repr, reducing the number of temporary PyObjects at any given time to 4 or five, instead of len(array) + 5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 From noreply@sourceforge.net Wed Apr 23 19:11:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 11:11:46 -0700 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-25 18:16 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 14:11 Message: Logged In: YES user_id=6380 A suggestion: put some static global counters in the new code that count how many times each of the significant branches are taken, and a little routine that prints out the counts on exit. Then people can run various benchmarks and report the numbers, and that may help you decide which paths are worth more work... ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-23 07:43 Message: Logged In: YES user_id=34209 I'd not be proud in any case; neither the concept nor most of the implementation was my idea :-) But my questions still stand; the 3% slowdown in pystone is a lot if all you see is a 1.5% gain in Zope3 startup time, but I can't think of any ways to fix that before next friday, or before 2.3 is released. (The problem is either code size or switch length, which can be 'fixed' by culling code, re-ordering the switch again or changing the switch into a computed-goto.) And I'd need to find me a machine with less cache to actually notice the slowdown :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 08:38 Message: Logged In: YES user_id=6380 However, you should be proud of yourself nevertheless. On the same Zope3 startup "benchmark", Raymond Hettinger's bytecode optimizations scored 0% improvement. Python -O didn't make any difference either. So it's a touch benchmark! (And yes, I did remove the .pyc/.pyo files each time.) (And no, I can't test -OO because Zope uses the docstrings.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 08:20 Message: Logged In: YES user_id=6380 OK, I did a more realistic benchmark: startup time of Zope3. With more or less current CVS Python 2.3 (but not Raymond H's bytecode optimizations), it took 3.52 seconds. With your patch (and all .pyc files rebuilt) it took 3.47 seconds. That's about a percent and a half. (With Python 2.2 it took 4.08 seconds.) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-21 18:48 Message: Logged In: YES user_id=34209 Pystone is not likely to show much speedup, as it contains exactly 2 instances of CALL_ATTR, only barely in the main loop. However, it should not slow down because of CALL_ATTR either; the two CALL_ATTRs are of the most optimized sort, old-style instance methods, and none of the other code paths have changed *at all* (in the fast-and-ugly mode of the patch, which is the default.) There are only two reasons I can think of that explain a slower pystone: code cache and the switch statement layout. This apparently does not influence my (somewhat high-end-ish) test machines, but does yours (and others.) Both are more or less outside my control. They might be fixed by switch reordering or rearranging of the code so the compiler optimizes it better, but that's very platform specific and lacking a proper test-bed for that situation, I can't do it. Alternatively, there may be some funk with regards to bytecode version. If bytecode wasn't properly regenerated, I can imagine not seeing *any* speedup. Have you tried something as simple as ./python timeit.py -s 'class X:' -s ' def spam(self): pass' -s 'x = X()' 'x.spam()' ? This gives a good 30% speedup on my home PC. Bytecode problems wouldn't influence pystone though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 14:42 Message: Logged In: YES user_id=6380 Alas, like others, I see a tiny slowdown on pystone (maybe 3 percent). This is with the default version of patch version 4 (fixed). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 18:48 Message: Logged In: YES user_id=34209 Oops, that patch contained a C++-ism, ceval.c:3504 and 3505 needed to be swapped. Uploaded a new version. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 18:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all .() occurances. What and are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where resulted in an (old-style) instance, and one where resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-17 20:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-17 20:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-17 19:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-25 18:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply@sourceforge.net Wed Apr 23 19:22:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 11:22:38 -0700 Subject: [Patches] [ python-Patches-725904 ] Minor changes to logging Message-ID: Patches item #725904, was opened at 2003-04-22 18:37 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Open Resolution: Accepted Priority: 7 Submitted By: Vinay Sajip (vsajip) Assigned to: Neal Norwitz (nnorwitz) Summary: Minor changes to logging Initial Comment: __init__.py: 1. Updated version number to 0.4.8 and status to beta. handlers.py: 1. Replaced explicit Python version check with hasattr to determine the running Python's capability. 2. Added Date: header to SMTPHandler 3. Changed HTTPHandler to allow more flexible mapping of a LogRecord to a dictionary to be urlencoded. Regression test ran OK on my system after these changes were made. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 14:22 Message: Logged In: YES user_id=6380 If adding a small sleep to the code "fixes" the problem, there is still a more fundamental problem with the tests. Vinaj, can you look into this? Do you understand the issue? I wonder if maybe the tests shouldn't be thread-based at all. It is okay if this doesn't get resolved before the b1 release; there will be a b2 release a month later. (As long as it doesn't require API changes -- bugfixes or changes to the test suite are okay though.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-22 23:52 Message: Logged In: YES user_id=33168 Checked in as: * Lib/logging/__init__.py: 1.9 * Lib/logging/handlers.py: 1.6 I still have the test failure problem. It's more consistent on Redhat 9. Adding a time.sleep(.1) to the test as the first statement in the finally: in test_main() (line 458) "fixes" the problem. Although this is a hack that I don't want to check in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:29 Message: Logged In: YES user_id=6380 Unassigning and accepting; someone else please apply this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 From noreply@sourceforge.net Wed Apr 23 19:27:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 11:27:59 -0700 Subject: [Patches] [ python-Patches-685051 ] fix for 680789: reprs in arraymodule Message-ID: Patches item #685051, was opened at 2003-02-11 20:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: logistix (logistix) Assigned to: Raymond Hettinger (rhettinger) Summary: fix for 680789: reprs in arraymodule Initial Comment: arraymodule's repr used "string += ',' + el" for each element in the array. Lists and dicts did a string.join to build the repr. Attached patch builds a tuple of array elements and then joins them. This fixes the time issue, but I don't know enough about how you guys manage memory in each case to tell what impact that'll have on really, really big arrays (although I imagine it takes more memory). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 13:27 Message: Logged In: YES user_id=80475 Yes. I worked through your second patch and fixed a couple of minor errors (old_sz was declared or set). Then, I tested and timed it. The code had enough complexity that it took over an hour to prove that it worked and had no other hidden bugs. That presents a bit of a maitainability issue. My abbreviated approach solved the quadratic time problem but does consume a memory multiple beyond your version. Ordinarily, that isn't an issue were worry about, but I presume that the reason someone is using the array module is that they have space constraints. This string representation itself is going to be much larger than the array object (a four byte long, takes ten digits plus a space and a comma). The question is whether there is a use case for repr() instead of tofile() or tostring() in a situation where there is just enough memory for the array object and it's string representation but not enough for an intermediate list object. If you think it is critical, we can apply the fixed-up version of your patch. But think carefully about whether it is worth the code complexity, maintainability challenges, increased coupling, and the duplication of list.repr code. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-04-23 13:04 Message: Logged In: YES user_id=699438 Did you look at the second patch I posted? My concern is that the intermediate list temporarily requires an extra 'sizeof(PyObject) x len(array)', instead of 'sizeof (int/char/whatever) x len(array)' to do a repr now. This is a pretty big multiple, right? Current patch is fine with me if it's fine with you. Just wanted to bring it up. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 12:28 Message: Logged In: YES user_id=80475 I substantially re-worked and simplifed the patch and have applied it as: arraymodule 2.87 Thanks for addressing the bug report. Otherwise, this might not have gotten done for Py2.3. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-02-22 15:41 Message: Logged In: YES user_id=699438 As I learn more about the sizeof PyObjects, I don't really like my last patch. It creates too many intermediate PyObjects at at the same time. This patch uses two passes to build the repr, reducing the number of temporary PyObjects at any given time to 4 or five, instead of len(array) + 5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 From noreply@sourceforge.net Wed Apr 23 19:33:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 11:33:25 -0700 Subject: [Patches] [ python-Patches-658316 ] skips.txt for regrtest.py Message-ID: Patches item #658316, was opened at 2002-12-24 15:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658316&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Brett Cannon (bcannon) Summary: skips.txt for regrtest.py Initial Comment: As I promised on python-dev here is the functionality to have a skips.txt file for regrtest.py. If the file is present in the current directory it is parsed (using the exact same code as used for the -f option for regrtest; good, old copy-n-paste) and all tests are added to the expected skip set. And as commented in the file, the name of the file is so named after Skip Montanaro because he is too shy. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 13:33 Message: Logged In: YES user_id=80475 It is time to exercise your new commit priviledges. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 16:15 Message: Logged In: YES user_id=21627 Raymond, any further comments? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-12-29 20:37 Message: Logged In: YES user_id=357491 Oops. =) New diff includes a paragraph at the end of the module documentation that mentions how to use the new functionality. Please delete the old diff. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-29 00:09 Message: Logged In: YES user_id=80475 The patch looks good. Now, it needs documentation. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-12-26 16:04 Message: Logged In: YES user_id=357491 Sorry about that! I could have sworn I checked the box. I have uploaded enough files here you would think it would be habitual by now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 13:10 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658316&group_id=5470 From noreply@sourceforge.net Wed Apr 23 20:09:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 12:09:50 -0700 Subject: [Patches] [ python-Patches-658327 ] Add inet_pton and inet_ntop to socket Message-ID: Patches item #658327, was opened at 2002-12-24 16:00 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) >Assigned to: Guido van Rossum (gvanrossum) Summary: Add inet_pton and inet_ntop to socket Initial Comment: Patch is against current CVS and adds two socket module functions, inet_pton and inet_ntop. Both of these should be available on all platforms (because of other dependancies in the code) so I don't think portability is a problem. inet_ntop converts a packed IP address to a human-readable '.' or ':' separated string representation of the IP. inet_pton performs the reverse operation. (Potential) problems: inet_pton sets errno to ENOSPC, which may lead to a confusing error message. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 15:09 Message: Logged In: YES user_id=6380 Close. The tests however fail on platforms where inet_pton etc. aren't defined. The docs should say that this is not available on all platforms (and in particular not on Windows). ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-04-19 14:14 Message: Logged In: YES user_id=366566 Once again I've screwed up and uploaded the wrong .diff. Here is the correct one, which I just applied to a clean CVS checkout and ran the regression tests for, just to be sure. One test does fail (test_tzset), but also fails on a clean CVS checkout. Additionally, as a correct to my last post, has_ipv6 is set based on the definition of IPV6_ENABLED, not HAVE_INET_PTON. My apologies for your wasted time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 13:53 Message: Logged In: YES user_id=6380 I reject this patch on account of the fact that it clearly hasn't been tested: there's a call to memset() with 2 instead of 3 arguments. Given this lack of care I'm lowering the priority. Also note that there was a patch to test_heapq.py in the patch set. Poster is free to submit a new patch, but I can't guarantee that it'll make it into 2.3b1. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-04-19 13:28 Message: Logged In: YES user_id=366566 Based on the discussion, I've uploaded a new version of the patch. This one does the following: if HAVE_INET_PTON is defined, has_ipv6 is added to the socket module as True, socket_inet_pton and socket_inet_ntop are defined and added to the module, and use the underlying functions to perform the work, only AF_INET and AF_INET6 are supported and where appropriate, input lengths are checked against in_addr and in6_addr. Otherwise, has_ipv6 is added to the socket module as False and no other changes are made. No checks against IPV6_ENABLED are made, because AF_INET6 is always defined and only the platform functions are used to handle values passed to the functions. The patch also updates libsocket.tex, ACKS, NEWS, the socket.py module docstring, and adds tests for inet_pton, inet_ntop, inet_ntoa, and inet_aton to test_socket. Guido, I'm assigning this to you as per your suggestions on python-dev, and because Neal has told me in private correspondance that he doesn't think he'll have a chance to get to it before 2.3b1 comes out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-04 02:05 Message: Logged In: YES user_id=21627 My two suggestions aren't exclusive: If you have the native inet_pton, you can *always* support IPv6 addresses with that, regardless of whether --enable-ipv6 was passed to configure or not. If that is done, it will be a legitime test failure for inet_pton not to support IPv6 - after all, the primary reason to define this function was to support IPv6, so if the native function fails to do so, there is clearly a bug in the system. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 22:41 Message: Logged In: YES user_id=33168 I added the #ifdef, but that doesn't address the testing problem. If the platform has inet_pton, but doesn't have IPv6 ENABLED. The inet_pton will be exported, but there's no good way to tell if you can pass an IPv6 address. The only way to test if IPv6 is enabled would be to call inet_pton with AF_INET6, catch a socket.error and check if the exception message is "unknown address family". Since this is really a testing issue, perhaps that's best after all? Do you agree this should be done? * Remove has_ipv6 * Export inet_pton & inet_ntop only if defined for platform * Only try to test inet_pton/ntop if defined for platform * Modify the tests to pass a valid IPv6 test, catch socket.error, if the error message is "unknown address family", don't test ipv6 any further, if the error message is different, raise TestFailed, if no exception, test all IPv6 addresses ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 17:25 Message: Logged In: YES user_id=33168 As I recall, yes, has_ipv6 is only for tests. There was no way to distinguish if python was built with IPv6 support, since AF_INET6 was always defined. Your second approach sounds like it will work. I need to review the code, though. I've forgotten how it works. :-( ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 05:15 Message: Logged In: YES user_id=21627 The has_ipv6 test is only there for the tests? In that case, drop it, and just perform AF_INET6 conversions unconditionally. OTOH, I think we should not expose the emulated inet_pton: it doesn't set errno correctly, and offers no advantage over inet_addr. So wrap the entire code with HAVE_INET_PTON, and only perform the tests if the function is supported. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 21:40 Message: Logged In: YES user_id=33168 I was just about to check this in, but then I ran into a problem. IPv6 may not be enabled, even if the constant AF_INET6 exists. The cleanest way I saw to address this in the test was to add a has_ipv6 boolean constant to the socket module. Martin, do you think this is acceptable? Attached is a complete patch which should be safe (based on the discussion below), includes tests and doc changes. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:04 Message: Logged In: YES user_id=366566 Yea, testing for the proper input length is definitely something that should be done. The patch looks good, but for one thing. If the specified address family is neither AF_INET nor AF_INET6, the length won't be tested and the underlying inet_ntop will be called. This isn't a problem now (afaik) because only those two address families are support, but in a future libc version with more supported address families, it might open a similar hole to the one you've fixed. Perhaps the + } else { + PyErr_SetString(socket_error, "unknown address family"); + return NULL; + } should be moved up from the second if-grouping to follow the first if-grouping. Everything else looks good to me. Thanks for taking the time to look at this :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 22:49 Message: Logged In: YES user_id=33168 JP, do you agree with my comment on 2002-12-30 about the checks? I have attached an updated patch. Please review and verify this is correct. Thank you for the additional tests. Feel free to submit patches with additional tests for any and all modules! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-31 11:52 Message: Logged In: YES user_id=366566 Doc, NEWS, and test_socket patch attached. I didn't notice any inet_aton/inet_ntoa tests in the module so I added a couple for those as well (I excluded a test for inet_ntoa('255.255.255.255') ;) Also included are a couple IPv6 tests. I'm not sure if these are appropriate, since many systems may still lack the required support for them to pass. I'll leave it up to you to decide whether they should be commented out or removed or whatever. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 08:17 Message: Logged In: YES user_id=21627 I agree that such a change should be added. Neal, you have given this patch more attention than I did - please check it in when you consider it complete. I just like to point out that it is missing documentation changes (libsocket.tex), a NEWS entry, and a test case. kuran, please provide those as a single patch file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-30 19:11 Message: Logged In: YES user_id=33168 ISTM that in socket_inet_ntop() you need to verify the size of the packed value passed in. If the user passes an empty string, inet_ntop() could read beyond the buffer passed in, potentially causing a core dump. The checks could be something like this: if (af == AF_INET && len != sizeof(struct in_addr)) else if (af == AF_INET6 && len != sizeof(struct in6_addr)) Do this make sense? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-27 10:39 Message: Logged In: YES user_id=366566 The use case I have for it at the moment is a DNS server (Twisted.names). inet_pton allows me to handle IPv6 addresses, so it allows me to support AAAA and A6 records. I believe an IPv6 capable socks proxy would find this useful as well. Basically, low level network stuff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-27 05:23 Message: Logged In: YES user_id=21627 What is the rationale for providing this functionality? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-26 13:32 Message: Logged In: YES user_id=366566 Ooops, I made two, and uploaded the wrong one >:O Sorry. Dunno if it's still helpful, but here's the unified diff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 13:10 Message: Logged In: YES user_id=33168 Next time, please use context or unified diff. -c or -u option to cvs diff: cvs diff -c ... ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-24 16:05 Message: Logged In: YES user_id=366566 Sourceforge decided not to attach the file the first time... Here it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 From noreply@sourceforge.net Wed Apr 23 21:33:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 13:33:47 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 22:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 13:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-15 01:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 14:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 11:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Wed Apr 23 22:00:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 14:00:34 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 17:00 Message: Logged In: YES user_id=6380 I suggest not to mess with unittest.py; it is still externally maintained as PyUnit. Maybe ask the PyUnit developer. No time to review the test, sorry; if it works, I suggest to just check it in. ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 16:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 07:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-14 19:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 08:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 05:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 05:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 04:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 14:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 10:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 08:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 12:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 08:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-20 22:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 13:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 04:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 15:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 06:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 03:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 13:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 18:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Wed Apr 23 23:27:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 15:27:04 -0700 Subject: [Patches] [ python-Patches-658316 ] skips.txt for regrtest.py Message-ID: Patches item #658316, was opened at 2002-12-24 12:03 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658316&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: skips.txt for regrtest.py Initial Comment: As I promised on python-dev here is the functionality to have a skips.txt file for regrtest.py. If the file is present in the current directory it is parsed (using the exact same code as used for the -f option for regrtest; good, old copy-n-paste) and all tests are added to the expected skip set. And as commented in the file, the name of the file is so named after Skip Montanaro because he is too shy. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-04-23 15:27 Message: Logged In: YES user_id=357491 =) Sure thing. Noticed it was assigned to me and everything. Just need to add one feature; I want it to print out what tests were specifically skipped because of the skips.txt file so people don't forget that they have tests being skipped because of what they have in the file. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 11:33 Message: Logged In: YES user_id=80475 It is time to exercise your new commit priviledges. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 13:15 Message: Logged In: YES user_id=21627 Raymond, any further comments? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-12-29 17:37 Message: Logged In: YES user_id=357491 Oops. =) New diff includes a paragraph at the end of the module documentation that mentions how to use the new functionality. Please delete the old diff. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-28 21:09 Message: Logged In: YES user_id=80475 The patch looks good. Now, it needs documentation. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-12-26 13:04 Message: Logged In: YES user_id=357491 Sorry about that! I could have sworn I checked the box. I have uploaded enough files here you would think it would be habitual by now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 10:10 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658316&group_id=5470 From noreply@sourceforge.net Wed Apr 23 23:46:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 15:46:13 -0700 Subject: [Patches] [ python-Patches-725904 ] Minor changes to logging Message-ID: Patches item #725904, was opened at 2003-04-22 22:37 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 7 Submitted By: Vinay Sajip (vsajip) Assigned to: Neal Norwitz (nnorwitz) Summary: Minor changes to logging Initial Comment: __init__.py: 1. Updated version number to 0.4.8 and status to beta. handlers.py: 1. Replaced explicit Python version check with hasattr to determine the running Python's capability. 2. Added Date: header to SMTPHandler 3. Changed HTTPHandler to allow more flexible mapping of a LogRecord to a dictionary to be urlencoded. Regression test ran OK on my system after these changes were made. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2003-04-23 22:46 Message: Logged In: YES user_id=308438 I can try to look into this, although I don't have access to Red Hat 9. I have limited access to Mandrake 9 and will try to run tests in that environment; I may not be able to reproduce it. I have no problem with simplifying the test - the reason for using threads is to give the logging system a reasonably good workout. test_logging.py is already quite a bit simpler than the test harness I use personally. While the test does create threads, it does seem to follow established practice and there is no obvious (to me) reason for the problem. Resolving this issue should not require a change to the API - if the worst comes to the worst, we can simplify test_logging to do minimal logic tests for logger/handler logic. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 18:22 Message: Logged In: YES user_id=6380 If adding a small sleep to the code "fixes" the problem, there is still a more fundamental problem with the tests. Vinaj, can you look into this? Do you understand the issue? I wonder if maybe the tests shouldn't be thread-based at all. It is okay if this doesn't get resolved before the b1 release; there will be a b2 release a month later. (As long as it doesn't require API changes -- bugfixes or changes to the test suite are okay though.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-23 03:52 Message: Logged In: YES user_id=33168 Checked in as: * Lib/logging/__init__.py: 1.9 * Lib/logging/handlers.py: 1.6 I still have the test failure problem. It's more consistent on Redhat 9. Adding a time.sleep(.1) to the test as the first statement in the finally: in test_main() (line 458) "fixes" the problem. Although this is a hack that I don't want to check in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 00:29 Message: Logged In: YES user_id=6380 Unassigning and accepting; someone else please apply this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 From noreply@sourceforge.net Thu Apr 24 01:32:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 17:32:57 -0700 Subject: [Patches] [ python-Patches-725904 ] Minor changes to logging Message-ID: Patches item #725904, was opened at 2003-04-22 18:37 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 7 Submitted By: Vinay Sajip (vsajip) Assigned to: Neal Norwitz (nnorwitz) Summary: Minor changes to logging Initial Comment: __init__.py: 1. Updated version number to 0.4.8 and status to beta. handlers.py: 1. Replaced explicit Python version check with hasattr to determine the running Python's capability. 2. Added Date: header to SMTPHandler 3. Changed HTTPHandler to allow more flexible mapping of a LogRecord to a dictionary to be urlencoded. Regression test ran OK on my system after these changes were made. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 20:32 Message: Logged In: YES user_id=6380 Vinaj, I suggest that you don't focus on trying to reproduce the problem but study the way you have structured the tests to show to yourself that it *is* possible. Then think about a restructuring that avoids this. E.g. by using an event variable (see the threading module). If that doesn't work for Python 1.5.2, that doesn't matter IMO. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-04-23 18:46 Message: Logged In: YES user_id=308438 I can try to look into this, although I don't have access to Red Hat 9. I have limited access to Mandrake 9 and will try to run tests in that environment; I may not be able to reproduce it. I have no problem with simplifying the test - the reason for using threads is to give the logging system a reasonably good workout. test_logging.py is already quite a bit simpler than the test harness I use personally. While the test does create threads, it does seem to follow established practice and there is no obvious (to me) reason for the problem. Resolving this issue should not require a change to the API - if the worst comes to the worst, we can simplify test_logging to do minimal logic tests for logger/handler logic. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 14:22 Message: Logged In: YES user_id=6380 If adding a small sleep to the code "fixes" the problem, there is still a more fundamental problem with the tests. Vinaj, can you look into this? Do you understand the issue? I wonder if maybe the tests shouldn't be thread-based at all. It is okay if this doesn't get resolved before the b1 release; there will be a b2 release a month later. (As long as it doesn't require API changes -- bugfixes or changes to the test suite are okay though.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-22 23:52 Message: Logged In: YES user_id=33168 Checked in as: * Lib/logging/__init__.py: 1.9 * Lib/logging/handlers.py: 1.6 I still have the test failure problem. It's more consistent on Redhat 9. Adding a time.sleep(.1) to the test as the first statement in the finally: in test_main() (line 458) "fixes" the problem. Although this is a hack that I don't want to check in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:29 Message: Logged In: YES user_id=6380 Unassigning and accepting; someone else please apply this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 From noreply@sourceforge.net Thu Apr 24 03:47:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 19:47:57 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 15:27 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-04-23 19:47 Message: Logged In: YES user_id=357491 OK, docstring is fixed along with the lib docs. Also fixed a couple typos. Also backported to release2.2-maint. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:58 Message: Logged In: YES user_id=6380 Backport to 2.2: yes, but it's just a doc issue. The best way to work with 2.2 if you have the disk space and you already have a trunk checkout: 1) make a copy of your trunk checkout 2) in that copy, do "cvs update -r release22-maint" >From now on, the copy works on the branch. Just remember never to do "cvs update -A" there (this resets the sticky tag to the trunk). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:54 Message: Logged In: YES user_id=6380 Somehow, tracker permissions have to be updated separately, and some of the SF admin screens are not very clear. I've upgraded your permissions in this tracker now! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 17:37 Message: Logged In: YES user_id=357491 Should I also backport this to 2.2? I assume yes, but thought I should double-check (maybe subconsciously I don't want to have to deal with learning how to get a commit correct on a tagged branch =). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 17:35 Message: Logged In: YES user_id=357491 OK, I will fix the docs (both the library docs and the docstring). And I don't know why the hell I am not listed. I still can't delete items off of tracker items that I have created (this was a problem before I became a committer). Guess I need to email SF tech support and see what they say. I will get the docs changed and close this patch (assuming it lets me) as if it was assigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:27 Message: Logged In: YES user_id=6380 Hm, I don't see you in the list of committers? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:25 Message: Logged In: YES user_id=6380 In general fixing the docs is much safet than fixing the code. ;-) If you submit a doc patch here it'll be applied. (Note that the docstring is also lying.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Thu Apr 24 03:48:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Apr 2003 19:48:36 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 15:27 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-04-23 19:48 Message: Logged In: YES user_id=357491 OK, docstring is fixed along with the lib docs. Also fixed a couple typos. Also backported to release2.2-maint. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-23 19:47 Message: Logged In: YES user_id=357491 OK, docstring is fixed along with the lib docs. Also fixed a couple typos. Also backported to release2.2-maint. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:58 Message: Logged In: YES user_id=6380 Backport to 2.2: yes, but it's just a doc issue. The best way to work with 2.2 if you have the disk space and you already have a trunk checkout: 1) make a copy of your trunk checkout 2) in that copy, do "cvs update -r release22-maint" >From now on, the copy works on the branch. Just remember never to do "cvs update -A" there (this resets the sticky tag to the trunk). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:54 Message: Logged In: YES user_id=6380 Somehow, tracker permissions have to be updated separately, and some of the SF admin screens are not very clear. I've upgraded your permissions in this tracker now! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 17:37 Message: Logged In: YES user_id=357491 Should I also backport this to 2.2? I assume yes, but thought I should double-check (maybe subconsciously I don't want to have to deal with learning how to get a commit correct on a tagged branch =). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 17:35 Message: Logged In: YES user_id=357491 OK, I will fix the docs (both the library docs and the docstring). And I don't know why the hell I am not listed. I still can't delete items off of tracker items that I have created (this was a problem before I became a committer). Guess I need to email SF tech support and see what they say. I will get the docs changed and close this patch (assuming it lets me) as if it was assigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:27 Message: Logged In: YES user_id=6380 Hm, I don't see you in the list of committers? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 17:25 Message: Logged In: YES user_id=6380 In general fixing the docs is much safet than fixing the code. ;-) If you submit a doc patch here it'll be applied. (Note that the docstring is also lying.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Thu Apr 24 09:30:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 01:30:34 -0700 Subject: [Patches] [ python-Patches-726751 ] Clarify docs for except target assignment Message-ID: Patches item #726751, was opened at 2003-04-24 01:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726751&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify docs for except target assignment Initial Comment: I have always found the docs dealing with the target as found in 'except' clauses misleading:: try: raise Exception('argument 1') except Exception, x: print type(x) This code outputs ```` while I would have expected ```` from the way the docs read (at least to me). So I tried to clarify this in the tutorial and references (Doc/tut/tut.tex and Doc/ref/ref7.tex respectively). If people think I am nuts and people don't get confused by the fact that having a single target gets the exception instance assigned to it while a tuple of targets gets the exception to unpack its arg values through iterating over them with the way the docs are now, then I guess I am nuts. =) Regardless of the final outcome of this patch, the result will close/ reject bug #675928 . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726751&group_id=5470 From noreply@sourceforge.net Thu Apr 24 09:31:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 01:31:13 -0700 Subject: [Patches] [ python-Patches-726751 ] Clarify docs for except target assignment Message-ID: Patches item #726751, was opened at 2003-04-24 01:30 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726751&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Clarify docs for except target assignment Initial Comment: I have always found the docs dealing with the target as found in 'except' clauses misleading:: try: raise Exception('argument 1') except Exception, x: print type(x) This code outputs ```` while I would have expected ```` from the way the docs read (at least to me). So I tried to clarify this in the tutorial and references (Doc/tut/tut.tex and Doc/ref/ref7.tex respectively). If people think I am nuts and people don't get confused by the fact that having a single target gets the exception instance assigned to it while a tuple of targets gets the exception to unpack its arg values through iterating over them with the way the docs are now, then I guess I am nuts. =) Regardless of the final outcome of this patch, the result will close/ reject bug #675928 . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726751&group_id=5470 From noreply@sourceforge.net Thu Apr 24 12:57:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 04:57:03 -0700 Subject: [Patches] [ python-Patches-725899 ] Cause urllib.urlretrieve() to match docs for local files Message-ID: Patches item #725899, was opened at 2003-04-22 18:27 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Cause urllib.urlretrieve() to match docs for local files Initial Comment: As of right now, urllib.urlretrieve() returns an actual mimetools.Message object for its 'headers' value. Now both the module doc and doc string say that it should be returning None. I have a patch here (all 3 lines of it) to cause urlretrive to match the documentation. But perhaps we should change the docs instead? I have no clue if there is any code out in the wild that relies on the current behavior. I personally say keep the code as it is and fix the docs, but that is just me. I am going to hold off on applying this patch until someone else either agrees with me or I get someone higher up the food chain to tell me I am wrong. I am going to assign this to Guido initially but I can apply the patch myself; just need an answer on this before b1 goes out since this patch changes semantics. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 07:57 Message: Logged In: YES user_id=6380 Very thorough. Thanks! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-23 22:48 Message: Logged In: YES user_id=357491 OK, docstring is fixed along with the lib docs. Also fixed a couple typos. Also backported to release2.2-maint. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-23 22:47 Message: Logged In: YES user_id=357491 OK, docstring is fixed along with the lib docs. Also fixed a couple typos. Also backported to release2.2-maint. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:58 Message: Logged In: YES user_id=6380 Backport to 2.2: yes, but it's just a doc issue. The best way to work with 2.2 if you have the disk space and you already have a trunk checkout: 1) make a copy of your trunk checkout 2) in that copy, do "cvs update -r release22-maint" >From now on, the copy works on the branch. Just remember never to do "cvs update -A" there (this resets the sticky tag to the trunk). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:54 Message: Logged In: YES user_id=6380 Somehow, tracker permissions have to be updated separately, and some of the SF admin screens are not very clear. I've upgraded your permissions in this tracker now! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 20:37 Message: Logged In: YES user_id=357491 Should I also backport this to 2.2? I assume yes, but thought I should double-check (maybe subconsciously I don't want to have to deal with learning how to get a commit correct on a tagged branch =). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-22 20:35 Message: Logged In: YES user_id=357491 OK, I will fix the docs (both the library docs and the docstring). And I don't know why the hell I am not listed. I still can't delete items off of tracker items that I have created (this was a problem before I became a committer). Guess I need to email SF tech support and see what they say. I will get the docs changed and close this patch (assuming it lets me) as if it was assigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:27 Message: Logged In: YES user_id=6380 Hm, I don't see you in the list of committers? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:25 Message: Logged In: YES user_id=6380 In general fixing the docs is much safet than fixing the code. ;-) If you submit a doc patch here it'll be applied. (Note that the docstring is also lying.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725899&group_id=5470 From noreply@sourceforge.net Thu Apr 24 13:38:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 05:38:30 -0700 Subject: [Patches] [ python-Patches-679505 ] Deprecate rotor module Message-ID: Patches item #679505, was opened at 2003-02-03 09:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679505&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 4 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Deprecate rotor module Initial Comment: Here's a trivial patch that marks the rotor module as deprecated. To be used if Paul Rubin's AES module goes into 2.3 (maybe even if it doesn't). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-04-24 08:38 Message: Logged In: YES user_id=11375 Marking as accepted based on GvR's say-so. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 06:39 Message: Logged In: YES user_id=21627 I retract my comment, the rationale is fine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 06:37 Message: Logged In: YES user_id=21627 What is the rationale for deprecating the rotor module? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-03 09:04 Message: Logged In: YES user_id=11375 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679505&group_id=5470 From noreply@sourceforge.net Thu Apr 24 14:09:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 06:09:01 -0700 Subject: [Patches] [ python-Patches-726869 ] special-case recursion limit for gcc 3.x on FreeBSD & OS/2 Message-ID: Patches item #726869, was opened at 2003-04-24 23:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726869&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Gustavo Niemeyer (niemeyer) Summary: special-case recursion limit for gcc 3.x on FreeBSD & OS/2 Initial Comment: gcc 3.2.2 on FreeBSD (autoconf default -O3) and gcc 3.2.1(EMX port default -O2) generates code for _sre.c that fails catastrophically for the normal recursion limit (10000). Some 64 bit systems are already special-cased to a recursion limit of 7500, for apparently similar reasons. I elected to use a separate #if branch to keep the 64bit systems separate from the gcc issues, which are specific to certain systems for unknown reasons. At one point, gcc 2.95.3 on FreeBSD was also having the same effect, however recent fixes appear to have alleviated that. Assigned to Gustavo, as he's been working on _sre. Supercedes #725024, which I'll close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726869&group_id=5470 From noreply@sourceforge.net Thu Apr 24 14:12:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 06:12:02 -0700 Subject: [Patches] [ python-Patches-725024 ] adjust optimisation to deal with bus errors on FreeBSD Message-ID: Patches item #725024, was opened at 2003-04-22 01:10 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725024&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: adjust optimisation to deal with bus errors on FreeBSD Initial Comment: Since checkin of patch #720991 on April 14, I've not been able to run test_sre (or test_re) on a 2.3-CVS built on FreeBSD 4.7 (gcc 2.95.4, using autoconf default -O3) without getting a bus error. Using less aggressive optimisation works around the issue. I can reproduce the problem with gcc 2.95.3 on FreeBSD 4.4, gcc 3.2.2 on FreeBSD 4.7 built from the FreeBSD ports system, and gcc 3.2.1 for OS/2+EMX. I'm not in a position to do a full investigation of the issue, so I've prepared the attached patch to configure.in which lowers the optimisation for gcc on FreeBSD. For gcc 2.95.x, dropping the optimisation to -O2 is sufficient to get a Python interpreter which doesn't fail test_sre with a bus error. This compiler is the default compiler for FreeBSD 4.x. This change is reduces performance on a VIA C3 800MHz system by about 3-4% (both pystone and pybench) For gcc 3.2.x, the optimisation has to be dropped to -Os for test_sre to pass without a bus error. This compiler is the default compiler for FreeBSD 5.0. On a VIA C3 800MHz system running FreeBSD 4.7, this change reduces performance by 6-7.5% (6% pybench, 7.5% pystone). The EMX port does not use autoconf. Caveats: - I don't yet have a FreeBSD 5.0 system, but have based this patch on the assumption that the 5.0 system compiler will be configured with the same specs as the FreeBSD ports configuration, and therefore have the same behaviour. - a less intrusive workaround would be to only lower optimisation for the affected file (Modules/_sre.c), however that seems impossible with autoconf. - there appear to be no reports of similar issues for gcc on Linux, so I've assumed that the problem is specific to how FreeBSD configures the compilers and/or binutils. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-24 23:12 Message: Logged In: YES user_id=250749 A better solution was found: special case the recursion limit in _sre.c for gcc 3.x on the affected platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725024&group_id=5470 From noreply@sourceforge.net Thu Apr 24 14:15:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 06:15:09 -0700 Subject: [Patches] [ python-Patches-725024 ] adjust optimisation to deal with bus errors on FreeBSD Message-ID: Patches item #725024, was opened at 2003-04-22 01:10 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725024&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: adjust optimisation to deal with bus errors on FreeBSD Initial Comment: Since checkin of patch #720991 on April 14, I've not been able to run test_sre (or test_re) on a 2.3-CVS built on FreeBSD 4.7 (gcc 2.95.4, using autoconf default -O3) without getting a bus error. Using less aggressive optimisation works around the issue. I can reproduce the problem with gcc 2.95.3 on FreeBSD 4.4, gcc 3.2.2 on FreeBSD 4.7 built from the FreeBSD ports system, and gcc 3.2.1 for OS/2+EMX. I'm not in a position to do a full investigation of the issue, so I've prepared the attached patch to configure.in which lowers the optimisation for gcc on FreeBSD. For gcc 2.95.x, dropping the optimisation to -O2 is sufficient to get a Python interpreter which doesn't fail test_sre with a bus error. This compiler is the default compiler for FreeBSD 4.x. This change is reduces performance on a VIA C3 800MHz system by about 3-4% (both pystone and pybench) For gcc 3.2.x, the optimisation has to be dropped to -Os for test_sre to pass without a bus error. This compiler is the default compiler for FreeBSD 5.0. On a VIA C3 800MHz system running FreeBSD 4.7, this change reduces performance by 6-7.5% (6% pybench, 7.5% pystone). The EMX port does not use autoconf. Caveats: - I don't yet have a FreeBSD 5.0 system, but have based this patch on the assumption that the 5.0 system compiler will be configured with the same specs as the FreeBSD ports configuration, and therefore have the same behaviour. - a less intrusive workaround would be to only lower optimisation for the affected file (Modules/_sre.c), however that seems impossible with autoconf. - there appear to be no reports of similar issues for gcc on Linux, so I've assumed that the problem is specific to how FreeBSD configures the compilers and/or binutils. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-24 23:15 Message: Logged In: YES user_id=250749 patch #726869 implements the better solution ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-04-24 23:12 Message: Logged In: YES user_id=250749 A better solution was found: special case the recursion limit in _sre.c for gcc 3.x on the affected platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725024&group_id=5470 From noreply@sourceforge.net Thu Apr 24 14:24:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 06:24:02 -0700 Subject: [Patches] [ python-Patches-679505 ] Deprecate rotor module Message-ID: Patches item #679505, was opened at 2003-02-03 09:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679505&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Deprecate rotor module Initial Comment: Here's a trivial patch that marks the rotor module as deprecated. To be used if Paul Rubin's AES module goes into 2.3 (maybe even if it doesn't). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-04-24 09:24 Message: Logged In: YES user_id=11375 Checked in. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-04-24 08:38 Message: Logged In: YES user_id=11375 Marking as accepted based on GvR's say-so. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 06:39 Message: Logged In: YES user_id=21627 I retract my comment, the rationale is fine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 06:37 Message: Logged In: YES user_id=21627 What is the rationale for deprecating the rotor module? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-03 09:04 Message: Logged In: YES user_id=11375 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679505&group_id=5470 From noreply@sourceforge.net Thu Apr 24 16:02:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 08:02:20 -0700 Subject: [Patches] [ python-Patches-713428 ] Fixes for 'commands' module on win32 Message-ID: Patches item #713428, was opened at 2003-04-01 19:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Warnes (warnes) Assigned to: Martin v. Löwis (loewis) Summary: Fixes for 'commands' module on win32 Initial Comment: Currently the 'commands' module is provided with python on Win32 systems, but does not function properly. (The library reference says it is only available on Unix). The commands module provides 3 functions: getoutput(cmd) returns output generated by executing 'cmd' in a shell getstatusoutput(cmd) returns (status,output) generated by executing 'cmd' in a shell getstatus(file) returns output of "ls -ld file" Below is a simple patch which enables 'getoutput' and 'getstatusoutut' to work properly on Win32. Since 'getstatusfile' only makes sense on Unix, the patch prevents it from being defined on Win32. The current behavior is maintained on all other platforms. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-04-24 17:02 Message: Logged In: YES user_id=21627 Apparently, you did not check the checkbox. Can you please retry? ---------------------------------------------------------------------- Comment By: Gregory Warnes (warnes) Date: 2003-04-10 06:50 Message: Logged In: YES user_id=9316 Uploaded a revised patch file, as requested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-08 08:02 Message: Logged In: YES user_id=21627 Can you please resubmit this as a unified diff? Also, please make sure you don't incude white-space only changes: Your patch says that it changes all lines, just because you add a CR at the end of every line (so either convert the modified file to Unix conventions, or the original file to Windows conventions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470 From noreply@sourceforge.net Thu Apr 24 16:51:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 08:51:30 -0700 Subject: [Patches] [ python-Patches-695710 ] fix bug 678519: cStringIO self iterator Message-ID: Patches item #695710, was opened at 2003-03-01 14:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695710&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: fix bug 678519: cStringIO self iterator Initial Comment: StringIO.StringIO already appears to be a self-iterator. This patch makes cStringIO.StringIO a self-iterator as well. It also does a tiny bit of cleanup to cStringIO. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 10:51 Message: Logged In: YES user_id=80475 Committed as: Modules\cStringIO.c 2.40 Lib\test\test_StringIO.py 1.15 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-19 16:27 Message: Logged In: YES user_id=33168 I don't think it's impolite. I'll try to take a look later, unless someone beats me to it. :-) ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-03-19 16:17 Message: Logged In: YES user_id=670441 Okay, patchstrio4 uses PyObject_SelfIter and doesn't have as much of my prettification, so there aren't any whitespace-only diff lines. (I think) Should I assign this patch to either Neal or MvL for further review, or would that be impolite? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-19 14:54 Message: Logged In: YES user_id=80475 It looks good to me, compiles okay, passes tests, etc. I do prefer that you get one more reviewer to look at it. Neal or MvL might be a good choice. GvR picked PyObject_SelfIter to be the name of the iterator's tp_iter slot filler. So you can go ahead and use it to eliminate IO_getiter. One nit, when you load the next patch, copy in the unchanged lines from the original. There are many lines marked as having a change but the content is the same. This means that something changed in the whitespace. It's not big deal but it makes the patch harder to review. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-03-19 13:39 Message: Logged In: YES user_id=670441 I'm not sure I understand your concern with the new tp_iter slot, it just makes cStringIO a self iterator as requested on python-dev, going for the analogy with file objects, right? Actually it should probably use the still-being-debated GenericGetIter or whatever it will be called, but not until the debate is over. I think the get/setattrs are okay. Everything they did is done by the default get/set attrs, once we set up the appropriate methods and members (there's just the one member, softspace). I thought replacing them by the defaults would be clearer and easier to maintain. Also, it is in analogy with fileobject.c, so I thought making the cStringIO implementation more like file's would be good. As for the creating a new tuple every time and the 0,0,0,0 style, you're absolutely right, I've attached a new patch that fixes those up per your suggestions. I was creating a new tuple every time in analogy with iterobject.c's calliter_iternext. Perhaps that should be changed as well? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-17 19:55 Message: Logged In: YES user_id=80475 I'm going to unassign this one because the patch makes me uncomfortable. The tp_iter slot was already filled in a way that is reasonable and the new code doesn't seem to be an improvement. If you go ahead with it, carefully consider whether some negative effects can arise from eliminating the get/setattrs. Also, the call to readline should avoid creating a new empty tuple on each call (either make a single one and re-use it everytime or alter readline to accept a NULL for args). The 0,0,0,0,0,0,0 style in the type definition should be spelled-out line by line so that it is maintainable and is consistent with other modules. All that being said, the test cases were nice and code runs flawlessly. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-03-11 21:35 Message: Logged In: YES user_id=670441 I prefer that too, but I can't attach patches to existing bug reports in sourceforge, only to bug reports or patches I open myself. Nor can I delete patches I have attached if I don't like them. Actually, the advice I read somewhere or other (python.org developer faq?) recommends opening a separate patch all the time, but I'd rather be able to put them with the bug reports. I used to paste patches directly into the text of a message, but this is only good for extremely short patches on sourceforge. When doing that I noticed that patches for old bugs that haven't been discussed in a few months tend to get ignored, which is another plus for opening a separate patch. (There seem to be several very old bugs which have solutions attached or discussion indicates they should be closed) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 20:44 Message: Logged In: YES user_id=80475 I don't know about the other reviewers but I prefer that the patches be attached to the original bug instead on a new patch tracker on SF. This makes it easier to follow the dialogue on this issue. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-03-05 17:16 Message: Logged In: YES user_id=670441 patchcstrio2 is a better version, more cleaned up. Use it instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695710&group_id=5470 From noreply@sourceforge.net Thu Apr 24 17:07:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 09:07:45 -0700 Subject: [Patches] [ python-Patches-713428 ] Fixes for 'commands' module on win32 Message-ID: Patches item #713428, was opened at 2003-04-01 12:51 Message generated for change (Comment added) made by warnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Warnes (warnes) Assigned to: Martin v. Löwis (loewis) Summary: Fixes for 'commands' module on win32 Initial Comment: Currently the 'commands' module is provided with python on Win32 systems, but does not function properly. (The library reference says it is only available on Unix). The commands module provides 3 functions: getoutput(cmd) returns output generated by executing 'cmd' in a shell getstatusoutput(cmd) returns (status,output) generated by executing 'cmd' in a shell getstatus(file) returns output of "ls -ld file" Below is a simple patch which enables 'getoutput' and 'getstatusoutut' to work properly on Win32. Since 'getstatusfile' only makes sense on Unix, the patch prevents it from being defined on Win32. The current behavior is maintained on all other platforms. ---------------------------------------------------------------------- >Comment By: Gregory Warnes (warnes) Date: 2003-04-24 12:07 Message: Logged In: YES user_id=9316 2nd attempt to upload fixed patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-24 11:02 Message: Logged In: YES user_id=21627 Apparently, you did not check the checkbox. Can you please retry? ---------------------------------------------------------------------- Comment By: Gregory Warnes (warnes) Date: 2003-04-10 00:50 Message: Logged In: YES user_id=9316 Uploaded a revised patch file, as requested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-08 02:02 Message: Logged In: YES user_id=21627 Can you please resubmit this as a unified diff? Also, please make sure you don't incude white-space only changes: Your patch says that it changes all lines, just because you add a CR at the end of every line (so either convert the modified file to Unix conventions, or the original file to Windows conventions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470 From noreply@sourceforge.net Thu Apr 24 18:54:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Apr 2003 10:54:21 -0700 Subject: [Patches] [ python-Patches-652980 ] Generator form of os.path.walk Message-ID: Patches item #652980, was opened at 2002-12-12 17:29 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=652980&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Edward C. Jones (edcjones) Assigned to: Nobody/Anonymous (nobody) Summary: Generator form of os.path.walk Initial Comment: Generator yielding "top" and all files and directories under it (except "." and ".."). "walk2" is much easier to use than "walk" but lacks its flexibility. The generator does a top-down traversal of the directory tree. Unlike "walk", "walk2" raises an exception if top does not exist. It is easy to modify the code to return only files or only directories. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 13:54 Message: Logged In: YES user_id=6380 Rejected this patch. Instead, we should use Tim's code and call it os.walk(). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-13 05:41 Message: Logged In: YES user_id=21627 I would recommend to put this into the Cookbook for now. Actually, it's already there: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/ 105873 and http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/ 161542 I like the second snippet best, as it avoids building recursive generators. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/ 52664 is similar: you can also iterate over the files, but it computes a list, instead of being a generator. I like that it allows to do globbing while it traverses. For a Python patch, this is incomplete: It ought to patch all copies of the path module, and it ought to provide documentation (and perhaps test cases). Please use unified or context diffs. As I said on python-dev, I'm -1 unless it also provides support for file types (i.e. it should return (filename, filetype) pairs, instead of returning file names). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-12 18:58 Message: Logged In: YES user_id=80475 The upload didn't make it. Try resubmitting the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=652980&group_id=5470 From noreply@sourceforge.net Fri Apr 25 11:03:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 03:03:09 -0700 Subject: [Patches] [ python-Patches-725569 ] Improved output for unittest failUnlessEqual Message-ID: Patches item #725569, was opened at 2003-04-22 12:33 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Duncan Booth (duncanb) Assigned to: Nobody/Anonymous (nobody) Summary: Improved output for unittest failUnlessEqual Initial Comment: The failUnlessEqual method in unittest.TestCase doesn't handle well the case where the objects being compared have a long string representation. The whole repr for each object is printed no matter how long, and no indication is given of where any differences occur. This patch uses difflib on long representations to provide a short output that highlights where the first difference actually is. It also limits the output for each value to fit on a single line (with the differences indicated on the line following). e.g. FAIL: test_failunlessEqual4 (__main__.Test) ---------------------------------------------------------------------- TestFailed: failUnlessEqual {'A': 65, 'C': 67, ...0, 'P ': 0, 'R': 82, 'U': 85, 'T': 84, 'W': 87, 'V': 8... ... ^^ ^ ... {'A': 65, 'C': 67, ...0, 'S': 83, 'R': 82, 'U': 85, 'T': 84, 'W': 87, 'V': 8... ... ^ ^^ ... File "F:\temp\test.py", line 59, in test_failunlessEqual4 self.failUnlessEqual(d2, d1) ---------------------------------------------------------------------- The attached file contains the changes, assuming that patch "722638 Better output for unittest" has already been applied. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-04-25 12:03 Message: Logged In: YES user_id=11105 There's a bug in your patch: ! else: ! x, y = s[:LINELEN+1], t[:LINELEN+1] ! left = 0 s and t are not defined here (UnboundLocal exception is raised), ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470 From noreply@sourceforge.net Fri Apr 25 11:18:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 03:18:51 -0700 Subject: [Patches] [ python-Patches-725904 ] Minor changes to logging Message-ID: Patches item #725904, was opened at 2003-04-22 22:37 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 7 Submitted By: Vinay Sajip (vsajip) Assigned to: Neal Norwitz (nnorwitz) Summary: Minor changes to logging Initial Comment: __init__.py: 1. Updated version number to 0.4.8 and status to beta. handlers.py: 1. Replaced explicit Python version check with hasattr to determine the running Python's capability. 2. Added Date: header to SMTPHandler 3. Changed HTTPHandler to allow more flexible mapping of a LogRecord to a dictionary to be urlencoded. Regression test ran OK on my system after these changes were made. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2003-04-25 10:18 Message: Logged In: YES user_id=308438 I attach an updated test_logging.py and output/test_logging which avoids the use of thread.join() and uses a condition variable instead to synchronize threads. In addition, the TCP thread automatically terminates when it sees an end-of-test sentinel. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 00:32 Message: Logged In: YES user_id=6380 Vinaj, I suggest that you don't focus on trying to reproduce the problem but study the way you have structured the tests to show to yourself that it *is* possible. Then think about a restructuring that avoids this. E.g. by using an event variable (see the threading module). If that doesn't work for Python 1.5.2, that doesn't matter IMO. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-04-23 22:46 Message: Logged In: YES user_id=308438 I can try to look into this, although I don't have access to Red Hat 9. I have limited access to Mandrake 9 and will try to run tests in that environment; I may not be able to reproduce it. I have no problem with simplifying the test - the reason for using threads is to give the logging system a reasonably good workout. test_logging.py is already quite a bit simpler than the test harness I use personally. While the test does create threads, it does seem to follow established practice and there is no obvious (to me) reason for the problem. Resolving this issue should not require a change to the API - if the worst comes to the worst, we can simplify test_logging to do minimal logic tests for logger/handler logic. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 18:22 Message: Logged In: YES user_id=6380 If adding a small sleep to the code "fixes" the problem, there is still a more fundamental problem with the tests. Vinaj, can you look into this? Do you understand the issue? I wonder if maybe the tests shouldn't be thread-based at all. It is okay if this doesn't get resolved before the b1 release; there will be a b2 release a month later. (As long as it doesn't require API changes -- bugfixes or changes to the test suite are okay though.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-23 03:52 Message: Logged In: YES user_id=33168 Checked in as: * Lib/logging/__init__.py: 1.9 * Lib/logging/handlers.py: 1.6 I still have the test failure problem. It's more consistent on Redhat 9. Adding a time.sleep(.1) to the test as the first statement in the finally: in test_main() (line 458) "fixes" the problem. Although this is a hack that I don't want to check in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 00:29 Message: Logged In: YES user_id=6380 Unassigning and accepting; someone else please apply this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 From noreply@sourceforge.net Fri Apr 25 11:35:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 03:35:50 -0700 Subject: [Patches] [ python-Patches-725569 ] Improved output for unittest failUnlessEqual Message-ID: Patches item #725569, was opened at 2003-04-22 10:33 Message generated for change (Comment added) made by duncanb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Duncan Booth (duncanb) Assigned to: Nobody/Anonymous (nobody) Summary: Improved output for unittest failUnlessEqual Initial Comment: The failUnlessEqual method in unittest.TestCase doesn't handle well the case where the objects being compared have a long string representation. The whole repr for each object is printed no matter how long, and no indication is given of where any differences occur. This patch uses difflib on long representations to provide a short output that highlights where the first difference actually is. It also limits the output for each value to fit on a single line (with the differences indicated on the line following). e.g. FAIL: test_failunlessEqual4 (__main__.Test) ---------------------------------------------------------------------- TestFailed: failUnlessEqual {'A': 65, 'C': 67, ...0, 'P ': 0, 'R': 82, 'U': 85, 'T': 84, 'W': 87, 'V': 8... ... ^^ ^ ... {'A': 65, 'C': 67, ...0, 'S': 83, 'R': 82, 'U': 85, 'T': 84, 'W': 87, 'V': 8... ... ^ ^^ ... File "F:\temp\test.py", line 59, in test_failunlessEqual4 self.failUnlessEqual(d2, d1) ---------------------------------------------------------------------- The attached file contains the changes, assuming that patch "722638 Better output for unittest" has already been applied. ---------------------------------------------------------------------- >Comment By: Duncan Booth (duncanb) Date: 2003-04-25 10:35 Message: Logged In: YES user_id=74031 Oops. I forgot to test for the case where the string didn't need shortening in the middle. New patch uploaded. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 10:03 Message: Logged In: YES user_id=11105 There's a bug in your patch: ! else: ! x, y = s[:LINELEN+1], t[:LINELEN+1] ! left = 0 s and t are not defined here (UnboundLocal exception is raised), ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470 From noreply@sourceforge.net Fri Apr 25 12:40:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 04:40:45 -0700 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-04-25 13:40 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_bool.py 1.9 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 23:00 Message: Logged In: YES user_id=6380 I suggest not to mess with unittest.py; it is still externally maintained as PyUnit. Maybe ask the PyUnit developer. No time to review the test, sorry; if it works, I suggest to just check it in. ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-23 22:33 Message: Logged In: YES user_id=89016 Here's the next one: test_bool.py ported to PyUnit with a few additional tests. Code coverage for boolobject.c is at 100%. Would it make sense to move assertIs() and assertIsNot() to unittest.py? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 13:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_pwd delete Lib/test/test_pwd.py 1.13 Lib/test/test_grp.py 1.11 Lib/test/test___all__.py 1.29 (with if __name == '__main__': test_main() added to test_pwd) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-15 01:09 Message: Logged In: YES user_id=33168 Sorry, you are correct. I removed the output/test_pwd and the test passes. This is on redhat 9 now. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-14 14:31 Message: Logged In: YES user_id=89016 Neal, are you sure the error you get isn't just from the output comparison? Can you post a traceback? test_pwd works for me with Redhat 7.3. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-13 11:07 Message: Logged In: YES user_id=89016 > question why do you use 3 lines in test_main, > rather than the old way? -- > test_support.run_unittest(Test) The example in Lib/test/README seems to suggest that it should be done this way. I'll look into the test_pwd problem tomorrow. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:54 Message: Logged In: YES user_id=33168 question why do you use 3 lines in test_main, rather than the old way? -- test_support.run_unittest(Test) test___all__ is fine test_grp is fine test_pwd fails for me on Redhat 7.2. It also needs an if __name == '__main__': test_main() ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 11:10 Message: Logged In: YES user_id=89016 Here's an updated test_grp that executes tests equivalent to those in test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-10 10:46 Message: Logged In: YES user_id=89016 Here's the next one: test_pwd ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-03-11 20:15 Message: Logged In: YES user_id=89016 Here's the next one: test___all__.py ported to PyUnit and updated. A better solution might be to replace __builtin__.__import__ in regrtest.py and test for the __all__ attribute there. Additionally this might allow us to check which modules are imported by regrtest.py and which are not and require additional tests. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Fri Apr 25 12:52:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 04:52:46 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Comment added) made by purcell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Steve Purcell (purcell) Date: 2003-04-25 13:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-20 04:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 17:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Fri Apr 25 13:05:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 05:05:08 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-04-25 14:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 13:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-20 04:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 17:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Fri Apr 25 13:37:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 05:37:01 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Comment added) made by purcell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Steve Purcell (purcell) Date: 2003-04-25 14:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 13:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-20 04:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 17:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Fri Apr 25 13:52:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 05:52:21 -0700 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-04-25 14:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 14:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 13:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-20 04:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 17:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply@sourceforge.net Fri Apr 25 15:22:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 07:22:16 -0700 Subject: [Patches] [ python-Patches-725904 ] Minor changes to logging Message-ID: Patches item #725904, was opened at 2003-04-22 18:37 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Vinay Sajip (vsajip) Assigned to: Neal Norwitz (nnorwitz) Summary: Minor changes to logging Initial Comment: __init__.py: 1. Updated version number to 0.4.8 and status to beta. handlers.py: 1. Replaced explicit Python version check with hasattr to determine the running Python's capability. 2. Added Date: header to SMTPHandler 3. Changed HTTPHandler to allow more flexible mapping of a LogRecord to a dictionary to be urlencoded. Regression test ran OK on my system after these changes were made. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-25 10:22 Message: Logged In: YES user_id=6380 Thanks, checked in! ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-04-25 06:18 Message: Logged In: YES user_id=308438 I attach an updated test_logging.py and output/test_logging which avoids the use of thread.join() and uses a condition variable instead to synchronize threads. In addition, the TCP thread automatically terminates when it sees an end-of-test sentinel. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 20:32 Message: Logged In: YES user_id=6380 Vinaj, I suggest that you don't focus on trying to reproduce the problem but study the way you have structured the tests to show to yourself that it *is* possible. Then think about a restructuring that avoids this. E.g. by using an event variable (see the threading module). If that doesn't work for Python 1.5.2, that doesn't matter IMO. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-04-23 18:46 Message: Logged In: YES user_id=308438 I can try to look into this, although I don't have access to Red Hat 9. I have limited access to Mandrake 9 and will try to run tests in that environment; I may not be able to reproduce it. I have no problem with simplifying the test - the reason for using threads is to give the logging system a reasonably good workout. test_logging.py is already quite a bit simpler than the test harness I use personally. While the test does create threads, it does seem to follow established practice and there is no obvious (to me) reason for the problem. Resolving this issue should not require a change to the API - if the worst comes to the worst, we can simplify test_logging to do minimal logic tests for logger/handler logic. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 14:22 Message: Logged In: YES user_id=6380 If adding a small sleep to the code "fixes" the problem, there is still a more fundamental problem with the tests. Vinaj, can you look into this? Do you understand the issue? I wonder if maybe the tests shouldn't be thread-based at all. It is okay if this doesn't get resolved before the b1 release; there will be a b2 release a month later. (As long as it doesn't require API changes -- bugfixes or changes to the test suite are okay though.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-22 23:52 Message: Logged In: YES user_id=33168 Checked in as: * Lib/logging/__init__.py: 1.9 * Lib/logging/handlers.py: 1.6 I still have the test failure problem. It's more consistent on Redhat 9. Adding a time.sleep(.1) to the test as the first statement in the finally: in test_main() (line 458) "fixes" the problem. Although this is a hack that I don't want to check in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:29 Message: Logged In: YES user_id=6380 Unassigning and accepting; someone else please apply this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 From noreply@sourceforge.net Fri Apr 25 15:23:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 07:23:18 -0700 Subject: [Patches] [ python-Patches-658327 ] Add inet_pton and inet_ntop to socket Message-ID: Patches item #658327, was opened at 2002-12-24 16:00 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Guido van Rossum (gvanrossum) Summary: Add inet_pton and inet_ntop to socket Initial Comment: Patch is against current CVS and adds two socket module functions, inet_pton and inet_ntop. Both of these should be available on all platforms (because of other dependancies in the code) so I don't think portability is a problem. inet_ntop converts a packed IP address to a human-readable '.' or ':' separated string representation of the IP. inet_pton performs the reverse operation. (Potential) problems: inet_pton sets errno to ENOSPC, which may lead to a confusing error message. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-25 10:23 Message: Logged In: YES user_id=6380 Checked in; now fixing the fallout for Windows. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 15:09 Message: Logged In: YES user_id=6380 Close. The tests however fail on platforms where inet_pton etc. aren't defined. The docs should say that this is not available on all platforms (and in particular not on Windows). ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-04-19 14:14 Message: Logged In: YES user_id=366566 Once again I've screwed up and uploaded the wrong .diff. Here is the correct one, which I just applied to a clean CVS checkout and ran the regression tests for, just to be sure. One test does fail (test_tzset), but also fails on a clean CVS checkout. Additionally, as a correct to my last post, has_ipv6 is set based on the definition of IPV6_ENABLED, not HAVE_INET_PTON. My apologies for your wasted time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 13:53 Message: Logged In: YES user_id=6380 I reject this patch on account of the fact that it clearly hasn't been tested: there's a call to memset() with 2 instead of 3 arguments. Given this lack of care I'm lowering the priority. Also note that there was a patch to test_heapq.py in the patch set. Poster is free to submit a new patch, but I can't guarantee that it'll make it into 2.3b1. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-04-19 13:28 Message: Logged In: YES user_id=366566 Based on the discussion, I've uploaded a new version of the patch. This one does the following: if HAVE_INET_PTON is defined, has_ipv6 is added to the socket module as True, socket_inet_pton and socket_inet_ntop are defined and added to the module, and use the underlying functions to perform the work, only AF_INET and AF_INET6 are supported and where appropriate, input lengths are checked against in_addr and in6_addr. Otherwise, has_ipv6 is added to the socket module as False and no other changes are made. No checks against IPV6_ENABLED are made, because AF_INET6 is always defined and only the platform functions are used to handle values passed to the functions. The patch also updates libsocket.tex, ACKS, NEWS, the socket.py module docstring, and adds tests for inet_pton, inet_ntop, inet_ntoa, and inet_aton to test_socket. Guido, I'm assigning this to you as per your suggestions on python-dev, and because Neal has told me in private correspondance that he doesn't think he'll have a chance to get to it before 2.3b1 comes out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-04 02:05 Message: Logged In: YES user_id=21627 My two suggestions aren't exclusive: If you have the native inet_pton, you can *always* support IPv6 addresses with that, regardless of whether --enable-ipv6 was passed to configure or not. If that is done, it will be a legitime test failure for inet_pton not to support IPv6 - after all, the primary reason to define this function was to support IPv6, so if the native function fails to do so, there is clearly a bug in the system. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 22:41 Message: Logged In: YES user_id=33168 I added the #ifdef, but that doesn't address the testing problem. If the platform has inet_pton, but doesn't have IPv6 ENABLED. The inet_pton will be exported, but there's no good way to tell if you can pass an IPv6 address. The only way to test if IPv6 is enabled would be to call inet_pton with AF_INET6, catch a socket.error and check if the exception message is "unknown address family". Since this is really a testing issue, perhaps that's best after all? Do you agree this should be done? * Remove has_ipv6 * Export inet_pton & inet_ntop only if defined for platform * Only try to test inet_pton/ntop if defined for platform * Modify the tests to pass a valid IPv6 test, catch socket.error, if the error message is "unknown address family", don't test ipv6 any further, if the error message is different, raise TestFailed, if no exception, test all IPv6 addresses ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 17:25 Message: Logged In: YES user_id=33168 As I recall, yes, has_ipv6 is only for tests. There was no way to distinguish if python was built with IPv6 support, since AF_INET6 was always defined. Your second approach sounds like it will work. I need to review the code, though. I've forgotten how it works. :-( ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 05:15 Message: Logged In: YES user_id=21627 The has_ipv6 test is only there for the tests? In that case, drop it, and just perform AF_INET6 conversions unconditionally. OTOH, I think we should not expose the emulated inet_pton: it doesn't set errno correctly, and offers no advantage over inet_addr. So wrap the entire code with HAVE_INET_PTON, and only perform the tests if the function is supported. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 21:40 Message: Logged In: YES user_id=33168 I was just about to check this in, but then I ran into a problem. IPv6 may not be enabled, even if the constant AF_INET6 exists. The cleanest way I saw to address this in the test was to add a has_ipv6 boolean constant to the socket module. Martin, do you think this is acceptable? Attached is a complete patch which should be safe (based on the discussion below), includes tests and doc changes. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:04 Message: Logged In: YES user_id=366566 Yea, testing for the proper input length is definitely something that should be done. The patch looks good, but for one thing. If the specified address family is neither AF_INET nor AF_INET6, the length won't be tested and the underlying inet_ntop will be called. This isn't a problem now (afaik) because only those two address families are support, but in a future libc version with more supported address families, it might open a similar hole to the one you've fixed. Perhaps the + } else { + PyErr_SetString(socket_error, "unknown address family"); + return NULL; + } should be moved up from the second if-grouping to follow the first if-grouping. Everything else looks good to me. Thanks for taking the time to look at this :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 22:49 Message: Logged In: YES user_id=33168 JP, do you agree with my comment on 2002-12-30 about the checks? I have attached an updated patch. Please review and verify this is correct. Thank you for the additional tests. Feel free to submit patches with additional tests for any and all modules! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-31 11:52 Message: Logged In: YES user_id=366566 Doc, NEWS, and test_socket patch attached. I didn't notice any inet_aton/inet_ntoa tests in the module so I added a couple for those as well (I excluded a test for inet_ntoa('255.255.255.255') ;) Also included are a couple IPv6 tests. I'm not sure if these are appropriate, since many systems may still lack the required support for them to pass. I'll leave it up to you to decide whether they should be commented out or removed or whatever. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 08:17 Message: Logged In: YES user_id=21627 I agree that such a change should be added. Neal, you have given this patch more attention than I did - please check it in when you consider it complete. I just like to point out that it is missing documentation changes (libsocket.tex), a NEWS entry, and a test case. kuran, please provide those as a single patch file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-30 19:11 Message: Logged In: YES user_id=33168 ISTM that in socket_inet_ntop() you need to verify the size of the packed value passed in. If the user passes an empty string, inet_ntop() could read beyond the buffer passed in, potentially causing a core dump. The checks could be something like this: if (af == AF_INET && len != sizeof(struct in_addr)) else if (af == AF_INET6 && len != sizeof(struct in6_addr)) Do this make sense? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-27 10:39 Message: Logged In: YES user_id=366566 The use case I have for it at the moment is a DNS server (Twisted.names). inet_pton allows me to handle IPv6 addresses, so it allows me to support AAAA and A6 records. I believe an IPv6 capable socks proxy would find this useful as well. Basically, low level network stuff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-27 05:23 Message: Logged In: YES user_id=21627 What is the rationale for providing this functionality? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-26 13:32 Message: Logged In: YES user_id=366566 Ooops, I made two, and uploaded the wrong one >:O Sorry. Dunno if it's still helpful, but here's the unified diff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 13:10 Message: Logged In: YES user_id=33168 Next time, please use context or unified diff. -c or -u option to cvs diff: cvs diff -c ... ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-24 16:05 Message: Logged In: YES user_id=366566 Sourceforge decided not to attach the file the first time... Here it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 From noreply@sourceforge.net Fri Apr 25 15:34:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 07:34:26 -0700 Subject: [Patches] [ python-Patches-725904 ] Minor changes to logging Message-ID: Patches item #725904, was opened at 2003-04-22 18:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 7 Submitted By: Vinay Sajip (vsajip) Assigned to: Neal Norwitz (nnorwitz) Summary: Minor changes to logging Initial Comment: __init__.py: 1. Updated version number to 0.4.8 and status to beta. handlers.py: 1. Replaced explicit Python version check with hasattr to determine the running Python's capability. 2. Added Date: header to SMTPHandler 3. Changed HTTPHandler to allow more flexible mapping of a LogRecord to a dictionary to be urlencoded. Regression test ran OK on my system after these changes were made. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-25 10:34 Message: Logged In: YES user_id=33168 The test works now on both Redhat 9 and Solaris 8! Thanks Vinay. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-25 10:22 Message: Logged In: YES user_id=6380 Thanks, checked in! ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-04-25 06:18 Message: Logged In: YES user_id=308438 I attach an updated test_logging.py and output/test_logging which avoids the use of thread.join() and uses a condition variable instead to synchronize threads. In addition, the TCP thread automatically terminates when it sees an end-of-test sentinel. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 20:32 Message: Logged In: YES user_id=6380 Vinaj, I suggest that you don't focus on trying to reproduce the problem but study the way you have structured the tests to show to yourself that it *is* possible. Then think about a restructuring that avoids this. E.g. by using an event variable (see the threading module). If that doesn't work for Python 1.5.2, that doesn't matter IMO. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-04-23 18:46 Message: Logged In: YES user_id=308438 I can try to look into this, although I don't have access to Red Hat 9. I have limited access to Mandrake 9 and will try to run tests in that environment; I may not be able to reproduce it. I have no problem with simplifying the test - the reason for using threads is to give the logging system a reasonably good workout. test_logging.py is already quite a bit simpler than the test harness I use personally. While the test does create threads, it does seem to follow established practice and there is no obvious (to me) reason for the problem. Resolving this issue should not require a change to the API - if the worst comes to the worst, we can simplify test_logging to do minimal logic tests for logger/handler logic. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 14:22 Message: Logged In: YES user_id=6380 If adding a small sleep to the code "fixes" the problem, there is still a more fundamental problem with the tests. Vinaj, can you look into this? Do you understand the issue? I wonder if maybe the tests shouldn't be thread-based at all. It is okay if this doesn't get resolved before the b1 release; there will be a b2 release a month later. (As long as it doesn't require API changes -- bugfixes or changes to the test suite are okay though.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-22 23:52 Message: Logged In: YES user_id=33168 Checked in as: * Lib/logging/__init__.py: 1.9 * Lib/logging/handlers.py: 1.6 I still have the test failure problem. It's more consistent on Redhat 9. Adding a time.sleep(.1) to the test as the first statement in the finally: in test_main() (line 458) "fixes" the problem. Although this is a hack that I don't want to check in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 20:29 Message: Logged In: YES user_id=6380 Unassigning and accepting; someone else please apply this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725904&group_id=5470 From noreply@sourceforge.net Fri Apr 25 15:40:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 07:40:48 -0700 Subject: [Patches] [ python-Patches-727483 ] AUTH_TYPE and REMOTE_USER for CGIHTTPServer.py:run_cgi() Message-ID: Patches item #727483, was opened at 2003-04-25 18:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727483&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: AUTH_TYPE and REMOTE_USER for CGIHTTPServer.py:run_cgi() Initial Comment: The patch adds env['AUTH_TYPE'] and env['REMOTE_USER'] for CGIHTTPServer.py:run_cgi(), if there was Authorization header and if the header can be parsed according to WWW-Authorization rules. REMOTE_USER actually extracted from the header only if the header shows it is Basic Authorization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727483&group_id=5470 From noreply@sourceforge.net Fri Apr 25 15:41:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 07:41:54 -0700 Subject: [Patches] [ python-Patches-727483 ] AUTH_TYPE and REMOTE_USER for CGIHTTPServer.py:run_cgi() Message-ID: Patches item #727483, was opened at 2003-04-25 18:40 Message generated for change (Settings changed) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727483&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None >Priority: 3 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: AUTH_TYPE and REMOTE_USER for CGIHTTPServer.py:run_cgi() Initial Comment: The patch adds env['AUTH_TYPE'] and env['REMOTE_USER'] for CGIHTTPServer.py:run_cgi(), if there was Authorization header and if the header can be parsed according to WWW-Authorization rules. REMOTE_USER actually extracted from the header only if the header shows it is Basic Authorization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727483&group_id=5470 From noreply@sourceforge.net Fri Apr 25 16:42:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Apr 2003 08:42:15 -0700 Subject: [Patches] [ python-Patches-545480 ] Examples for urllib2 Message-ID: Patches item #545480, was opened at 2002-04-18 00:13 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=545480&group_id=5470 Category: Documentation Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Jeremy Hylton (jhylton) Summary: Examples for urllib2 Initial Comment: An associate who's learning Python recently complained about a lack of examples for urllib2. As a starting point, I'd like to submit the following: This example gets the python.org main page and displays the first 100 bytes of it: >>> import urllib2 >>> url = urllib2.urlopen('http://www.python.org/') >>> print url.read()[:100]