From noreply at sourceforge.net Mon Nov 1 03:21:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 03:21:51 2004 Subject: [Patches] [ python-Patches-1053879 ] mingw compile Message-ID: Patches item #1053879, was opened at 2004-10-25 11:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Kramm (kramm) Assigned to: Nobody/Anonymous (nobody) Summary: mingw compile Initial Comment: A cross-compile of a Win32 Python under Linux using MingW (www.mingw.org) didn't work, as posixmodule.c didn't know anything about MingW. This patch fixes the various compile errors by introducing a new local MINGW define in posixmodule.c, and making several #ifdefs also take that variable into account. After this patch is applied, it's possible to compile python.exe on Linux with MingW by doing CXX=i386-mingw32msvc-g++ CPP=i386-mingw32msvc-cpp RANLIB=i386-mingw32msvc-ranlib AR=i386-mingw32msvc-ar CC="/opt/xmingw/bin/i386-mingw32msvc-gcc -DMS_WINDOWS -DPy_WIN_WIDE_FILENAMES" ./configure --host=i586-mingw32msvc sed -i s/initposix/initnt/g Modules/config.c sed -i 's/#define HAVE_DEV_PTMX 1//g' pyconfig.h make ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 21:21 Message: Logged In: YES user_id=80475 I don't have a way of testing your patch and will have to apply it on blind faith. Be sure to get it right and read it carefully to make sure it doesn't mess-up anyone else's compilation. The attached version won't compile for me (MSVC++ 6.0 on WinMe): posixmodule.c C:\py24\Modules\posixmodule.c(1175) : warning C4013: 'ttyname' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1175) : warning C4047: '=' : 'char *' differs in levels of indirection from 'int ' C:\py24\Modules\posixmodule.c(1660) : error C2065: 'DIR' : undeclared identifier C:\py24\Modules\posixmodule.c(1660) : error C2065: 'dirp' : undeclared identifier C:\py24\Modules\posixmodule.c(1660) : warning C4552: '*' : operator has no effect; expected operator with side-effect C:\py24\Modules\posixmodule.c(1661) : error C2143: syntax error : missing ';' before 'type' C:\py24\Modules\posixmodule.c(1662) : error C2143: syntax error : missing ';' before 'type' C:\py24\Modules\posixmodule.c(1665) : error C2065: 'arg_is_unicode' : undeclared identifier C:\py24\Modules\posixmodule.c(1670) : warning C4013: 'opendir' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1670) : warning C4047: '==' : 'int ' differs in levels of indirection from 'void *' C:\py24\Modules\posixmodule.c(1674) : warning C4013: 'closedir' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1678) : error C2065: 'ep' : undeclared identifier C:\py24\Modules\posixmodule.c(1678) : warning C4013: 'readdir' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1678) : warning C4047: '!=' : 'int ' differs in levels of indirection from 'void *' C:\py24\Modules\posixmodule.c(1679) : error C2223: left of '->d_name' must point to struct/union C:\py24\Modules\posixmodule.c(1680) : error C2223: left of '->d_namlen' must point to struct/union C:\py24\Modules\posixmodule.c(1681) : error C2223: left of '->d_name' must point to struct/union C:\py24\Modules\posixmodule.c(1681) : error C2223: left of '->d_namlen' must point to struct/union C:\py24\Modules\posixmodule.c(1683) : error C2223: left of '->d_name' must point to struct/union C:\py24\Modules\posixmodule.c(1683) : error C2223: left of '->d_namlen' must point to struct/union C:\py24\Modules\posixmodule.c(1683) : error C2198: 'PyString_FromStringAndSize' : too few actual parameters C:\py24\Modules\posixmodule.c(2860) : warning C4013: 'fork' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(2986) : warning C4013: 'getegid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(2999) : warning C4013: 'geteuid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3012) : warning C4013: 'getgid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3134) : warning C4013: 'getppid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3176) : warning C4013: 'getuid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3206) : warning C4013: 'kill' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(4959) : warning C4013: 'wait' undefined; assuming extern returning int ---------------------------------------------------------------------- Comment By: Matthias Kramm (kramm) Date: 2004-10-31 04:11 Message: Logged In: YES user_id=1146139 Ok, I've attached the full posixmodule.c. It's based on the lastest CVS version (2.329, from 2004/10/13). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 00:40 Message: Logged In: YES user_id=80475 Please attach a new posixmodule.c instead of the diff file. For some reason, my patch tool thinks the formatting is malformed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 From noreply at sourceforge.net Mon Nov 1 04:53:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 04:53:20 2004 Subject: [Patches] [ python-Patches-1056967 ] No ValueError for safe_substitute() Message-ID: Patches item #1056967, was opened at 2004-10-29 14:47 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1056967&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: No ValueError for safe_substitute() Initial Comment: I think it's a mistake for Template.safe_substitute() to raise a ValueError when the invalid group is matched. I just ran across such a situation in Real Code that is using Template. In my code, I'm using a subclass to override idpattern and then calling safe_substitute(). The source of the template is a flattened mail message where what I'm substituting is going into some of the header fields. The body of the message contains a big blurb of XML, including the string "...$1...". Well, that $1 triggers the ValueError. This patch changes the semantics of safe_substitute() so that when the 'invalid' group matches, the original delimiter is returned, which I think is the right thing to do. Included is an updated test (I will update the docs too if you agree that this patch should be applied). ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-31 22:53 Message: Logged In: YES user_id=12800 Committed, with doc updates. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-30 23:46 Message: Logged In: YES user_id=80475 The docs should spell-out that the safe in safe_substitute() means that no exceptions will be raised except possible memory errors. In some sense, it is now anything but safe. It will silently skip past dangling delimiters, unclosed braced identifiers such as ${oops, identifiers with incorrect bracing such $, and idenfiers that aren't valid python identifiers such as $1two3. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-30 22:39 Message: Logged In: YES user_id=80475 Simplify: return '%s' % self.delimiter To just: return self.delimiter Please add docs and Misc/NEWS entry, then apply. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-30 20:13 Message: Logged In: YES user_id=1038590 I'd agree with those semantics - if an unrecognised identifier doesn't trigger a Key Error, I see no reason for a non-identifier to trigger a Value Error. For people who want stricter checking - well, that's what substitute() is for. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1056967&group_id=5470 From noreply at sourceforge.net Mon Nov 1 09:28:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 09:28:15 2004 Subject: [Patches] [ python-Patches-1053879 ] mingw compile Message-ID: Patches item #1053879, was opened at 2004-10-25 18:38 Message generated for change (Comment added) made by kramm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Kramm (kramm) Assigned to: Nobody/Anonymous (nobody) Summary: mingw compile Initial Comment: A cross-compile of a Win32 Python under Linux using MingW (www.mingw.org) didn't work, as posixmodule.c didn't know anything about MingW. This patch fixes the various compile errors by introducing a new local MINGW define in posixmodule.c, and making several #ifdefs also take that variable into account. After this patch is applied, it's possible to compile python.exe on Linux with MingW by doing CXX=i386-mingw32msvc-g++ CPP=i386-mingw32msvc-cpp RANLIB=i386-mingw32msvc-ranlib AR=i386-mingw32msvc-ar CC="/opt/xmingw/bin/i386-mingw32msvc-gcc -DMS_WINDOWS -DPy_WIN_WIDE_FILENAMES" ./configure --host=i586-mingw32msvc sed -i s/initposix/initnt/g Modules/config.c sed -i 's/#define HAVE_DEV_PTMX 1//g' pyconfig.h make ---------------------------------------------------------------------- >Comment By: Matthias Kramm (kramm) Date: 2004-11-01 09:28 Message: Logged In: YES user_id=1146139 Thanks for testing this with MSVC++. You're right- the patch did break VC compilation (There was an #else missing in the big recursive #ifdef block on line 80). I'll attach a fixed version (and delete the old version). I've scrutinized the new version several times to make sure there aren't any other issues. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-01 03:21 Message: Logged In: YES user_id=80475 I don't have a way of testing your patch and will have to apply it on blind faith. Be sure to get it right and read it carefully to make sure it doesn't mess-up anyone else's compilation. The attached version won't compile for me (MSVC++ 6.0 on WinMe): posixmodule.c C:\py24\Modules\posixmodule.c(1175) : warning C4013: 'ttyname' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1175) : warning C4047: '=' : 'char *' differs in levels of indirection from 'int ' C:\py24\Modules\posixmodule.c(1660) : error C2065: 'DIR' : undeclared identifier C:\py24\Modules\posixmodule.c(1660) : error C2065: 'dirp' : undeclared identifier C:\py24\Modules\posixmodule.c(1660) : warning C4552: '*' : operator has no effect; expected operator with side-effect C:\py24\Modules\posixmodule.c(1661) : error C2143: syntax error : missing ';' before 'type' C:\py24\Modules\posixmodule.c(1662) : error C2143: syntax error : missing ';' before 'type' C:\py24\Modules\posixmodule.c(1665) : error C2065: 'arg_is_unicode' : undeclared identifier C:\py24\Modules\posixmodule.c(1670) : warning C4013: 'opendir' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1670) : warning C4047: '==' : 'int ' differs in levels of indirection from 'void *' C:\py24\Modules\posixmodule.c(1674) : warning C4013: 'closedir' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1678) : error C2065: 'ep' : undeclared identifier C:\py24\Modules\posixmodule.c(1678) : warning C4013: 'readdir' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1678) : warning C4047: '!=' : 'int ' differs in levels of indirection from 'void *' C:\py24\Modules\posixmodule.c(1679) : error C2223: left of '->d_name' must point to struct/union C:\py24\Modules\posixmodule.c(1680) : error C2223: left of '->d_namlen' must point to struct/union C:\py24\Modules\posixmodule.c(1681) : error C2223: left of '->d_name' must point to struct/union C:\py24\Modules\posixmodule.c(1681) : error C2223: left of '->d_namlen' must point to struct/union C:\py24\Modules\posixmodule.c(1683) : error C2223: left of '->d_name' must point to struct/union C:\py24\Modules\posixmodule.c(1683) : error C2223: left of '->d_namlen' must point to struct/union C:\py24\Modules\posixmodule.c(1683) : error C2198: 'PyString_FromStringAndSize' : too few actual parameters C:\py24\Modules\posixmodule.c(2860) : warning C4013: 'fork' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(2986) : warning C4013: 'getegid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(2999) : warning C4013: 'geteuid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3012) : warning C4013: 'getgid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3134) : warning C4013: 'getppid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3176) : warning C4013: 'getuid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3206) : warning C4013: 'kill' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(4959) : warning C4013: 'wait' undefined; assuming extern returning int ---------------------------------------------------------------------- Comment By: Matthias Kramm (kramm) Date: 2004-10-31 10:11 Message: Logged In: YES user_id=1146139 Ok, I've attached the full posixmodule.c. It's based on the lastest CVS version (2.329, from 2004/10/13). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 06:40 Message: Logged In: YES user_id=80475 Please attach a new posixmodule.c instead of the diff file. For some reason, my patch tool thinks the formatting is malformed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 From noreply at sourceforge.net Mon Nov 1 11:14:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 11:14:16 2004 Subject: [Patches] [ python-Patches-1053879 ] mingw compile Message-ID: Patches item #1053879, was opened at 2004-10-25 11:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Kramm (kramm) >Assigned to: Martin v. L?wis (loewis) Summary: mingw compile Initial Comment: A cross-compile of a Win32 Python under Linux using MingW (www.mingw.org) didn't work, as posixmodule.c didn't know anything about MingW. This patch fixes the various compile errors by introducing a new local MINGW define in posixmodule.c, and making several #ifdefs also take that variable into account. After this patch is applied, it's possible to compile python.exe on Linux with MingW by doing CXX=i386-mingw32msvc-g++ CPP=i386-mingw32msvc-cpp RANLIB=i386-mingw32msvc-ranlib AR=i386-mingw32msvc-ar CC="/opt/xmingw/bin/i386-mingw32msvc-gcc -DMS_WINDOWS -DPy_WIN_WIDE_FILENAMES" ./configure --host=i586-mingw32msvc sed -i s/initposix/initnt/g Modules/config.c sed -i 's/#define HAVE_DEV_PTMX 1//g' pyconfig.h make ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-01 05:14 Message: Logged In: YES user_id=80475 Martin, I have no way of testing this further. The diff looks fine to my eye. I would like to apply it before the beta so that any problems would surface right away. Do you have any issues with the patch that I might not have thought about? ---------------------------------------------------------------------- Comment By: Matthias Kramm (kramm) Date: 2004-11-01 03:28 Message: Logged In: YES user_id=1146139 Thanks for testing this with MSVC++. You're right- the patch did break VC compilation (There was an #else missing in the big recursive #ifdef block on line 80). I'll attach a fixed version (and delete the old version). I've scrutinized the new version several times to make sure there aren't any other issues. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 21:21 Message: Logged In: YES user_id=80475 I don't have a way of testing your patch and will have to apply it on blind faith. Be sure to get it right and read it carefully to make sure it doesn't mess-up anyone else's compilation. The attached version won't compile for me (MSVC++ 6.0 on WinMe): posixmodule.c C:\py24\Modules\posixmodule.c(1175) : warning C4013: 'ttyname' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1175) : warning C4047: '=' : 'char *' differs in levels of indirection from 'int ' C:\py24\Modules\posixmodule.c(1660) : error C2065: 'DIR' : undeclared identifier C:\py24\Modules\posixmodule.c(1660) : error C2065: 'dirp' : undeclared identifier C:\py24\Modules\posixmodule.c(1660) : warning C4552: '*' : operator has no effect; expected operator with side-effect C:\py24\Modules\posixmodule.c(1661) : error C2143: syntax error : missing ';' before 'type' C:\py24\Modules\posixmodule.c(1662) : error C2143: syntax error : missing ';' before 'type' C:\py24\Modules\posixmodule.c(1665) : error C2065: 'arg_is_unicode' : undeclared identifier C:\py24\Modules\posixmodule.c(1670) : warning C4013: 'opendir' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1670) : warning C4047: '==' : 'int ' differs in levels of indirection from 'void *' C:\py24\Modules\posixmodule.c(1674) : warning C4013: 'closedir' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1678) : error C2065: 'ep' : undeclared identifier C:\py24\Modules\posixmodule.c(1678) : warning C4013: 'readdir' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(1678) : warning C4047: '!=' : 'int ' differs in levels of indirection from 'void *' C:\py24\Modules\posixmodule.c(1679) : error C2223: left of '->d_name' must point to struct/union C:\py24\Modules\posixmodule.c(1680) : error C2223: left of '->d_namlen' must point to struct/union C:\py24\Modules\posixmodule.c(1681) : error C2223: left of '->d_name' must point to struct/union C:\py24\Modules\posixmodule.c(1681) : error C2223: left of '->d_namlen' must point to struct/union C:\py24\Modules\posixmodule.c(1683) : error C2223: left of '->d_name' must point to struct/union C:\py24\Modules\posixmodule.c(1683) : error C2223: left of '->d_namlen' must point to struct/union C:\py24\Modules\posixmodule.c(1683) : error C2198: 'PyString_FromStringAndSize' : too few actual parameters C:\py24\Modules\posixmodule.c(2860) : warning C4013: 'fork' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(2986) : warning C4013: 'getegid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(2999) : warning C4013: 'geteuid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3012) : warning C4013: 'getgid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3134) : warning C4013: 'getppid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3176) : warning C4013: 'getuid' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(3206) : warning C4013: 'kill' undefined; assuming extern returning int C:\py24\Modules\posixmodule.c(4959) : warning C4013: 'wait' undefined; assuming extern returning int ---------------------------------------------------------------------- Comment By: Matthias Kramm (kramm) Date: 2004-10-31 04:11 Message: Logged In: YES user_id=1146139 Ok, I've attached the full posixmodule.c. It's based on the lastest CVS version (2.329, from 2004/10/13). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 00:40 Message: Logged In: YES user_id=80475 Please attach a new posixmodule.c instead of the diff file. For some reason, my patch tool thinks the formatting is malformed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 From noreply at sourceforge.net Mon Nov 1 12:11:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 12:11:16 2004 Subject: [Patches] [ python-Patches-1057588 ] chr, ord, unichr documentation updates Message-ID: Patches item #1057588, was opened at 2004-10-31 08:25 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None >Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: chr, ord, unichr documentation updates Initial Comment: The attached diff may be applied against v1.175 of libfuncs.tex -- http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Doc/lib/libfuncs.tex?content-type=text%2Fplain&rev=1.175 chr(): A str is not in any particular encoding, so don't talk about ASCII, which does not apply to arguments > 127 anyway. Also make reference to unichr(). ord(): A str is not in any particular encoding, so don't talk about ASCII. Describe what the return value represents for each type of string (str, unicode), and mention the TypeError that will be raised on narrow unicode builds of Python. unichr(): Mention the restrictions on the argument depending on whether Python was built with wide or narrow unicode. The precedent in unicode() is to refer to str objects as "8-bit strings", so the wording of the above changes was chosen accordingly. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-11-01 12:11 Message: Logged In: YES user_id=38388 The new wording is indeed better than the old one. +1 on that change. However, you should use the term "code point" consistently and perhaps add a footnote explaining the difference between code point, glyph and character (Unicode strings are arrays of code points - not characters). Another note: I don't particularly like the terms "narrow" and "wide" Unicode builds. If possible, these terms should be replaced by the more accurate technical terms UCS2 and UCS4 - since the error messages relating to this difference also mention these technical terms rather then narrow or wide builds. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 19:17 Message: Logged In: YES user_id=371366 Oops, didn't mean to remove the assignment to fdrake when adding previous comment. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 09:23 Message: Logged In: YES user_id=371366 Also note that I did not suggest removing the example with the letter "a". I just suggested removing the reference to "ASCII" in particular. Ideally, IMHO, the documentation for sequence types is where one should mention the strong association between strings and ASCII. It currently doesn't even really describe what a string or Unicode string is. It should state that non-Unicode strings are an abstraction in which each member of the sequence is a "character" that is actually an 8-bit value, as in Standard C, intended to represent a character in an arbitrary encoding, and that there is an _informal_ convention, in documentation, of referring to these values as being ASCII values, in part due to the notational conventions of string literals, such as using "\t", "\n", and "\r" to represent decimal values 9, 10, and 13, respectively (associations that only make sense in ASCII or ASCII-based encodings), and in part because it is easier to talk about the lower 128 values in terms of their ASCII equivalents (e.g. "chr(97) produces the string 'a'"). Likewise, the unicode type could be described as being an abstraction of 16-bit ("narrow") or 32-bit ("wide") code units, depending on how Python was built, and so on... I would see making such unambiguous statements to be a reasonable alternative to just deleting mentions of ASCII from the library docs, although I think making all of the changes would be best, as people already have preconceived notions of what a 'string' is and I know from experience that they tend to not worry about straightening out their understanding of such nuances until they get burned by assumptions built around statements like "ord() gives you the ASCII value". ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 08:51 Message: Logged In: YES user_id=371366 That kind of resistance to using accurate, strict terminology just perpetuates common misunderstandings about the relationship between characters and encodings. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 08:38 Message: Logged In: YES user_id=80475 The attachment didn't make it. Try again. And, FWIW, I think the documentation is perfectly clear as is. Though the ASCII reference is not strict, I think taking it out would be a mistake. Though many encodings are possible, there is a strong relationship between the number 97 and the letter 'a'. Mentioning ASCII makes that relationship clear. IOW, I -1 on changing it until a new bytes type is introduced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 From noreply at sourceforge.net Mon Nov 1 14:02:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 14:02:37 2004 Subject: [Patches] [ python-Patches-1015989 ] compiler.transformer: correct lineno attribute when possible Message-ID: Patches item #1015989, was opened at 2004-08-25 16:00 Message generated for change (Comment added) made by felixwiemann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015989&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thenault Sylvain (syt) Assigned to: Jeremy Hylton (jhylton) Summary: compiler.transformer: correct lineno attribute when possible Initial Comment: this patch try to fix the lineno attribute of some ast nodes whenever possible. I'm not sure this patch fix all relevant cases, but at least it fixes the most obvious ones. I would like to have at the end a correct line number on every nodes but Module (some program such as Pylint are using this package and need to have this information correctly). A test module is also joined. ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-11-01 14:02 Message: Logged In: YES user_id=1014490 This patch seems to have been applied in rev. 1.45 of transformer.py. However, there is a problem, see #1057835. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015989&group_id=5470 From noreply at sourceforge.net Tue Nov 2 07:56:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 2 07:56:07 2004 Subject: [Patches] [ python-Patches-1057588 ] chr, ord, unichr documentation updates Message-ID: Patches item #1057588, was opened at 2004-10-31 00:25 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: chr, ord, unichr documentation updates Initial Comment: The attached diff may be applied against v1.175 of libfuncs.tex -- http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Doc/lib/libfuncs.tex?content-type=text%2Fplain&rev=1.175 chr(): A str is not in any particular encoding, so don't talk about ASCII, which does not apply to arguments > 127 anyway. Also make reference to unichr(). ord(): A str is not in any particular encoding, so don't talk about ASCII. Describe what the return value represents for each type of string (str, unicode), and mention the TypeError that will be raised on narrow unicode builds of Python. unichr(): Mention the restrictions on the argument depending on whether Python was built with wide or narrow unicode. The precedent in unicode() is to refer to str objects as "8-bit strings", so the wording of the above changes was chosen accordingly. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2004-11-01 23:56 Message: Logged In: YES user_id=371366 You're right re: UCS2/UCS4. I can work up another patch. I think you know this, but "code point" is not accurate UTR#17-conformant terminology, as it just refers to the single integer number from the code space that is available to Unicode (0x0-0xD7FF and 0xE000-0x10FFFF), bearing in mind that not all code points correspond to characters (all those whose hex values end in FFFE and FFFF, for example). If we are just talking about what a Unicode string is in general sense, we say it is just a sequence of characters -- a character being a unit like, say, "Latin small letter z", or "plus sign", in a writing system ("script") like Latin/Roman, Cyrillic, Hiragana, etc. If we are talking about what the unicode type is in Python, to be accurate, we should say it is a sequence of UCS2 or UCS4 "code values", depending on how Python was compiled, and note that in its printable representation, the unicode type displays, for characters outside the ASCII range, the "code points" represented by those code values. It does this using the same syntax as for string literals, but treats surrogate pairs of code values as being representative of a single code point (e.g., a unicode object consisting of code value 0xD800 followed by 0xDC00 is printably represented by u'\U00010000' even though it's still a string of length 2 in both UCS2 and UCS4 builds of Python). Is there a recommendation for how to refer unambiguously to an instance of a unicode type? Is it a "unicode object"? How about an instance of the str type? Is it an "8-bit string"? I notice we say "byte string" a lot but apparently not everyone is happy about that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-11-01 04:11 Message: Logged In: YES user_id=38388 The new wording is indeed better than the old one. +1 on that change. However, you should use the term "code point" consistently and perhaps add a footnote explaining the difference between code point, glyph and character (Unicode strings are arrays of code points - not characters). Another note: I don't particularly like the terms "narrow" and "wide" Unicode builds. If possible, these terms should be replaced by the more accurate technical terms UCS2 and UCS4 - since the error messages relating to this difference also mention these technical terms rather then narrow or wide builds. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 11:17 Message: Logged In: YES user_id=371366 Oops, didn't mean to remove the assignment to fdrake when adding previous comment. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 01:23 Message: Logged In: YES user_id=371366 Also note that I did not suggest removing the example with the letter "a". I just suggested removing the reference to "ASCII" in particular. Ideally, IMHO, the documentation for sequence types is where one should mention the strong association between strings and ASCII. It currently doesn't even really describe what a string or Unicode string is. It should state that non-Unicode strings are an abstraction in which each member of the sequence is a "character" that is actually an 8-bit value, as in Standard C, intended to represent a character in an arbitrary encoding, and that there is an _informal_ convention, in documentation, of referring to these values as being ASCII values, in part due to the notational conventions of string literals, such as using "\t", "\n", and "\r" to represent decimal values 9, 10, and 13, respectively (associations that only make sense in ASCII or ASCII-based encodings), and in part because it is easier to talk about the lower 128 values in terms of their ASCII equivalents (e.g. "chr(97) produces the string 'a'"). Likewise, the unicode type could be described as being an abstraction of 16-bit ("narrow") or 32-bit ("wide") code units, depending on how Python was built, and so on... I would see making such unambiguous statements to be a reasonable alternative to just deleting mentions of ASCII from the library docs, although I think making all of the changes would be best, as people already have preconceived notions of what a 'string' is and I know from experience that they tend to not worry about straightening out their understanding of such nuances until they get burned by assumptions built around statements like "ord() gives you the ASCII value". ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 00:51 Message: Logged In: YES user_id=371366 That kind of resistance to using accurate, strict terminology just perpetuates common misunderstandings about the relationship between characters and encodings. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 00:38 Message: Logged In: YES user_id=80475 The attachment didn't make it. Try again. And, FWIW, I think the documentation is perfectly clear as is. Though the ASCII reference is not strict, I think taking it out would be a mistake. Though many encodings are possible, there is a strong relationship between the number 97 and the letter 'a'. Mentioning ASCII makes that relationship clear. IOW, I -1 on changing it until a new bytes type is introduced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 From noreply at sourceforge.net Tue Nov 2 20:19:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 2 20:19:12 2004 Subject: [Patches] [ python-Patches-829073 ] ref. manual talks of 'sequence' instead of 'iterable' Message-ID: Patches item #829073, was opened at 2003-10-23 13:51 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=829073&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ref. manual talks of 'sequence' instead of 'iterable' Initial Comment: The language reference of Python 2.3 and the one of Python 2.4a0 says the expression_list in a for statement should yield a sequence. However, it may yield any iterable, so this is not really true. It is correct earlier in the text, since it does say "or other iterable object" earlier. This patch changes the mention of "sequence" to "iterable" in two more occurences of the language reference of the for statement. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-11-02 14:19 Message: Logged In: YES user_id=3066 I've clarified this a bit; as long as we keep the distinction between "iterable object" and "iterator" clear, we're fine. (An object that supports __getitem__() with integer indexes but not __iter__() is perfectly valid as an iterable; iter() is happy with it.) Doc/ref/ref7.tex 1.42, 1.35.16.4 ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-08-07 11:09 Message: Logged In: YES user_id=99874 I'm in favor of the change. Brett's point is valid (that it *also* accepts an object that defines __getitem__ but isn't a valid iterable). But (these days) the key thing is that it should be an iterable. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-10-23 20:44 Message: Logged In: YES user_id=357491 This is slightly touchy wording. It does accept an object that defines __getitem__ and not __iter__, and vice-versa. And since iterables can be thought of as sequences it still basically works. But I have no issue moving over to "iterable", personally. I am going to let someone else weigh in on this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=829073&group_id=5470 From noreply at sourceforge.net Tue Nov 2 20:28:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 2 20:28:15 2004 Subject: [Patches] [ python-Patches-793553 ] urllib SSL authentication docs are wrong Message-ID: Patches item #793553, was opened at 2003-08-22 20:15 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: urllib SSL authentication docs are wrong Initial Comment: urllib docs for URLOpener say: Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. They're not needed, and the certificate is never checked, because _ssl.c doesn't check it (which is documented in the socket.ssl docs). A doc patch is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 14:27 Message: Logged In: YES user_id=21627 Sure, I agree the current documentation is wrong. It would be good to test the feature before correcting the documentation, though. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-31 14:09 Message: Logged In: YES user_id=261020 <Googles for x509> Ah. That appears to be true. In that case, do you agree that the following is still wrong (taken from urllib.URLOpener docs)? Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. You don't need either dict entry for opening most https: URLs. Also, it gives no clue that x509 is for client authentication, and that server authentication is not done. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 12:16 Message: Logged In: YES user_id=21627 Isn't the purpose of these arguments client-side authentication? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 From noreply at sourceforge.net Tue Nov 2 20:28:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 2 20:28:16 2004 Subject: [Patches] [ python-Patches-1031233 ] Clean up discussion of new C thread idiom Message-ID: Patches item #1031233, was opened at 2004-09-20 10:14 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031233&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Clean up discussion of new C thread idiom Initial Comment: In init.tex, the code for the typical idiom for C threads now uses the PyGILState functions. However the preceeding discussion still refers to the need to acquire an interpreter state, etc. Attached is a patch which tries to clean this up a little. I removed the paragraph about interpreter states (which raises the possibility of creating a new interpreter state) since multiple interpreter states are, I believe, incompatible (or at least untested) with PyGILState. It's possible that more of PEP 311 should be included here, particularly the part about having to call PyEval_InitThreads on the main thread before using any of the thread APIs. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-09-23 08:13 Message: Logged In: YES user_id=86307 Changed my added text to refer to Py_NewInterpreter, rather than PyInterpreterState_New. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031233&group_id=5470 From noreply at sourceforge.net Tue Nov 2 20:28:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 2 20:28:25 2004 Subject: [Patches] [ python-Patches-1054715 ] Fix for Unix macro expansion in citetitle Message-ID: Patches item #1054715, was opened at 2004-10-26 13:13 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054715&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Brodie (leogah) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix for Unix macro expansion in citetitle Initial Comment: Fix for bug 867556 (see e.g. http://www.python.org/doc/2.3/lib/module-mailbox.html ) The Unix macro within a citetitle generates bad HTML. As far as I can see, this is the only problem page, and the only one where the attached patch changes the generated HTML. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-10-26 14:51 Message: Logged In: YES user_id=671362 Looks good to me with one exception. Original script is indented with spaces only, but your patch mixes spaces and tabs. Can you repair it? Anyway, thanks for submitting a patch for my bug report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054715&group_id=5470 From noreply at sourceforge.net Tue Nov 2 21:29:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 2 21:29:21 2004 Subject: [Patches] [ python-Patches-1035255 ] Remove CoreServices / CoreFoundation dependencies in core Message-ID: Patches item #1035255, was opened at 2004-09-26 20:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Brett Cannon (bcannon) Summary: Remove CoreServices / CoreFoundation dependencies in core Initial Comment: This patch trims down the Python core on Darwin by making it independent of CoreFoundation and CoreServices. It does this by: Changed linker flags in configure/configure.in Removed the unused PyMac_GetAppletScriptFile Moved the implementation of PyMac_StrError to the MacOS module Moved the implementation of PyMac_GetFullPathname to the Carbon.File module In theory this should make Python start up faster on OS X, but I haven't benchmarked it. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-11-02 12:29 Message: Logged In: YES user_id=357491 OK, I didn't hear from Anthony and he just announced that b2 is going to be cut soon (3.5 hours from now) so I am trying to get clearance to deprecate PyMac_GetAppletScriptFile() in 2.4 so that this can go in first thing in 2.5 . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-29 17:49 Message: Logged In: YES user_id=357491 I am waiting to hear from Anthony on an email I sent him about whether he is okay on me applying this for b2. Otherwise the patch is all ready to be checked in. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-25 23:34 Message: Logged In: YES user_id=139309 Mostly correct. The function is intended to be used from the executable stub of a bundled python application. No known application uses a custom stub, and no stub from an automated tool uses this function. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-25 22:51 Message: Logged In: YES user_id=357491 So it is undocumented, only references to it from Google point to Python's own CVS, and it is meant for internal use for building bundles that is supposed to be automated anyway. Missing anything there? That sounds like enough to me to drop it since it is a hinderance to solving this bug. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-25 20:35 Message: Logged In: YES user_id=139309 99.5% sure nothing else uses it. It's only useful from a bundled application. I don't know a single Python application that creates a bundle manually. All published methods for creating a Python bundle use a stub that's either pure python (bundlebuilder, BuildApplet), or descendent of the Objective C stub I wrote for the PyObjC Xcode template (incl. py2app). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-25 19:59 Message: Logged In: YES user_id=357491 OK, I have a cleaned up version of the patch ready to be checked in, but I realized that it changes the API by removing PyMac_GetAppletScriptFile(). While googling seems to suggest it is not used by anyone, it still changes the API. How sure are you that no one uses it? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-23 15:39 Message: Logged In: YES user_id=139309 Raymond said to bump the priority. It is definitely a bugfix not a feature, though. No, it definitely does not remove all linking to CF, just from the core. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-23 13:21 Message: Logged In: YES user_id=357491 Bob, did Anthony OK the priority bump? I need to decide whether this is a bugfix or feature and thus go into b2. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-23 12:49 Message: Logged In: YES user_id=357491 Note that this would close bug #1034277 . Also realize that it does not remove all linking against CF; if you look in setup.py you will notice that a few modules (including _locale) still need to link against CoreFoundation. This patch is just to remove the dependence on the core, not extension modules. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-20 14:16 Message: Logged In: YES user_id=139309 It certainly won't solve the test__locale issue, but it *might* make it intermittent depending on what you've imported ;) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-20 14:14 Message: Logged In: YES user_id=357491 I will see if I can get to this over the weekend. Might take a while since I am not familiar with much of the MacPython stuff beyond the UNIX- level issues. Until then, I am wondering if this will help solve test__locale from failing since the C locale should no longer be locked down since compilation against CF was what was causing trouble in the first place. And I need to remember to regenerate configure with autoconf 2.58 (not 2.57 as is included with OS X!). DarwinPorts to the rescue. =) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 From noreply at sourceforge.net Tue Nov 2 21:51:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 2 21:51:17 2004 Subject: [Patches] [ python-Patches-1035255 ] Remove CoreServices / CoreFoundation dependencies in core Message-ID: Patches item #1035255, was opened at 2004-09-27 05:44 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Brett Cannon (bcannon) Summary: Remove CoreServices / CoreFoundation dependencies in core Initial Comment: This patch trims down the Python core on Darwin by making it independent of CoreFoundation and CoreServices. It does this by: Changed linker flags in configure/configure.in Removed the unused PyMac_GetAppletScriptFile Moved the implementation of PyMac_StrError to the MacOS module Moved the implementation of PyMac_GetFullPathname to the Carbon.File module In theory this should make Python start up faster on OS X, but I haven't benchmarked it. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2004-11-02 21:51 Message: Logged In: YES user_id=92689 It's Jack's call, but my opinion is that just ripping it out is fine, even if it's after b2. No need to go through a whole deprecation phase. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-11-02 21:29 Message: Logged In: YES user_id=357491 OK, I didn't hear from Anthony and he just announced that b2 is going to be cut soon (3.5 hours from now) so I am trying to get clearance to deprecate PyMac_GetAppletScriptFile() in 2.4 so that this can go in first thing in 2.5 . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-30 02:49 Message: Logged In: YES user_id=357491 I am waiting to hear from Anthony on an email I sent him about whether he is okay on me applying this for b2. Otherwise the patch is all ready to be checked in. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-26 08:34 Message: Logged In: YES user_id=139309 Mostly correct. The function is intended to be used from the executable stub of a bundled python application. No known application uses a custom stub, and no stub from an automated tool uses this function. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-26 07:51 Message: Logged In: YES user_id=357491 So it is undocumented, only references to it from Google point to Python's own CVS, and it is meant for internal use for building bundles that is supposed to be automated anyway. Missing anything there? That sounds like enough to me to drop it since it is a hinderance to solving this bug. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-26 05:35 Message: Logged In: YES user_id=139309 99.5% sure nothing else uses it. It's only useful from a bundled application. I don't know a single Python application that creates a bundle manually. All published methods for creating a Python bundle use a stub that's either pure python (bundlebuilder, BuildApplet), or descendent of the Objective C stub I wrote for the PyObjC Xcode template (incl. py2app). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-26 04:59 Message: Logged In: YES user_id=357491 OK, I have a cleaned up version of the patch ready to be checked in, but I realized that it changes the API by removing PyMac_GetAppletScriptFile(). While googling seems to suggest it is not used by anyone, it still changes the API. How sure are you that no one uses it? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-24 00:39 Message: Logged In: YES user_id=139309 Raymond said to bump the priority. It is definitely a bugfix not a feature, though. No, it definitely does not remove all linking to CF, just from the core. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-23 22:21 Message: Logged In: YES user_id=357491 Bob, did Anthony OK the priority bump? I need to decide whether this is a bugfix or feature and thus go into b2. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-23 21:49 Message: Logged In: YES user_id=357491 Note that this would close bug #1034277 . Also realize that it does not remove all linking against CF; if you look in setup.py you will notice that a few modules (including _locale) still need to link against CoreFoundation. This patch is just to remove the dependence on the core, not extension modules. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-20 23:16 Message: Logged In: YES user_id=139309 It certainly won't solve the test__locale issue, but it *might* make it intermittent depending on what you've imported ;) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-20 23:14 Message: Logged In: YES user_id=357491 I will see if I can get to this over the weekend. Might take a while since I am not familiar with much of the MacPython stuff beyond the UNIX- level issues. Until then, I am wondering if this will help solve test__locale from failing since the C locale should no longer be locked down since compilation against CF was what was causing trouble in the first place. And I need to remember to regenerate configure with autoconf 2.58 (not 2.57 as is included with OS X!). DarwinPorts to the rescue. =) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 From noreply at sourceforge.net Tue Nov 2 23:20:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 2 23:20:59 2004 Subject: [Patches] [ python-Patches-1054967 ] bdist_deb - Debian packager Message-ID: Patches item #1054967, was opened at 2004-10-26 17:48 Message generated for change (Comment added) made by dairiki You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 Category: Distutils and setup.py Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Sean Reifschneider (jafo) Summary: bdist_deb - Debian packager Initial Comment: Here's a first crack at a bdist_deb. This patch implements two new distutils commands: bdist_deb: Build Debian packages debianize: Create and populate a top-level debian subdirectory. (Essentially dh_make for distutils packages.) There is a slightly detailed README.bdist_deb included in the patches. I'm open to suggestions for improvements and bug-fixes. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-02 14:20 Message: Logged In: YES user_id=45814 Here's try number three! Changes are mostly fixes for woody. The README.bdist_deb (included in the patch set) enumerates the changes in more detail. (I've bitten the bullet and installed woody on one of my machines, so I'm fairly confident it should work now.) The patches, on todays CVS are, as always, attached below. ==== Note to Davide, Thank you, again, very much for all the testing. A couple of the lintian warnings ('prerm-does-not-remove-usr-doc-link' and 'postinst-does-not-set-usr-doc-link') that are listed in your test suite output are due, I think, to your mixed system. Specifically, I suspect you've got the woody version of lintian (which wants to see symlinks from /usr/doc/ to /usr/share/doc/), but a later version of debhelper. (Woody's dh_installdocs (in the debhelper package) automatically generates those links, later versions don't; /usr/doc has been phased out.) Anyhow, I'm not going to fix those warnings (unless it turns out that you're seeing them on your pure woody system.) On package with python scripts (in /usr/bin) Woody's lintian generates an 'unusual-interpreter' warning which I think is spurious (i.e. it is not a valid warning.) (Lintian 1.20.17 doesn't recognize things like /usr/bin/python2.1 as a valid interpreter --- it seems valid enough to me.) Best Regards, Jeff ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-30 01:57 Message: Logged In: YES user_id=170840 I've tried the 29/10 patch with my home system (dpkg-dev 1.10, debhelper 4.1.90 and dh-make 0.30) and another "pure woody" system (dpkg-dev 1.9.21, debhelper 4.0.2 and dh-make 0.30). I've used your test suite and some of my personal projects (using both bdist_deb and dh_make); as far as I can tell, it works very well. :-) bdist_deb always worked as expected, producing good debian packages. I've used dh_make and then I've run "dpkg-buildpackage -rfakeroot" and I got some errors (but I'm not sure they depends on your code). Also your test suite produced some failures. Here you can find the output of "dpkg-buildpackage -rfakeroot" and of your tests suite (both were running on my home system): http://erlug.linux.it/~da/tmp/dpkg-buildpackage http://erlug.linux.it/~da/tmp/testsuite Thank you for your great effort! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-10-29 12:38 Message: Logged In: YES user_id=45814 Thanks for the comments. Here's a second attempt. Changes include: It might work with woody. (I'd appreciate it if you could try again, Davide) 'debianize' command renamed to 'dh_make'. Use debchange to create debian/changelog. This eliminates the need to duplicate debchange's logic to deduce the packagers name and e-mail. A more complete test script. Patches are on today's CVS. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-27 07:47 Message: Logged In: YES user_id=170840 I've a woody with some packages backported from sarge (debhelper 4.1.90 and dpkg-dev 1.10). Running python2.3 ./setup.py bdist_deb with some of my projects, I got the error: dpkg-buildpackage: unknown option or argument --check-dirname-level=1 Debian dpkg-buildpackage . Commenting out the "check-dirname-level" and "check-dirname-regex" options in the bdist_deb.py file the script can go on, but it exits with the error: debian/rules:11: *** first argument to `word' function must be greater than 0. Stop. Hope this helps. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-10-26 20:44 Message: Logged In: YES user_id=81797 I'm just doing a review of this code. A couple of things: There's been some concern expressed about get_default_maintainer. Namely, that if debchange changes it's algorithm, it won't be reflected in this code. It seems like one possible way around that would be to build a directory with a "debian" directory under it, a fake "changelog", and then call debchange to write the data out, and parse it. Too bad there's not a direct hook into debchange to get that information. Can _formatdate, if email doesn't exist, use rfc822.formatdate()? Ditto for _parseaddr? It looks pretty good. However, when trying to build a .deb of my jotweb2 package, it's failing with: [...] dh_testdir dh_testroot dh_installchangelogs- dh_installdocs cp: cannot stat `doc': No such file or directory dh_installdocs: command returned error code 256 [...] I'm not sure exactly why. I do have a "doc" directory in my main package directory, but I don't reference to it in my setup.py or MANIFEST. Adding it to the MANIFEST doesn't seem to help this. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 From noreply at sourceforge.net Wed Nov 3 03:59:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 3 04:00:11 2004 Subject: [Patches] [ python-Patches-1054715 ] Fix for Unix macro expansion in citetitle Message-ID: Patches item #1054715, was opened at 2004-10-26 13:13 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054715&group_id=5470 Category: Documentation >Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Richard Brodie (leogah) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix for Unix macro expansion in citetitle Initial Comment: Fix for bug 867556 (see e.g. http://www.python.org/doc/2.3/lib/module-mailbox.html ) The Unix macro within a citetitle generates bad HTML. As far as I can see, this is the only problem page, and the only one where the attached patch changes the generated HTML. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-11-02 21:59 Message: Logged In: YES user_id=3066 Good catch; thanks! The patch looks good; I'll commit to the trunk and release23-maint branch once the release freeze for Python 2.4b2 is over. And if I don't get this done this weekend, someone with commit privs can just do it. (Anyone else can remind me about it via email.) ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-10-26 14:51 Message: Logged In: YES user_id=671362 Looks good to me with one exception. Original script is indented with spaces only, but your patch mixes spaces and tabs. Can you repair it? Anyway, thanks for submitting a patch for my bug report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054715&group_id=5470 From noreply at sourceforge.net Thu Nov 4 04:30:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 4 04:30:42 2004 Subject: [Patches] [ python-Patches-1054715 ] Fix for Unix macro expansion in citetitle Message-ID: Patches item #1054715, was opened at 2004-10-26 13:13 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054715&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Richard Brodie (leogah) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix for Unix macro expansion in citetitle Initial Comment: Fix for bug 867556 (see e.g. http://www.python.org/doc/2.3/lib/module-mailbox.html ) The Unix macro within a citetitle generates bad HTML. As far as I can see, this is the only problem page, and the only one where the attached patch changes the generated HTML. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-11-03 22:30 Message: Logged In: YES user_id=3066 Committed; thanks! Doc/perl/python.perl 1.151, 1.137.8.4 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-11-02 21:59 Message: Logged In: YES user_id=3066 Good catch; thanks! The patch looks good; I'll commit to the trunk and release23-maint branch once the release freeze for Python 2.4b2 is over. And if I don't get this done this weekend, someone with commit privs can just do it. (Anyone else can remind me about it via email.) ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-10-26 14:51 Message: Logged In: YES user_id=671362 Looks good to me with one exception. Original script is indented with spaces only, but your patch mixes spaces and tabs. Can you repair it? Anyway, thanks for submitting a patch for my bug report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054715&group_id=5470 From noreply at sourceforge.net Thu Nov 4 23:28:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 4 23:28:57 2004 Subject: [Patches] [ python-Patches-1060577 ] bdist_rpm not able to compile multiple rpm packages Message-ID: Patches item #1060577, was opened at 2004-11-04 17: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=1060577&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm not able to compile multiple rpm packages Initial Comment: bdist_rpm tries to deal with debuginfo packages by naming them in the source. Just as debuginfo packages are artifacts of a buildystem, one can modify the buildsystem to create various other rpms even though the spec file only creates one. The attached patch tries to approach the solution in a more general way, by looking at the spec file and extracting the names of rpms that are going to be generated. This patch has been posted at some point on the distutils-sig mailing list: http://mail.python.org/pipermail/distutils-sig/2004-June/003953.html I assumed it already made it in, apparently not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1060577&group_id=5470 From noreply at sourceforge.net Fri Nov 5 06:23:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 5 06:23:28 2004 Subject: [Patches] [ python-Patches-1035255 ] Remove CoreServices / CoreFoundation dependencies in core Message-ID: Patches item #1035255, was opened at 2004-09-26 20:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Brett Cannon (bcannon) Summary: Remove CoreServices / CoreFoundation dependencies in core Initial Comment: This patch trims down the Python core on Darwin by making it independent of CoreFoundation and CoreServices. It does this by: Changed linker flags in configure/configure.in Removed the unused PyMac_GetAppletScriptFile Moved the implementation of PyMac_StrError to the MacOS module Moved the implementation of PyMac_GetFullPathname to the Carbon.File module In theory this should make Python start up faster on OS X, but I haven't benchmarked it. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-11-04 21:23 Message: Logged In: YES user_id=357491 Where is Jack? Have not heard from him in ages. I have uploaded my version of the patch so that if someone decided to step over me and apply the patch they can. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-02 12:51 Message: Logged In: YES user_id=92689 It's Jack's call, but my opinion is that just ripping it out is fine, even if it's after b2. No need to go through a whole deprecation phase. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-11-02 12:29 Message: Logged In: YES user_id=357491 OK, I didn't hear from Anthony and he just announced that b2 is going to be cut soon (3.5 hours from now) so I am trying to get clearance to deprecate PyMac_GetAppletScriptFile() in 2.4 so that this can go in first thing in 2.5 . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-29 17:49 Message: Logged In: YES user_id=357491 I am waiting to hear from Anthony on an email I sent him about whether he is okay on me applying this for b2. Otherwise the patch is all ready to be checked in. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-25 23:34 Message: Logged In: YES user_id=139309 Mostly correct. The function is intended to be used from the executable stub of a bundled python application. No known application uses a custom stub, and no stub from an automated tool uses this function. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-25 22:51 Message: Logged In: YES user_id=357491 So it is undocumented, only references to it from Google point to Python's own CVS, and it is meant for internal use for building bundles that is supposed to be automated anyway. Missing anything there? That sounds like enough to me to drop it since it is a hinderance to solving this bug. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-25 20:35 Message: Logged In: YES user_id=139309 99.5% sure nothing else uses it. It's only useful from a bundled application. I don't know a single Python application that creates a bundle manually. All published methods for creating a Python bundle use a stub that's either pure python (bundlebuilder, BuildApplet), or descendent of the Objective C stub I wrote for the PyObjC Xcode template (incl. py2app). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-25 19:59 Message: Logged In: YES user_id=357491 OK, I have a cleaned up version of the patch ready to be checked in, but I realized that it changes the API by removing PyMac_GetAppletScriptFile(). While googling seems to suggest it is not used by anyone, it still changes the API. How sure are you that no one uses it? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-23 15:39 Message: Logged In: YES user_id=139309 Raymond said to bump the priority. It is definitely a bugfix not a feature, though. No, it definitely does not remove all linking to CF, just from the core. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-23 13:21 Message: Logged In: YES user_id=357491 Bob, did Anthony OK the priority bump? I need to decide whether this is a bugfix or feature and thus go into b2. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-23 12:49 Message: Logged In: YES user_id=357491 Note that this would close bug #1034277 . Also realize that it does not remove all linking against CF; if you look in setup.py you will notice that a few modules (including _locale) still need to link against CoreFoundation. This patch is just to remove the dependence on the core, not extension modules. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-20 14:16 Message: Logged In: YES user_id=139309 It certainly won't solve the test__locale issue, but it *might* make it intermittent depending on what you've imported ;) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-20 14:14 Message: Logged In: YES user_id=357491 I will see if I can get to this over the weekend. Might take a while since I am not familiar with much of the MacPython stuff beyond the UNIX- level issues. Until then, I am wondering if this will help solve test__locale from failing since the C locale should no longer be locked down since compilation against CF was what was causing trouble in the first place. And I need to remember to regenerate configure with autoconf 2.58 (not 2.57 as is included with OS X!). DarwinPorts to the rescue. =) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 From noreply at sourceforge.net Fri Nov 5 06:25:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 5 06:25:21 2004 Subject: [Patches] [ python-Patches-1035255 ] Remove CoreServices / CoreFoundation dependencies in core Message-ID: Patches item #1035255, was opened at 2004-09-26 23:44 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Brett Cannon (bcannon) Summary: Remove CoreServices / CoreFoundation dependencies in core Initial Comment: This patch trims down the Python core on Darwin by making it independent of CoreFoundation and CoreServices. It does this by: Changed linker flags in configure/configure.in Removed the unused PyMac_GetAppletScriptFile Moved the implementation of PyMac_StrError to the MacOS module Moved the implementation of PyMac_GetFullPathname to the Carbon.File module In theory this should make Python start up faster on OS X, but I haven't benchmarked it. ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2004-11-05 00:25 Message: Logged In: YES user_id=139309 he's been really busy.. he probably isn't going to many any noise here ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-11-05 00:23 Message: Logged In: YES user_id=357491 Where is Jack? Have not heard from him in ages. I have uploaded my version of the patch so that if someone decided to step over me and apply the patch they can. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-02 15:51 Message: Logged In: YES user_id=92689 It's Jack's call, but my opinion is that just ripping it out is fine, even if it's after b2. No need to go through a whole deprecation phase. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-11-02 15:29 Message: Logged In: YES user_id=357491 OK, I didn't hear from Anthony and he just announced that b2 is going to be cut soon (3.5 hours from now) so I am trying to get clearance to deprecate PyMac_GetAppletScriptFile() in 2.4 so that this can go in first thing in 2.5 . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-29 20:49 Message: Logged In: YES user_id=357491 I am waiting to hear from Anthony on an email I sent him about whether he is okay on me applying this for b2. Otherwise the patch is all ready to be checked in. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-26 02:34 Message: Logged In: YES user_id=139309 Mostly correct. The function is intended to be used from the executable stub of a bundled python application. No known application uses a custom stub, and no stub from an automated tool uses this function. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-26 01:51 Message: Logged In: YES user_id=357491 So it is undocumented, only references to it from Google point to Python's own CVS, and it is meant for internal use for building bundles that is supposed to be automated anyway. Missing anything there? That sounds like enough to me to drop it since it is a hinderance to solving this bug. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-25 23:35 Message: Logged In: YES user_id=139309 99.5% sure nothing else uses it. It's only useful from a bundled application. I don't know a single Python application that creates a bundle manually. All published methods for creating a Python bundle use a stub that's either pure python (bundlebuilder, BuildApplet), or descendent of the Objective C stub I wrote for the PyObjC Xcode template (incl. py2app). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-25 22:59 Message: Logged In: YES user_id=357491 OK, I have a cleaned up version of the patch ready to be checked in, but I realized that it changes the API by removing PyMac_GetAppletScriptFile(). While googling seems to suggest it is not used by anyone, it still changes the API. How sure are you that no one uses it? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-23 18:39 Message: Logged In: YES user_id=139309 Raymond said to bump the priority. It is definitely a bugfix not a feature, though. No, it definitely does not remove all linking to CF, just from the core. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-23 16:21 Message: Logged In: YES user_id=357491 Bob, did Anthony OK the priority bump? I need to decide whether this is a bugfix or feature and thus go into b2. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-23 15:49 Message: Logged In: YES user_id=357491 Note that this would close bug #1034277 . Also realize that it does not remove all linking against CF; if you look in setup.py you will notice that a few modules (including _locale) still need to link against CoreFoundation. This patch is just to remove the dependence on the core, not extension modules. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-20 17:16 Message: Logged In: YES user_id=139309 It certainly won't solve the test__locale issue, but it *might* make it intermittent depending on what you've imported ;) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-20 17:14 Message: Logged In: YES user_id=357491 I will see if I can get to this over the weekend. Might take a while since I am not familiar with much of the MacPython stuff beyond the UNIX- level issues. Until then, I am wondering if this will help solve test__locale from failing since the C locale should no longer be locked down since compilation against CF was what was causing trouble in the first place. And I need to remember to regenerate configure with autoconf 2.58 (not 2.57 as is included with OS X!). DarwinPorts to the rescue. =) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 From noreply at sourceforge.net Fri Nov 5 08:03:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 5 08:16:46 2004 Subject: [Patches] [ python-Patches-1035255 ] Remove CoreServices / CoreFoundation dependencies in core Message-ID: Patches item #1035255, was opened at 2004-09-26 22:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 Category: Macintosh Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Brett Cannon (bcannon) Summary: Remove CoreServices / CoreFoundation dependencies in core Initial Comment: This patch trims down the Python core on Darwin by making it independent of CoreFoundation and CoreServices. It does this by: Changed linker flags in configure/configure.in Removed the unused PyMac_GetAppletScriptFile Moved the implementation of PyMac_StrError to the MacOS module Moved the implementation of PyMac_GetFullPathname to the Carbon.File module In theory this should make Python start up faster on OS X, but I haven't benchmarked it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-05 02:03 Message: Logged In: YES user_id=80475 Applied. Bob, thx for the patch. Brett, thx for testing. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-11-05 00:25 Message: Logged In: YES user_id=139309 he's been really busy.. he probably isn't going to many any noise here ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-11-05 00:23 Message: Logged In: YES user_id=357491 Where is Jack? Have not heard from him in ages. I have uploaded my version of the patch so that if someone decided to step over me and apply the patch they can. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-02 15:51 Message: Logged In: YES user_id=92689 It's Jack's call, but my opinion is that just ripping it out is fine, even if it's after b2. No need to go through a whole deprecation phase. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-11-02 15:29 Message: Logged In: YES user_id=357491 OK, I didn't hear from Anthony and he just announced that b2 is going to be cut soon (3.5 hours from now) so I am trying to get clearance to deprecate PyMac_GetAppletScriptFile() in 2.4 so that this can go in first thing in 2.5 . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-29 19:49 Message: Logged In: YES user_id=357491 I am waiting to hear from Anthony on an email I sent him about whether he is okay on me applying this for b2. Otherwise the patch is all ready to be checked in. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-26 01:34 Message: Logged In: YES user_id=139309 Mostly correct. The function is intended to be used from the executable stub of a bundled python application. No known application uses a custom stub, and no stub from an automated tool uses this function. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-26 00:51 Message: Logged In: YES user_id=357491 So it is undocumented, only references to it from Google point to Python's own CVS, and it is meant for internal use for building bundles that is supposed to be automated anyway. Missing anything there? That sounds like enough to me to drop it since it is a hinderance to solving this bug. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-25 22:35 Message: Logged In: YES user_id=139309 99.5% sure nothing else uses it. It's only useful from a bundled application. I don't know a single Python application that creates a bundle manually. All published methods for creating a Python bundle use a stub that's either pure python (bundlebuilder, BuildApplet), or descendent of the Objective C stub I wrote for the PyObjC Xcode template (incl. py2app). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-25 21:59 Message: Logged In: YES user_id=357491 OK, I have a cleaned up version of the patch ready to be checked in, but I realized that it changes the API by removing PyMac_GetAppletScriptFile(). While googling seems to suggest it is not used by anyone, it still changes the API. How sure are you that no one uses it? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-23 17:39 Message: Logged In: YES user_id=139309 Raymond said to bump the priority. It is definitely a bugfix not a feature, though. No, it definitely does not remove all linking to CF, just from the core. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-23 15:21 Message: Logged In: YES user_id=357491 Bob, did Anthony OK the priority bump? I need to decide whether this is a bugfix or feature and thus go into b2. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-23 14:49 Message: Logged In: YES user_id=357491 Note that this would close bug #1034277 . Also realize that it does not remove all linking against CF; if you look in setup.py you will notice that a few modules (including _locale) still need to link against CoreFoundation. This patch is just to remove the dependence on the core, not extension modules. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-20 16:16 Message: Logged In: YES user_id=139309 It certainly won't solve the test__locale issue, but it *might* make it intermittent depending on what you've imported ;) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-10-20 16:14 Message: Logged In: YES user_id=357491 I will see if I can get to this over the weekend. Might take a while since I am not familiar with much of the MacPython stuff beyond the UNIX- level issues. Until then, I am wondering if this will help solve test__locale from failing since the C locale should no longer be locked down since compilation against CF was what was causing trouble in the first place. And I need to remember to regenerate configure with autoconf 2.58 (not 2.57 as is included with OS X!). DarwinPorts to the rescue. =) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 From noreply at sourceforge.net Sat Nov 6 08:40:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 6 08:40:19 2004 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 19:55 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2004-11-06 08:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Sat Nov 6 10:19:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 6 10:19:22 2004 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 10:55 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 01:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-05 23:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Sat Nov 6 10:43:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 6 10:43:57 2004 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 19:55 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2004-11-06 10:43 Message: Logged In: YES user_id=92689 I just wanted to check whether the author _knows_ smtpd.py, since he doesn't mention it. Maybe I should put it more bluntly: What's the benefit of having an incompatible, less featureful, threaded version of smtpd.py in the library? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 10:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 08:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Sun Nov 7 00:03:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 00:03:46 2004 Subject: [Patches] [ python-Patches-1061679 ] add missing __all__ to pickletools.py Message-ID: Patches item #1061679, was opened at 2004-11-07 08: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=1061679&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: add missing __all__ to pickletools.py Initial Comment: pickletools.py module has its own document and only two functions are documented there for external use. However, __all__ is not defined in pickletools.py. : $ python -c 'from pickletools import *;print len(globals ())' 60 Setting the __all__ variable seems reasonable to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061679&group_id=5470 From noreply at sourceforge.net Sun Nov 7 00:47:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 00:47:26 2004 Subject: [Patches] [ python-Patches-1061679 ] add missing __all__ to pickletools.py Message-ID: Patches item #1061679, was opened at 2004-11-06 18:03 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061679&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: add missing __all__ to pickletools.py Initial Comment: pickletools.py module has its own document and only two functions are documented there for external use. However, __all__ is not defined in pickletools.py. : $ python -c 'from pickletools import *;print len(globals ())' 60 Setting the __all__ variable seems reasonable to me. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-11-06 18:47 Message: Logged In: YES user_id=31435 Yup, that's a good idea. I didn't realize this was a patch at first, so I just did it. It's a lot like your patch . Lib/pickletools.py 1.28 Lib/test/test___all__.py 1.41 Misc/NEWS 1.1184 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061679&group_id=5470 From noreply at sourceforge.net Sun Nov 7 05:26:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 05:26:21 2004 Subject: [Patches] [ python-Patches-1061767 ] fix for bug 1055168 (pdb not entering the right frame) Message-ID: Patches item #1061767, was opened at 2004-11-06 20:26 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=1061767&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 1055168 (pdb not entering the right frame) Initial Comment: Bdb.set_trace() assumed that the frame which needs to be debugged is the caller's frame. This assumption fails if Bdb_set_trace() is called from inside a debugger (say from inside of a pdb's set_trace). So now Bdb.set_trace() accepts an optional parameter frame_to_debug which allows the caller to specify which frame needs to be debugged, and pdb is modified to use it.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061767&group_id=5470 From noreply at sourceforge.net Sun Nov 7 05:42:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 05:42:33 2004 Subject: [Patches] [ python-Patches-1061767 ] fix for bug 1055168 (pdb not entering the right frame) Message-ID: Patches item #1061767, was opened at 2004-11-06 20:26 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061767&group_id=5470 >Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 1055168 (pdb not entering the right frame) Initial Comment: Bdb.set_trace() assumed that the frame which needs to be debugged is the caller's frame. This assumption fails if Bdb_set_trace() is called from inside a debugger (say from inside of a pdb's set_trace). So now Bdb.set_trace() accepts an optional parameter frame_to_debug which allows the caller to specify which frame needs to be debugged, and pdb is modified to use it.. ---------------------------------------------------------------------- >Comment By: Ilya Sandler (isandler) Date: 2004-11-06 20:42 Message: Logged In: YES user_id=971153 The original bug report gives an example where the code to debug was specified from python's shell. I am not quite how pdb is supposed to behave in this case.. With the patch, it does seem to enter in the right frame, but it can't list the code. The patch does work when the code comes from a file. .def foo(): import pdb pdb.set_trace() print "tracing 1" print "tracing 2" foo() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061767&group_id=5470 From noreply at sourceforge.net Sun Nov 7 07:02:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 07:02:55 2004 Subject: [Patches] [ python-Patches-1061780 ] use a new -m option in pdb and profile invocations Message-ID: Patches item #1061780, was opened at 2004-11-06 22: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=1061780&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: use a new -m option in pdb and profile invocations Initial Comment: The old way (described in current docs) to invoke pdb and profile as script is like this python /usr/local/lib/python1.5/pdb.py myscript.py With a new -m python option, there is now a better way to do that. python -m pdb myscript.py Hence the doc update.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061780&group_id=5470 From noreply at sourceforge.net Sun Nov 7 07:18:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 07:18:55 2004 Subject: [Patches] [ python-Patches-1061780 ] use a new -m option in pdb and profile invocations Message-ID: Patches item #1061780, was opened at 2004-11-07 01:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061780&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: use a new -m option in pdb and profile invocations Initial Comment: The old way (described in current docs) to invoke pdb and profile as script is like this python /usr/local/lib/python1.5/pdb.py myscript.py With a new -m python option, there is now a better way to do that. python -m pdb myscript.py Hence the doc update.. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-07 01:18 Message: Logged In: YES user_id=80475 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061780&group_id=5470 From noreply at sourceforge.net Sun Nov 7 08:11:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 08:11:18 2004 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 12:55 Message generated for change (Comment added) made by mdr0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- >Comment By: Mark D. Roth (mdr0) Date: 2004-11-07 01:11 Message: Logged In: YES user_id=994239 Yes, I am aware of smtpd.py. My understanding is (although please correct me if I'm wrong) that the asyncore/asynchat framework will not be able to service network clients if the found_terminator() method performs an operation that blocks. The BaseSMTPServer class doesn't suffer from that problem, because it's threaded. If you're interested in integrating this module, I'd be happy to clean it up to conform with the Python style guidelines, add documentation, and implement the allow_host() method. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 03:43 Message: Logged In: YES user_id=92689 I just wanted to check whether the author _knows_ smtpd.py, since he doesn't mention it. Maybe I should put it more bluntly: What's the benefit of having an incompatible, less featureful, threaded version of smtpd.py in the library? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 03:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 01:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Sun Nov 7 09:19:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 09:19:50 2004 Subject: [Patches] [ python-Patches-1061803 ] Source code encoding in IDLE console Message-ID: Patches item #1061803, was opened at 2004-11-07 17:19 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=1061803&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Source code encoding in IDLE console Initial Comment: Source code encoding is ignored in IDLE console sessions currently. To allow to use encodings other than Latin-1, encoding marker must be added before passing it to tokenizers. (see the attached patch) current behavior: >>> u'한글' u'\xc7\xd1\xb1\xdb' this must be like ... >>> u'한글' u'\ud55c\uae00' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061803&group_id=5470 From noreply at sourceforge.net Sun Nov 7 11:20:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 11:21:06 2004 Subject: [Patches] [ python-Patches-1061803 ] Source code encoding in IDLE console Message-ID: Patches item #1061803, was opened at 2004-11-07 09:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061803&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Source code encoding in IDLE console Initial Comment: Source code encoding is ignored in IDLE console sessions currently. To allow to use encodings other than Latin-1, encoding marker must be added before passing it to tokenizers. (see the attached patch) current behavior: >>> u'한글' u'\xc7\xd1\xb1\xdb' this must be like ... >>> u'한글' u'\ud55c\uae00' ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-11-07 11:20 Message: Logged In: YES user_id=21627 I think the patch is wrong, as it messes with the source code typed. At a minimum, line number will be off by one, no? I'm currently working on a different solution, allowing compile() to accept an encoding. However, it is too late to add this to 2.4 now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061803&group_id=5470 From noreply at sourceforge.net Sun Nov 7 12:37:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 12:38:03 2004 Subject: [Patches] [ python-Patches-1061767 ] fix for bug 1055168 (pdb not entering the right frame) Message-ID: Patches item #1061767, was opened at 2004-11-07 05:26 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061767&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 1055168 (pdb not entering the right frame) Initial Comment: Bdb.set_trace() assumed that the frame which needs to be debugged is the caller's frame. This assumption fails if Bdb_set_trace() is called from inside a debugger (say from inside of a pdb's set_trace). So now Bdb.set_trace() accepts an optional parameter frame_to_debug which allows the caller to specify which frame needs to be debugged, and pdb is modified to use it.. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 12:37 Message: Logged In: YES user_id=469548 That's normal: pdb can never list code that was input on a console. A coworker of mine (Jeroen Vloothuis) and I beautified the code a bit, and I checked it in as rev 1.73 of pdb.py and rev 1.47 of bdb.py. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-11-07 05:42 Message: Logged In: YES user_id=971153 The original bug report gives an example where the code to debug was specified from python's shell. I am not quite how pdb is supposed to behave in this case.. With the patch, it does seem to enter in the right frame, but it can't list the code. The patch does work when the code comes from a file. .def foo(): import pdb pdb.set_trace() print "tracing 1" print "tracing 2" foo() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061767&group_id=5470 From noreply at sourceforge.net Sun Nov 7 12:39:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 12:39:13 2004 Subject: [Patches] [ python-Patches-1061767 ] fix for bug 1055168 (pdb not entering the right frame) Message-ID: Patches item #1061767, was opened at 2004-11-07 05:26 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061767&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 1055168 (pdb not entering the right frame) Initial Comment: Bdb.set_trace() assumed that the frame which needs to be debugged is the caller's frame. This assumption fails if Bdb_set_trace() is called from inside a debugger (say from inside of a pdb's set_trace). So now Bdb.set_trace() accepts an optional parameter frame_to_debug which allows the caller to specify which frame needs to be debugged, and pdb is modified to use it.. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 12:37 Message: Logged In: YES user_id=469548 That's normal: pdb can never list code that was input on a console. A coworker of mine (Jeroen Vloothuis) and I beautified the code a bit, and I checked it in as rev 1.73 of pdb.py and rev 1.47 of bdb.py. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-11-07 05:42 Message: Logged In: YES user_id=971153 The original bug report gives an example where the code to debug was specified from python's shell. I am not quite how pdb is supposed to behave in this case.. With the patch, it does seem to enter in the right frame, but it can't list the code. The patch does work when the code comes from a file. .def foo(): import pdb pdb.set_trace() print "tracing 1" print "tracing 2" foo() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061767&group_id=5470 From noreply at sourceforge.net Sun Nov 7 13:46:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 13:46:56 2004 Subject: [Patches] [ python-Patches-1061882 ] [ 1061857 ] Error and omission in logging docs Message-ID: Patches item #1061882, was opened at 2004-11-07 13:46 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=1061882&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeroen Vloothuis (slmm) Assigned to: Nobody/Anonymous (nobody) Summary: [ 1061857 ] Error and omission in logging docs Initial Comment: The patch attached below adds the section for the TimedRotatingLogging class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061882&group_id=5470 From noreply at sourceforge.net Sun Nov 7 14:01:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 14:01:50 2004 Subject: [Patches] [ python-Patches-1061803 ] Source code encoding in IDLE console Message-ID: Patches item #1061803, was opened at 2004-11-07 17:19 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061803&group_id=5470 Category: IDLE >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Source code encoding in IDLE console Initial Comment: Source code encoding is ignored in IDLE console sessions currently. To allow to use encodings other than Latin-1, encoding marker must be added before passing it to tokenizers. (see the attached patch) current behavior: >>> u'한글' u'\xc7\xd1\xb1\xdb' this must be like ... >>> u'한글' u'\ud55c\uae00' ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-11-07 22:01 Message: Logged In: YES user_id=55188 Surprisingly, it doesn't affect source code lines. But, I'm still wondering why it isn't counted as a distinct line. :) >>> raise ValueError Traceback (most recent call last): File "", line 1, in -toplevel- raise ValueError ValueError >>> if 1: pass raise ValueError Traceback (most recent call last): File "", line 3, in -toplevel- raise ValueError ValueError Okay. I agree that it's too late to change behavior, but it may need to write some errata item about this inconsistency of IDLE vs terminal interactive mode on documentation. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-07 19:20 Message: Logged In: YES user_id=21627 I think the patch is wrong, as it messes with the source code typed. At a minimum, line number will be off by one, no? I'm currently working on a different solution, allowing compile() to accept an encoding. However, it is too late to add this to 2.4 now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061803&group_id=5470 From noreply at sourceforge.net Sun Nov 7 14:30:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 14:30:10 2004 Subject: [Patches] [ python-Patches-1061904 ] fix for bug 878275 class MyTest(unittest.TestSuite) Message-ID: Patches item #1061904, was opened at 2004-11-07 14: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=1061904&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 878275 class MyTest(unittest.TestSuite) Initial Comment: The docs on unittest, and the code comments, all seem to indicate that testcases must be derived from unittest.TestCase. So to avoid strange errors, the TestLoader now checks this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061904&group_id=5470 From noreply at sourceforge.net Sun Nov 7 14:44:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 14:44:46 2004 Subject: [Patches] [ python-Patches-1025636 ] Check for NULL returns in compile.c:com_import_stmt Message-ID: Patches item #1025636, was opened at 2004-09-10 07:38 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025636&group_id=5470 Category: Parser/Compiler Group: None >Status: Pending Resolution: None Priority: 6 Submitted By: Dima Dorfman (ddorfman) Assigned to: Jeremy Hylton (jhylton) Summary: Check for NULL returns in compile.c:com_import_stmt Initial Comment: com_import_stmt doesn't check for tuple construction being successful. This hasn't been noticed before because it would only happen if we're out of memory, and compiling usually isn't done in the middle of a memory-intensive operation. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2004-11-07 13:44 Message: Logged In: YES user_id=31392 I agree. It's unlikely to happen, but it ought to be checked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025636&group_id=5470 From noreply at sourceforge.net Sun Nov 7 15:05:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 15:05:08 2004 Subject: [Patches] [ python-Patches-1025636 ] Check for NULL returns in compile.c:com_import_stmt Message-ID: Patches item #1025636, was opened at 2004-09-10 07:38 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025636&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Dima Dorfman (ddorfman) Assigned to: Jeremy Hylton (jhylton) Summary: Check for NULL returns in compile.c:com_import_stmt Initial Comment: com_import_stmt doesn't check for tuple construction being successful. This hasn't been noticed before because it would only happen if we're out of memory, and compiling usually isn't done in the middle of a memory-intensive operation. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2004-11-07 14:05 Message: Logged In: YES user_id=31392 Fixed in rev 2.337 of compile.c. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-11-07 13:44 Message: Logged In: YES user_id=31392 I agree. It's unlikely to happen, but it ought to be checked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025636&group_id=5470 From noreply at sourceforge.net Sun Nov 7 15:15:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 15:15:17 2004 Subject: [Patches] [ python-Patches-1061882 ] [ 1061857 ] Error and omission in logging docs Message-ID: Patches item #1061882, was opened at 2004-11-07 13:46 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061882&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeroen Vloothuis (slmm) Assigned to: Nobody/Anonymous (nobody) Summary: [ 1061857 ] Error and omission in logging docs Initial Comment: The patch attached below adds the section for the TimedRotatingLogging class. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 15:15 Message: Logged In: YES user_id=469548 Applied as rev 1.31 of liblogging.tex. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061882&group_id=5470 From noreply at sourceforge.net Sun Nov 7 15:29:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 15:29:17 2004 Subject: [Patches] [ python-Patches-876193 ] reorganize, extend function call optimizations Message-ID: Patches item #876193, was opened at 2004-01-13 16:35 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876193&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: reorganize, extend function call optimizations Initial Comment: This patch rejigs the optimizations for certain kinds of function call -- easy Python functions, METH_O functions and so on. It also extends the "easy Python function" optimization to handle default arguments. It adds a tp_pythoncall field to type objects, with the signature of the ceval.c local static function do_call (which is now exported and called PyEval_DoCall). This field is filled out in the function and method constructors appropriately. What do you think? Makes little performance difference (0.5% improvement in pystone on one machine), but I think I prefer this arrangement. It generalizes better, for one thing. The patch is a little untidy at present -- some code duplication and it utterly mangles the function call statistics code -- but these should be shallow. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2004-11-07 14:29 Message: Logged In: YES user_id=31392 Is this patch still relevant? Should it wait until 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876193&group_id=5470 From noreply at sourceforge.net Sun Nov 7 15:37:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 15:37:10 2004 Subject: [Patches] [ python-Patches-1061924 ] Relative to bug #1061857 -- logging docs Message-ID: Patches item #1061924, was opened at 2004-11-07 14: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=1061924&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rodrigo Dias Arruda Senra (rodsenra) Assigned to: Nobody/Anonymous (nobody) Summary: Relative to bug #1061857 -- logging docs Initial Comment: This patch fixes the issue #1061857 -- Error and omission in logging docs. It incorporates patch 1061882 (by slmm - Jeroen Vloothuis), that adds a section about the TimedRotatingFileHandler. Moreover, this patch includes references to BaseRotatingHandler and corrects wrong references from 'setRollover' to 'doRollover'. All issues referenced by bug report #1061857 are comtemplated by this patch. Python version: CVS 2.4b2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061924&group_id=5470 From noreply at sourceforge.net Sun Nov 7 16:03:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 16:03:23 2004 Subject: [Patches] [ python-Patches-1061931 ] [ 971872 ] An apparent bug in help Message-ID: Patches item #1061931, was opened at 2004-11-07 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=1061931&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeroen Vloothuis (slmm) Assigned to: Nobody/Anonymous (nobody) Summary: [ 971872 ] An apparent bug in help Initial Comment: Help on property now prints its __doc__ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061931&group_id=5470 From noreply at sourceforge.net Sun Nov 7 16:27:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 16:27:43 2004 Subject: [Patches] [ python-Patches-1061941 ] fix for 988120 httplib.py not updating length correctly Message-ID: Patches item #1061941, was opened at 2004-11-07 16: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=1061941&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 988120 httplib.py not updating length correctly Initial Comment: Based upon the patch #988642, this patch is slightly improved, I've taken jjlee's comment into account. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061941&group_id=5470 From noreply at sourceforge.net Sun Nov 7 16:28:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 16:29:01 2004 Subject: [Patches] [ python-Patches-988642 ] Update HTTPRespnse.length Message-ID: Patches item #988642, was opened at 2004-07-10 23:16 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988642&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Jeremy Hylton (jhylton) Summary: Update HTTPRespnse.length Initial Comment: Update length attribute correctly when read() returns less than the expected number of bytes. Addresses bug # 988120 ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 16:28 Message: Logged In: YES user_id=129426 slightly improved patch is at 1061941 ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-09-02 15:15 Message: Logged In: YES user_id=31392 I will take a look. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 22:59 Message: Logged In: YES user_id=11375 Jeremy, you know about HTTP stuff, right? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-07-11 00:36 Message: Logged In: YES user_id=261020 Patch basically looks good, but I'm worrying about the bit of code in the current httplib.py, in the block commented with '# unbounded read'. Why the switch on .will_close? Shouldn't the switch be on (self.length is None), instead? I could well be missing something, but this looks like another bug of the same kind as in the original report. Also, how about the various .readline() calls? Might they also return less than a full line? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988642&group_id=5470 From noreply at sourceforge.net Sun Nov 7 16:32:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 16:32:49 2004 Subject: [Patches] [ python-Patches-1061941 ] fix for 988120 httplib.py not updating length correctly Message-ID: Patches item #1061941, was opened at 2004-11-07 15:27 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061941&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) >Assigned to: Jeremy Hylton (jhylton) Summary: fix for 988120 httplib.py not updating length correctly Initial Comment: Based upon the patch #988642, this patch is slightly improved, I've taken jjlee's comment into account. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061941&group_id=5470 From noreply at sourceforge.net Sun Nov 7 16:51:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 16:51:41 2004 Subject: [Patches] [ python-Patches-1061904 ] fix for bug 878275 class MyTest(unittest.TestSuite) Message-ID: Patches item #1061904, was opened at 2004-11-07 14:30 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061904&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 878275 class MyTest(unittest.TestSuite) Initial Comment: The docs on unittest, and the code comments, all seem to indicate that testcases must be derived from unittest.TestCase. So to avoid strange errors, the TestLoader now checks this. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 16:51 Message: Logged In: YES user_id=469548 Applied a different patch that only checks for unittest.TestSuite as rev 1.36 of unittest.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061904&group_id=5470 From noreply at sourceforge.net Sun Nov 7 17:14:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 17:14:34 2004 Subject: [Patches] [ python-Patches-1061924 ] Relative to bug #1061857 -- logging docs Message-ID: Patches item #1061924, was opened at 2004-11-07 15:37 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061924&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Rodrigo Dias Arruda Senra (rodsenra) Assigned to: Nobody/Anonymous (nobody) Summary: Relative to bug #1061857 -- logging docs Initial Comment: This patch fixes the issue #1061857 -- Error and omission in logging docs. It incorporates patch 1061882 (by slmm - Jeroen Vloothuis), that adds a section about the TimedRotatingFileHandler. Moreover, this patch includes references to BaseRotatingHandler and corrects wrong references from 'setRollover' to 'doRollover'. All issues referenced by bug report #1061857 are comtemplated by this patch. Python version: CVS 2.4b2 ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 17:14 Message: Logged In: YES user_id=469548 Applied as rev 1.32 of liblogging.tex. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061924&group_id=5470 From noreply at sourceforge.net Sun Nov 7 17:14:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 17:14:54 2004 Subject: [Patches] [ python-Patches-1061941 ] fix for 988120 httplib.py not updating length correctly Message-ID: Patches item #1061941, was opened at 2004-11-07 15:27 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061941&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Jeremy Hylton (jhylton) Summary: fix for 988120 httplib.py not updating length correctly Initial Comment: Based upon the patch #988642, this patch is slightly improved, I've taken jjlee's comment into account. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2004-11-07 16:14 Message: Logged In: YES user_id=31392 Fixed in httplib.py 1.94 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061941&group_id=5470 From noreply at sourceforge.net Sun Nov 7 17:15:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 17:15:58 2004 Subject: [Patches] [ python-Patches-988642 ] Update HTTPRespnse.length Message-ID: Patches item #988642, was opened at 2004-07-10 21:16 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988642&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Jeremy Hylton (jhylton) Summary: Update HTTPRespnse.length Initial Comment: Update length attribute correctly when read() returns less than the expected number of bytes. Addresses bug # 988120 ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2004-11-07 16:15 Message: Logged In: YES user_id=31392 Applied patch 1061941; fixed in httplib.py 1.94 ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 15:28 Message: Logged In: YES user_id=129426 slightly improved patch is at 1061941 ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-09-02 13:15 Message: Logged In: YES user_id=31392 I will take a look. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 20:59 Message: Logged In: YES user_id=11375 Jeremy, you know about HTTP stuff, right? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-07-10 22:36 Message: Logged In: YES user_id=261020 Patch basically looks good, but I'm worrying about the bit of code in the current httplib.py, in the block commented with '# unbounded read'. Why the switch on .will_close? Shouldn't the switch be on (self.length is None), instead? I could well be missing something, but this looks like another bug of the same kind as in the original report. Also, how about the various .readline() calls? Might they also return less than a full line? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988642&group_id=5470 From noreply at sourceforge.net Sun Nov 7 19:18:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 19:18:15 2004 Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket special linux socket names Message-ID: Patches item #1062014, was opened at 2004-11-07 19:18 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=1062014&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 764437 AF_UNIX socket special linux socket names Initial Comment: The patch addresses two things: 1. the socket name (obtained using getsockname() or getpeername() ) will now be correct in case of the special linux socket names (starting with 0 byte) 2. the socket module now has a new constant: UNIX_PATH_MAX , that can be used to build correctly-sized path names. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470 From noreply at sourceforge.net Sun Nov 7 19:29:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 19:29:55 2004 Subject: [Patches] [ python-Patches-1062018 ] Fix for bug issue #1038693 -- bad link in Tkinter docs Message-ID: Patches item #1062018, was opened at 2004-11-07 18: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=1062018&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rodrigo Dias Arruda Senra (rodsenra) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug issue #1038693 -- bad link in Tkinter docs Initial Comment: In the file tkinter.tex there was a broken reference to \citetitle[classes/ClassPacker.html] The whole sentence was commented out, like several other occurences in the same document. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062018&group_id=5470 From noreply at sourceforge.net Sun Nov 7 20:17:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 20:17:53 2004 Subject: [Patches] [ python-Patches-1061931 ] [ 971872 ] An apparent bug in help Message-ID: Patches item #1061931, was opened at 2004-11-07 16:03 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061931&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeroen Vloothuis (slmm) Assigned to: Nobody/Anonymous (nobody) Summary: [ 971872 ] An apparent bug in help Initial Comment: Help on property now prints its __doc__ ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 20:17 Message: Logged In: YES user_id=469548 Applied patch with some refactoring as rev 1.99 of pydoc.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061931&group_id=5470 From noreply at sourceforge.net Sun Nov 7 20:20:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 20:20:21 2004 Subject: [Patches] [ python-Patches-1062033 ] Half-fix for 1027771 - DOM insertBefore Message-ID: Patches item #1062033, was opened at 2004-11-07 19:20 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=1062033&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rodrigo Dias Arruda Senra (rodsenra) Assigned to: Nobody/Anonymous (nobody) Summary: Half-fix for 1027771 - DOM insertBefore Initial Comment: This patch adds """ If refChild is None, it inserts newChild at the end of the list of children. """ to the xmldom.tex. I left the last paragraph reported in 1027771 out of the patch, because I'm not certain it is clear enough or adequate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062033&group_id=5470 From noreply at sourceforge.net Sun Nov 7 20:37:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 20:37:37 2004 Subject: [Patches] [ python-Patches-1062018 ] Fix for bug issue #1038693 -- bad link in Tkinter docs Message-ID: Patches item #1062018, was opened at 2004-11-07 19:29 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062018&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Rodrigo Dias Arruda Senra (rodsenra) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug issue #1038693 -- bad link in Tkinter docs Initial Comment: In the file tkinter.tex there was a broken reference to \citetitle[classes/ClassPacker.html] The whole sentence was commented out, like several other occurences in the same document. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 20:37 Message: Logged In: YES user_id=469548 Applied as rev 1.27 of libtkinter.tex. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062018&group_id=5470 From noreply at sourceforge.net Sun Nov 7 20:55:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 20:55:51 2004 Subject: [Patches] [ python-Patches-1062033 ] Half-fix for 1027771 - DOM insertBefore Message-ID: Patches item #1062033, was opened at 2004-11-07 20:20 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062033&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Rodrigo Dias Arruda Senra (rodsenra) Assigned to: Nobody/Anonymous (nobody) Summary: Half-fix for 1027771 - DOM insertBefore Initial Comment: This patch adds """ If refChild is None, it inserts newChild at the end of the list of children. """ to the xmldom.tex. I left the last paragraph reported in 1027771 out of the patch, because I'm not certain it is clear enough or adequate. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 20:55 Message: Logged In: YES user_id=469548 Applied as rev 1.25 of xmldom.tex. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062033&group_id=5470 From noreply at sourceforge.net Sun Nov 7 21:11:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 21:11:59 2004 Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket special linux socket names Message-ID: Patches item #1062014, was opened at 2004-11-07 19:18 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 764437 AF_UNIX socket special linux socket names Initial Comment: The patch addresses two things: 1. the socket name (obtained using getsockname() or getpeername() ) will now be correct in case of the special linux socket names (starting with 0 byte) 2. the socket module now has a new constant: UNIX_PATH_MAX , that can be used to build correctly-sized path names. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 21:11 Message: Logged In: YES user_id=469548 As you noted on IRC: this needs a new regression test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470 From noreply at sourceforge.net Sun Nov 7 21:15:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 21:15:35 2004 Subject: [Patches] [ python-Patches-1062060 ] fix for 1016880 urllib.urlretrieve silently truncates dwnld Message-ID: Patches item #1062060, was opened at 2004-11-07 21: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=1062060&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 1016880 urllib.urlretrieve silently truncates dwnld Initial Comment: The patch makes urllib.urlretrieve raise an IOError if the actual download size is different from the expected size (taken from the content-length header). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470 From noreply at sourceforge.net Sun Nov 7 21:54:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 21:54:13 2004 Subject: [Patches] [ python-Patches-1062060 ] fix for 1016880 urllib.urlretrieve silently truncates dwnld Message-ID: Patches item #1062060, was opened at 2004-11-07 21:15 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 1016880 urllib.urlretrieve silently truncates dwnld Initial Comment: The patch makes urllib.urlretrieve raise an IOError if the actual download size is different from the expected size (taken from the content-length header). ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2004-11-07 21:54 Message: Logged In: YES user_id=129426 NOTE: urllib.patch2 may be a bit better. It fixes a misspelling, and also is more relaxed about a 'wrong' download size. To be more precise: it treats content-length as a lower bound (just like wget and firefox appear to do). So if there's more data to read, it reads more data, but if less data is available, it gives an IOError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470 From noreply at sourceforge.net Sun Nov 7 23:11:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 23:11:12 2004 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 10:55 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 14:11 Message: Logged In: YES user_id=341410 Re: features Aside from NOOP (which is easily added), the provided BaseSMTPServer seems to offer the same amount of functionality as smtpd (ignoring DebuggingServer, PureProxy and MailmanProxy, which are trivially borrowed from smtpd). Re: What's the benefit... Someone who wanted to use a synchronous SMTP server would have one available. I think that we should probably wait until the original author answers how this relates to smtpd.py, and perhaps decide then. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-06 23:11 Message: Logged In: YES user_id=994239 Yes, I am aware of smtpd.py. My understanding is (although please correct me if I'm wrong) that the asyncore/asynchat framework will not be able to service network clients if the found_terminator() method performs an operation that blocks. The BaseSMTPServer class doesn't suffer from that problem, because it's threaded. If you're interested in integrating this module, I'd be happy to clean it up to conform with the Python style guidelines, add documentation, and implement the allow_host() method. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 01:43 Message: Logged In: YES user_id=92689 I just wanted to check whether the author _knows_ smtpd.py, since he doesn't mention it. Maybe I should put it more bluntly: What's the benefit of having an incompatible, less featureful, threaded version of smtpd.py in the library? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 01:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-05 23:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Sun Nov 7 23:20:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 7 23:20:48 2004 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 10:55 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 14:20 Message: Logged In: YES user_id=341410 Hrm, nevemind, I just noticed mdr0's post. I'll leave the rest up to someone who has the authority to make decisions. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 14:11 Message: Logged In: YES user_id=341410 Re: features Aside from NOOP (which is easily added), the provided BaseSMTPServer seems to offer the same amount of functionality as smtpd (ignoring DebuggingServer, PureProxy and MailmanProxy, which are trivially borrowed from smtpd). Re: What's the benefit... Someone who wanted to use a synchronous SMTP server would have one available. I think that we should probably wait until the original author answers how this relates to smtpd.py, and perhaps decide then. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-06 23:11 Message: Logged In: YES user_id=994239 Yes, I am aware of smtpd.py. My understanding is (although please correct me if I'm wrong) that the asyncore/asynchat framework will not be able to service network clients if the found_terminator() method performs an operation that blocks. The BaseSMTPServer class doesn't suffer from that problem, because it's threaded. If you're interested in integrating this module, I'd be happy to clean it up to conform with the Python style guidelines, add documentation, and implement the allow_host() method. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 01:43 Message: Logged In: YES user_id=92689 I just wanted to check whether the author _knows_ smtpd.py, since he doesn't mention it. Maybe I should put it more bluntly: What's the benefit of having an incompatible, less featureful, threaded version of smtpd.py in the library? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 01:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-05 23:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Mon Nov 8 04:15:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 8 04:15:47 2004 Subject: [Patches] [ python-Patches-1038854 ] Fix struct.pack on 64-bit archs (broken on 2.*) Message-ID: Patches item #1038854, was opened at 2004-10-02 01:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Grundmann (sgatwasetde) Assigned to: Nobody/Anonymous (nobody) Summary: Fix struct.pack on 64-bit archs (broken on 2.*) Initial Comment: Description: The code in the struct module assumes that sizeof(long) == sizeof(int) which is wrong on (most) 64-bit architectures (linux on amd64 with a 32-bit userland is an exception). How To Repeat: on a 32-bit platform struct.pack behaves as expected: $ uname -m -r -s FreeBSD 4.10-STABLE i386 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert on a 64-bit platform it treats integers as longs (it does not check for over/underflows and returns the lower 4 byte): $ uname -m -r -s FreeBSD 5.2-CURRENT sparc64 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" '\x00\x00\x00\x00' Fix: in python/python/dist/src/Modules/structmodule.c: np_uint() and np_int() have to check for over/underflows using MAX_UINT, MAX_INT, MIN_INT as np_ushort() and np_short() already do for MAX_USHORT, ... the attached patch does this (diff was generated using diff -rNu and Revision 2.62 of python/python/dist/src/Modules/structmodule.c) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-11-07 22:15 Message: Logged In: YES user_id=33168 This patch breaks 3 tests: test_binhex test_gzip test_tarfile. tarfile breaks because of gzip. Run on opterons. Can you update the patch so these tests pass? ---------------------------------------------------------------------- Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-10-08 02:07 Message: Logged In: YES user_id=1131807 The attached patch will fix the range-checking-code of the integer pack functions for 64 and 32 bit architectures (tested on i386 and Sparc64, 64-bit little-endian was not tested 'cause of lack of hardware). All test cases worked as expected, there is no more need for BUGGY_RANGE_CHECK. I'm a bit unsure about the used method to get an unsigned long from a Python_Long object with overflow checking... PyLong_AsUnsignedLong(PyLong_FromLong(PyInt_AS_LONG(v))) looks a rather excessive. ---------------------------------------------------------------------- Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-10-06 02:31 Message: Logged In: YES user_id=1131807 I removed the attached patch since it only handles overflows for np_int/np_uint. bp_int/bp_uint and lp_int/lp_unit have different issues (no overflow checking at all, unneccessary loops - that will not be optimized by the compiler). I'm working on a new patch that fixes these problems (and the rest of BUGGY_RANGE_CHECK ;) ). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 09:31 Message: Logged In: YES user_id=4771 At a first glance, it appears that there is the same problem in bp_int/bp_uint and lp_int/lp_unit. Can you check that pack('I',...) fail to detect the overflow in the same way? If so, can you also provide the patch for these 4 other routines? Finally, it would be nice to add a test case in Lib/test/test_struct.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 From noreply at sourceforge.net Mon Nov 8 09:06:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 8 09:06:57 2004 Subject: [Patches] [ python-Patches-1062277 ] Pickle breakage with reduction of recursive structures Message-ID: Patches item #1062277, was opened at 2004-11-08 08:06 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=1062277&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Pickle breakage with reduction of recursive structures Initial Comment: Fix problems related to reduce cycles during pickling. A "reduce cycle" is what happens when a __reduce__ implementation returns an args that cycles back through the object it tried to reduce. This can't work because the unpickler has to call the constructor with those args, but it doesn't yet have that object to be able to place inside the args. There are two problems related to this: 1. The standard reduce implementation for proto < 2 in copy_reg (_reduce_ex) doesn't correctly deal with recursive structures. reduce_2 in typeobject.c does the right thing by using listitems and dictitems. Fix _reduce_ex by making it do the same thing. This is okay for proto < 2 because those arguments are a pickler- side feature. Tested in test_stdreducecycle. 2. Our pickle implementations don't check for reduce cycles. This is somewhat cosmetic except that stack overflow protection is imperfect (for cPickle), causing crashes, and some kinds of cycles trigger asserts (in pickle). Fixed in pickle and cPickle by introducing a reducing_now set; on entering save_reduce, the object id being saved must not be in that set or we've been called recursively while saving the callable or arguments. Tested in test_reduce_cycle. This shouldn't change any semantics. That reduce shouldn't introduce cycles through args isn't documented, but it can't work any other way. Possible improvement: If we want to support reducing of real immutable containers we might have to relax the reduction cycle test to give the cycle a chance of resolving itself normally (by constructing a partial object to pass to the constructor and filling it in later). I'm not sure if this trouble is worth it just to avoid writing a frozenset.__setstate__. See also: http://mail.python. org/pipermail/python-dev/2004-October/049714.html It would be very good if someone familiar with pickle reviewed this; I am still not very confident that I completely understand all the issues. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062277&group_id=5470 From noreply at sourceforge.net Mon Nov 8 09:10:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 8 09:10:55 2004 Subject: [Patches] [ python-Patches-1062279 ] deque pickling problems Message-ID: Patches item #1062279, was opened at 2004-11-08 08: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=1062279&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: deque pickling problems Initial Comment: Two problems with deque.__reduce__: 1. If one of the elements is self, it ends up in args, which makes it impossible for the unpickler to correctly supply it. Fixed by using the listitems argument (PEP 307 says that non-lists may use this if they support append and extend, which deque does) (test_pickle_recursive). This is related to SF #1062277 but does not depend on it. 2. Since we wrote our reduce, the standard ones don't have a chance to save the instance dictionary, so we have to do it ourselves (TestSubclass.test_pickle). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062279&group_id=5470 From noreply at sourceforge.net Mon Nov 8 09:44:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 8 09:44:50 2004 Subject: [Patches] [ python-Patches-1062279 ] deque pickling problems Message-ID: Patches item #1062279, was opened at 2004-11-08 03:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062279&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: deque pickling problems Initial Comment: Two problems with deque.__reduce__: 1. If one of the elements is self, it ends up in args, which makes it impossible for the unpickler to correctly supply it. Fixed by using the listitems argument (PEP 307 says that non-lists may use this if they support append and extend, which deque does) (test_pickle_recursive). This is related to SF #1062277 but does not depend on it. 2. Since we wrote our reduce, the standard ones don't have a chance to save the instance dictionary, so we have to do it ourselves (TestSubclass.test_pickle). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-08 03:44 Message: Logged In: YES user_id=80475 I'll look at this tomorrow. In the meantime, please check to see if you have the same problems with set/frozenset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062279&group_id=5470 From noreply at sourceforge.net Mon Nov 8 09:51:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 8 09:51:38 2004 Subject: [Patches] [ python-Patches-1062279 ] deque pickling problems Message-ID: Patches item #1062279, was opened at 2004-11-08 08:10 Message generated for change (Comment added) made by ddorfman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062279&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: deque pickling problems Initial Comment: Two problems with deque.__reduce__: 1. If one of the elements is self, it ends up in args, which makes it impossible for the unpickler to correctly supply it. Fixed by using the listitems argument (PEP 307 says that non-lists may use this if they support append and extend, which deque does) (test_pickle_recursive). This is related to SF #1062277 but does not depend on it. 2. Since we wrote our reduce, the standard ones don't have a chance to save the instance dictionary, so we have to do it ourselves (TestSubclass.test_pickle). ---------------------------------------------------------------------- >Comment By: Dima Dorfman (ddorfman) Date: 2004-11-08 08:51 Message: Logged In: YES user_id=908995 I'm working on set. It definitely has this problem, but an analogous fix requires introducing frozenset.__setstate__ which would make it possible to mutate a frozenset. A more correct solution might depend on whether someone finds a better alternative to my patch in #1062277. I think I'll post a patch that implements frozenset.__setstate__ tonight, but it's less obviously desirable than this one. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-08 08:44 Message: Logged In: YES user_id=80475 I'll look at this tomorrow. In the meantime, please check to see if you have the same problems with set/frozenset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062279&group_id=5470 From noreply at sourceforge.net Mon Nov 8 12:05:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 8 12:05:05 2004 Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket special linux socket names Message-ID: Patches item #1062014, was opened at 2004-11-07 19:18 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 764437 AF_UNIX socket special linux socket names Initial Comment: The patch addresses two things: 1. the socket name (obtained using getsockname() or getpeername() ) will now be correct in case of the special linux socket names (starting with 0 byte) 2. the socket module now has a new constant: UNIX_PATH_MAX , that can be used to build correctly-sized path names. ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2004-11-08 12:05 Message: Logged In: YES user_id=129426 Not only does it need a new regression test, but if it is accepted as-is, the socket module docs need to be updated too (mention the new constant for use with the special naming case) ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 21:11 Message: Logged In: YES user_id=469548 As you noted on IRC: this needs a new regression test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470 From noreply at sourceforge.net Mon Nov 8 12:07:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 8 12:07:52 2004 Subject: [Patches] [ python-Patches-1062353 ] set pickling problems Message-ID: Patches item #1062353, was opened at 2004-11-08 11:07 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=1062353&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: set pickling problems Initial Comment: As with deque (SF #1062279), two problems with set.__reduce__: 1. Recursive sets (which can be constructed with the aid of a hashable mutable object) aren't pickled correctly because __reduce__ wants a reference to itself in the call to its constructor. Fix by moving the keys to the state argument and resurrecting them in __setstate__ (test_pickling_recursive). 2. Without the standard reduce, we have to take care of the instance dictionary ourselves. The test for this is in a new TestSubclassOps class that is mixed in to TestSetSubclass and TestFrozenSetSubclass. I'm not sure if such a mixin is the best way to distribute that test. The biggest drawback to this patch is that __setstate__ makes it possible to mutate a frozenset. This implementation clears the cached hash after such a mutation, but even then it can be used to cause havoc in dicts. Such havoc isn't fatal (this doesn't do anything that a regular class can't do), but it can be confusing. Not being able to do this was a desirable property of frozenset, but it's unlikely to happen on accident, and sets.ImmutableSet has surived without it. Unless one of the pickle gurus provides a better alternative to SF #1062277, this might be the best option. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062353&group_id=5470 From noreply at sourceforge.net Mon Nov 8 12:08:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 8 12:08:27 2004 Subject: [Patches] [ python-Patches-1062279 ] deque pickling problems Message-ID: Patches item #1062279, was opened at 2004-11-08 08:10 Message generated for change (Comment added) made by ddorfman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062279&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: deque pickling problems Initial Comment: Two problems with deque.__reduce__: 1. If one of the elements is self, it ends up in args, which makes it impossible for the unpickler to correctly supply it. Fixed by using the listitems argument (PEP 307 says that non-lists may use this if they support append and extend, which deque does) (test_pickle_recursive). This is related to SF #1062277 but does not depend on it. 2. Since we wrote our reduce, the standard ones don't have a chance to save the instance dictionary, so we have to do it ourselves (TestSubclass.test_pickle). ---------------------------------------------------------------------- >Comment By: Dima Dorfman (ddorfman) Date: 2004-11-08 11:08 Message: Logged In: YES user_id=908995 set patch filed as SF #1062353 I just realized that neither of these patches do anything to handle __slots__, but I'm not even sure if it's necessary. At least _reduce_ex tells such classes to write their own getstate, and such subclasses of set or deque can always write their own reduce, so lack of such support doesn't make anything impossible--it just might require a little more work on the user's part. ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-11-08 08:51 Message: Logged In: YES user_id=908995 I'm working on set. It definitely has this problem, but an analogous fix requires introducing frozenset.__setstate__ which would make it possible to mutate a frozenset. A more correct solution might depend on whether someone finds a better alternative to my patch in #1062277. I think I'll post a patch that implements frozenset.__setstate__ tonight, but it's less obviously desirable than this one. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-08 08:44 Message: Logged In: YES user_id=80475 I'll look at this tomorrow. In the meantime, please check to see if you have the same problems with set/frozenset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062279&group_id=5470 From noreply at sourceforge.net Mon Nov 8 13:19:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 8 13:20:03 2004 Subject: [Patches] [ python-Patches-876193 ] reorganize, extend function call optimizations Message-ID: Patches item #876193, was opened at 2004-01-13 16:35 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876193&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: reorganize, extend function call optimizations Initial Comment: This patch rejigs the optimizations for certain kinds of function call -- easy Python functions, METH_O functions and so on. It also extends the "easy Python function" optimization to handle default arguments. It adds a tp_pythoncall field to type objects, with the signature of the ceval.c local static function do_call (which is now exported and called PyEval_DoCall). This field is filled out in the function and method constructors appropriately. What do you think? Makes little performance difference (0.5% improvement in pystone on one machine), but I think I prefer this arrangement. It generalizes better, for one thing. The patch is a little untidy at present -- some code duplication and it utterly mangles the function call statistics code -- but these should be shallow. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-11-08 12:19 Message: Logged In: YES user_id=6656 Well, nothing has invalidated it. I think I still would like to see it go in, but don't have strong opinions either way. What do you think of it? :-) It should certainly wait for 2.5. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-11-07 14:29 Message: Logged In: YES user_id=31392 Is this patch still relevant? Should it wait until 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876193&group_id=5470 From noreply at sourceforge.net Mon Nov 8 22:38:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 8 22:39:06 2004 Subject: [Patches] [ python-Patches-1054967 ] bdist_deb - Debian packager Message-ID: Patches item #1054967, was opened at 2004-10-26 17:48 Message generated for change (Comment added) made by dairiki You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 Category: Distutils and setup.py Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Sean Reifschneider (jafo) Summary: bdist_deb - Debian packager Initial Comment: Here's a first crack at a bdist_deb. This patch implements two new distutils commands: bdist_deb: Build Debian packages debianize: Create and populate a top-level debian subdirectory. (Essentially dh_make for distutils packages.) There is a slightly detailed README.bdist_deb included in the patches. I'm open to suggestions for improvements and bug-fixes. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-08 13:38 Message: Logged In: YES user_id=45814 Another updated patch set: As suggested by Bastian Kleineidam, when the source distribution includes it's own debian subdirectory, bdist_deb (rather than just crapping out) will now skip the dh_make stage, and just run debuild. As always, patches on the current CVS version of distutils are attached below. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-02 14:20 Message: Logged In: YES user_id=45814 Here's try number three! Changes are mostly fixes for woody. The README.bdist_deb (included in the patch set) enumerates the changes in more detail. (I've bitten the bullet and installed woody on one of my machines, so I'm fairly confident it should work now.) The patches, on todays CVS are, as always, attached below. ==== Note to Davide, Thank you, again, very much for all the testing. A couple of the lintian warnings ('prerm-does-not-remove-usr-doc-link' and 'postinst-does-not-set-usr-doc-link') that are listed in your test suite output are due, I think, to your mixed system. Specifically, I suspect you've got the woody version of lintian (which wants to see symlinks from /usr/doc/ to /usr/share/doc/), but a later version of debhelper. (Woody's dh_installdocs (in the debhelper package) automatically generates those links, later versions don't; /usr/doc has been phased out.) Anyhow, I'm not going to fix those warnings (unless it turns out that you're seeing them on your pure woody system.) On package with python scripts (in /usr/bin) Woody's lintian generates an 'unusual-interpreter' warning which I think is spurious (i.e. it is not a valid warning.) (Lintian 1.20.17 doesn't recognize things like /usr/bin/python2.1 as a valid interpreter --- it seems valid enough to me.) Best Regards, Jeff ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-30 01:57 Message: Logged In: YES user_id=170840 I've tried the 29/10 patch with my home system (dpkg-dev 1.10, debhelper 4.1.90 and dh-make 0.30) and another "pure woody" system (dpkg-dev 1.9.21, debhelper 4.0.2 and dh-make 0.30). I've used your test suite and some of my personal projects (using both bdist_deb and dh_make); as far as I can tell, it works very well. :-) bdist_deb always worked as expected, producing good debian packages. I've used dh_make and then I've run "dpkg-buildpackage -rfakeroot" and I got some errors (but I'm not sure they depends on your code). Also your test suite produced some failures. Here you can find the output of "dpkg-buildpackage -rfakeroot" and of your tests suite (both were running on my home system): http://erlug.linux.it/~da/tmp/dpkg-buildpackage http://erlug.linux.it/~da/tmp/testsuite Thank you for your great effort! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-10-29 12:38 Message: Logged In: YES user_id=45814 Thanks for the comments. Here's a second attempt. Changes include: It might work with woody. (I'd appreciate it if you could try again, Davide) 'debianize' command renamed to 'dh_make'. Use debchange to create debian/changelog. This eliminates the need to duplicate debchange's logic to deduce the packagers name and e-mail. A more complete test script. Patches are on today's CVS. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-27 07:47 Message: Logged In: YES user_id=170840 I've a woody with some packages backported from sarge (debhelper 4.1.90 and dpkg-dev 1.10). Running python2.3 ./setup.py bdist_deb with some of my projects, I got the error: dpkg-buildpackage: unknown option or argument --check-dirname-level=1 Debian dpkg-buildpackage . Commenting out the "check-dirname-level" and "check-dirname-regex" options in the bdist_deb.py file the script can go on, but it exits with the error: debian/rules:11: *** first argument to `word' function must be greater than 0. Stop. Hope this helps. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-10-26 20:44 Message: Logged In: YES user_id=81797 I'm just doing a review of this code. A couple of things: There's been some concern expressed about get_default_maintainer. Namely, that if debchange changes it's algorithm, it won't be reflected in this code. It seems like one possible way around that would be to build a directory with a "debian" directory under it, a fake "changelog", and then call debchange to write the data out, and parse it. Too bad there's not a direct hook into debchange to get that information. Can _formatdate, if email doesn't exist, use rfc822.formatdate()? Ditto for _parseaddr? It looks pretty good. However, when trying to build a .deb of my jotweb2 package, it's failing with: [...] dh_testdir dh_testroot dh_installchangelogs- dh_installdocs cp: cannot stat `doc': No such file or directory dh_installdocs: command returned error code 256 [...] I'm not sure exactly why. I do have a "doc" directory in my main package directory, but I don't reference to it in my setup.py or MANIFEST. Adding it to the MANIFEST doesn't seem to help this. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 From noreply at sourceforge.net Tue Nov 9 08:25:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 9 08:26:02 2004 Subject: [Patches] [ python-Patches-1062353 ] set pickling problems Message-ID: Patches item #1062353, was opened at 2004-11-08 06:07 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062353&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: set pickling problems Initial Comment: As with deque (SF #1062279), two problems with set.__reduce__: 1. Recursive sets (which can be constructed with the aid of a hashable mutable object) aren't pickled correctly because __reduce__ wants a reference to itself in the call to its constructor. Fix by moving the keys to the state argument and resurrecting them in __setstate__ (test_pickling_recursive). 2. Without the standard reduce, we have to take care of the instance dictionary ourselves. The test for this is in a new TestSubclassOps class that is mixed in to TestSetSubclass and TestFrozenSetSubclass. I'm not sure if such a mixin is the best way to distribute that test. The biggest drawback to this patch is that __setstate__ makes it possible to mutate a frozenset. This implementation clears the cached hash after such a mutation, but even then it can be used to cause havoc in dicts. Such havoc isn't fatal (this doesn't do anything that a regular class can't do), but it can be confusing. Not being able to do this was a desirable property of frozenset, but it's unlikely to happen on accident, and sets.ImmutableSet has surived without it. Unless one of the pickle gurus provides a better alternative to SF #1062277, this might be the best option. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-09 02:25 Message: Logged In: YES user_id=80475 Am adding the dict argument so that subclass dictionaries are handled without extra coding. See Objects/setobject.c 1.31 Sets were designed to be non-recursive. While you can create shennanigans to introduce hashable mutable objects to be stored recursively, I have no interest in building support for them. Certainly, it is not worth introducing other anomalies or worth compilcating the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062353&group_id=5470 From noreply at sourceforge.net Tue Nov 9 08:28:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 9 08:28:37 2004 Subject: [Patches] [ python-Patches-1062279 ] deque pickling problems Message-ID: Patches item #1062279, was opened at 2004-11-08 03:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062279&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: deque pickling problems Initial Comment: Two problems with deque.__reduce__: 1. If one of the elements is self, it ends up in args, which makes it impossible for the unpickler to correctly supply it. Fixed by using the listitems argument (PEP 307 says that non-lists may use this if they support append and extend, which deque does) (test_pickle_recursive). This is related to SF #1062277 but does not depend on it. 2. Since we wrote our reduce, the standard ones don't have a chance to save the instance dictionary, so we have to do it ourselves (TestSubclass.test_pickle). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-09 02:28 Message: Logged In: YES user_id=80475 Accepted and applied with minor modifications. See Modules/collectionsmodule.c 1.36 ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-11-08 06:08 Message: Logged In: YES user_id=908995 set patch filed as SF #1062353 I just realized that neither of these patches do anything to handle __slots__, but I'm not even sure if it's necessary. At least _reduce_ex tells such classes to write their own getstate, and such subclasses of set or deque can always write their own reduce, so lack of such support doesn't make anything impossible--it just might require a little more work on the user's part. ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-11-08 03:51 Message: Logged In: YES user_id=908995 I'm working on set. It definitely has this problem, but an analogous fix requires introducing frozenset.__setstate__ which would make it possible to mutate a frozenset. A more correct solution might depend on whether someone finds a better alternative to my patch in #1062277. I think I'll post a patch that implements frozenset.__setstate__ tonight, but it's less obviously desirable than this one. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-08 03:44 Message: Logged In: YES user_id=80475 I'll look at this tomorrow. In the meantime, please check to see if you have the same problems with set/frozenset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062279&group_id=5470 From noreply at sourceforge.net Tue Nov 9 08:31:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 9 08:31:15 2004 Subject: [Patches] [ python-Patches-1062277 ] Pickle breakage with reduction of recursive structures Message-ID: Patches item #1062277, was opened at 2004-11-08 03:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062277&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Pickle breakage with reduction of recursive structures Initial Comment: Fix problems related to reduce cycles during pickling. A "reduce cycle" is what happens when a __reduce__ implementation returns an args that cycles back through the object it tried to reduce. This can't work because the unpickler has to call the constructor with those args, but it doesn't yet have that object to be able to place inside the args. There are two problems related to this: 1. The standard reduce implementation for proto < 2 in copy_reg (_reduce_ex) doesn't correctly deal with recursive structures. reduce_2 in typeobject.c does the right thing by using listitems and dictitems. Fix _reduce_ex by making it do the same thing. This is okay for proto < 2 because those arguments are a pickler- side feature. Tested in test_stdreducecycle. 2. Our pickle implementations don't check for reduce cycles. This is somewhat cosmetic except that stack overflow protection is imperfect (for cPickle), causing crashes, and some kinds of cycles trigger asserts (in pickle). Fixed in pickle and cPickle by introducing a reducing_now set; on entering save_reduce, the object id being saved must not be in that set or we've been called recursively while saving the callable or arguments. Tested in test_reduce_cycle. This shouldn't change any semantics. That reduce shouldn't introduce cycles through args isn't documented, but it can't work any other way. Possible improvement: If we want to support reducing of real immutable containers we might have to relax the reduction cycle test to give the cycle a chance of resolving itself normally (by constructing a partial object to pass to the constructor and filling it in later). I'm not sure if this trouble is worth it just to avoid writing a frozenset.__setstate__. See also: http://mail.python. org/pipermail/python-dev/2004-October/049714.html It would be very good if someone familiar with pickle reviewed this; I am still not very confident that I completely understand all the issues. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-09 02:31 Message: Logged In: YES user_id=80475 IMO, this is more of a feature request than a bug. Also, it needs to be fully thought-out and discussed. Putting this sort of thing in just before the Py2.4 release candidate is probably not wise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062277&group_id=5470 From noreply at sourceforge.net Tue Nov 9 10:03:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 9 10:03:15 2004 Subject: [Patches] [ python-Patches-1062353 ] set pickling problems Message-ID: Patches item #1062353, was opened at 2004-11-08 11:07 Message generated for change (Comment added) made by ddorfman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062353&group_id=5470 Category: Modules Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: set pickling problems Initial Comment: As with deque (SF #1062279), two problems with set.__reduce__: 1. Recursive sets (which can be constructed with the aid of a hashable mutable object) aren't pickled correctly because __reduce__ wants a reference to itself in the call to its constructor. Fix by moving the keys to the state argument and resurrecting them in __setstate__ (test_pickling_recursive). 2. Without the standard reduce, we have to take care of the instance dictionary ourselves. The test for this is in a new TestSubclassOps class that is mixed in to TestSetSubclass and TestFrozenSetSubclass. I'm not sure if such a mixin is the best way to distribute that test. The biggest drawback to this patch is that __setstate__ makes it possible to mutate a frozenset. This implementation clears the cached hash after such a mutation, but even then it can be used to cause havoc in dicts. Such havoc isn't fatal (this doesn't do anything that a regular class can't do), but it can be confusing. Not being able to do this was a desirable property of frozenset, but it's unlikely to happen on accident, and sets.ImmutableSet has surived without it. Unless one of the pickle gurus provides a better alternative to SF #1062277, this might be the best option. ---------------------------------------------------------------------- >Comment By: Dima Dorfman (ddorfman) Date: 2004-11-09 09:03 Message: Logged In: YES user_id=908995 Fair enough. If sets weren't meant to be recursive then 1. 31 is sufficient. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-09 07:25 Message: Logged In: YES user_id=80475 Am adding the dict argument so that subclass dictionaries are handled without extra coding. See Objects/setobject.c 1.31 Sets were designed to be non-recursive. While you can create shennanigans to introduce hashable mutable objects to be stored recursively, I have no interest in building support for them. Certainly, it is not worth introducing other anomalies or worth compilcating the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062353&group_id=5470 From noreply at sourceforge.net Tue Nov 9 10:06:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 9 10:06:12 2004 Subject: [Patches] [ python-Patches-1062277 ] Pickle breakage with reduction of recursive structures Message-ID: Patches item #1062277, was opened at 2004-11-08 08:06 Message generated for change (Comment added) made by ddorfman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062277&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Pickle breakage with reduction of recursive structures Initial Comment: Fix problems related to reduce cycles during pickling. A "reduce cycle" is what happens when a __reduce__ implementation returns an args that cycles back through the object it tried to reduce. This can't work because the unpickler has to call the constructor with those args, but it doesn't yet have that object to be able to place inside the args. There are two problems related to this: 1. The standard reduce implementation for proto < 2 in copy_reg (_reduce_ex) doesn't correctly deal with recursive structures. reduce_2 in typeobject.c does the right thing by using listitems and dictitems. Fix _reduce_ex by making it do the same thing. This is okay for proto < 2 because those arguments are a pickler- side feature. Tested in test_stdreducecycle. 2. Our pickle implementations don't check for reduce cycles. This is somewhat cosmetic except that stack overflow protection is imperfect (for cPickle), causing crashes, and some kinds of cycles trigger asserts (in pickle). Fixed in pickle and cPickle by introducing a reducing_now set; on entering save_reduce, the object id being saved must not be in that set or we've been called recursively while saving the callable or arguments. Tested in test_reduce_cycle. This shouldn't change any semantics. That reduce shouldn't introduce cycles through args isn't documented, but it can't work any other way. Possible improvement: If we want to support reducing of real immutable containers we might have to relax the reduction cycle test to give the cycle a chance of resolving itself normally (by constructing a partial object to pass to the constructor and filling it in later). I'm not sure if this trouble is worth it just to avoid writing a frozenset.__setstate__. See also: http://mail.python. org/pipermail/python-dev/2004-October/049714.html It would be very good if someone familiar with pickle reviewed this; I am still not very confident that I completely understand all the issues. ---------------------------------------------------------------------- >Comment By: Dima Dorfman (ddorfman) Date: 2004-11-09 09:06 Message: Logged In: YES user_id=908995 Triggering assertions (pickle) and producing incorrect output (cPickle) are certainly bugs, and being able to pickle a recursive structure is not a feature request. The copy_reg part of the patch is the real fix, and as it's almost a translation of what reduce_2 already does, it should be safe for 2.4. I agree that the rest of the patch--to check for cycles during pickling--should wait until 2.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-09 07:31 Message: Logged In: YES user_id=80475 IMO, this is more of a feature request than a bug. Also, it needs to be fully thought-out and discussed. Putting this sort of thing in just before the Py2.4 release candidate is probably not wise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062277&group_id=5470 From noreply at sourceforge.net Tue Nov 9 13:40:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 9 13:41:01 2004 Subject: [Patches] [ python-Patches-1063059 ] distutils and python 1.5.2 Message-ID: Patches item #1063059, was opened at 2004-11-09 13: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=1063059&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Davide Alberani (alberanid) Assigned to: Nobody/Anonymous (nobody) Summary: distutils and python 1.5.2 Initial Comment: distutils is supposed to be compatible with Python 1.5.2. In the attachment there's a small patch, against the current CVS, that fixes some incompatibilities. Changes: * install_lib.py: reference to os.extsep * build_py.py: unrolled three list comprehensions to loops * build_py.py: modified a funct(*seq) to apply(funct, seq) * bdist_rpm.py: string.replace() instead of strObject.replace() I've tried the patch with some _simple_ packages, and it seems to work correctly, but I've not a great knowledge of the distutils internals, so _double check everything_, especially the loops I've written in the place of list comprehensions. Known issues: * command/register.py could not be ported to 1.5.2 because it uses modules like "urllib2"; for this reason running python1.5 ./setup.py --help-commands fails. I'm not sure what should be done (remove the "register" command if python version < 2.0?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063059&group_id=5470 From noreply at sourceforge.net Tue Nov 9 16:39:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 9 16:39:31 2004 Subject: [Patches] [ python-Patches-1054967 ] bdist_deb - Debian packager Message-ID: Patches item #1054967, was opened at 2004-10-27 02:48 Message generated for change (Comment added) made by alberanid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 Category: Distutils and setup.py Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Sean Reifschneider (jafo) Summary: bdist_deb - Debian packager Initial Comment: Here's a first crack at a bdist_deb. This patch implements two new distutils commands: bdist_deb: Build Debian packages debianize: Create and populate a top-level debian subdirectory. (Essentially dh_make for distutils packages.) There is a slightly detailed README.bdist_deb included in the patches. I'm open to suggestions for improvements and bug-fixes. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 16:39 Message: Logged In: YES user_id=170840 I've created a patch to make your bdist_deb/dh_make commands compatible with Python 1.5.2; it can be found here: http://erlug.linux.it/~da/tmp/distutils-cvs_debpy152-20041109.patch Beware that I've tested it for a very short time, so double check everything (especially the permissions on file/umasks). Moreover, the patch changes also some other files like build_py.py, install_lib.py, bdist_rpm.py, that were not 1.5.2 compatible - these changes are part of another patch I've posted today. HTH. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-08 22:38 Message: Logged In: YES user_id=45814 Another updated patch set: As suggested by Bastian Kleineidam, when the source distribution includes it's own debian subdirectory, bdist_deb (rather than just crapping out) will now skip the dh_make stage, and just run debuild. As always, patches on the current CVS version of distutils are attached below. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-02 23:20 Message: Logged In: YES user_id=45814 Here's try number three! Changes are mostly fixes for woody. The README.bdist_deb (included in the patch set) enumerates the changes in more detail. (I've bitten the bullet and installed woody on one of my machines, so I'm fairly confident it should work now.) The patches, on todays CVS are, as always, attached below. ==== Note to Davide, Thank you, again, very much for all the testing. A couple of the lintian warnings ('prerm-does-not-remove-usr-doc-link' and 'postinst-does-not-set-usr-doc-link') that are listed in your test suite output are due, I think, to your mixed system. Specifically, I suspect you've got the woody version of lintian (which wants to see symlinks from /usr/doc/ to /usr/share/doc/), but a later version of debhelper. (Woody's dh_installdocs (in the debhelper package) automatically generates those links, later versions don't; /usr/doc has been phased out.) Anyhow, I'm not going to fix those warnings (unless it turns out that you're seeing them on your pure woody system.) On package with python scripts (in /usr/bin) Woody's lintian generates an 'unusual-interpreter' warning which I think is spurious (i.e. it is not a valid warning.) (Lintian 1.20.17 doesn't recognize things like /usr/bin/python2.1 as a valid interpreter --- it seems valid enough to me.) Best Regards, Jeff ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-30 10:57 Message: Logged In: YES user_id=170840 I've tried the 29/10 patch with my home system (dpkg-dev 1.10, debhelper 4.1.90 and dh-make 0.30) and another "pure woody" system (dpkg-dev 1.9.21, debhelper 4.0.2 and dh-make 0.30). I've used your test suite and some of my personal projects (using both bdist_deb and dh_make); as far as I can tell, it works very well. :-) bdist_deb always worked as expected, producing good debian packages. I've used dh_make and then I've run "dpkg-buildpackage -rfakeroot" and I got some errors (but I'm not sure they depends on your code). Also your test suite produced some failures. Here you can find the output of "dpkg-buildpackage -rfakeroot" and of your tests suite (both were running on my home system): http://erlug.linux.it/~da/tmp/dpkg-buildpackage http://erlug.linux.it/~da/tmp/testsuite Thank you for your great effort! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-10-29 21:38 Message: Logged In: YES user_id=45814 Thanks for the comments. Here's a second attempt. Changes include: It might work with woody. (I'd appreciate it if you could try again, Davide) 'debianize' command renamed to 'dh_make'. Use debchange to create debian/changelog. This eliminates the need to duplicate debchange's logic to deduce the packagers name and e-mail. A more complete test script. Patches are on today's CVS. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-27 16:47 Message: Logged In: YES user_id=170840 I've a woody with some packages backported from sarge (debhelper 4.1.90 and dpkg-dev 1.10). Running python2.3 ./setup.py bdist_deb with some of my projects, I got the error: dpkg-buildpackage: unknown option or argument --check-dirname-level=1 Debian dpkg-buildpackage . Commenting out the "check-dirname-level" and "check-dirname-regex" options in the bdist_deb.py file the script can go on, but it exits with the error: debian/rules:11: *** first argument to `word' function must be greater than 0. Stop. Hope this helps. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-10-27 05:44 Message: Logged In: YES user_id=81797 I'm just doing a review of this code. A couple of things: There's been some concern expressed about get_default_maintainer. Namely, that if debchange changes it's algorithm, it won't be reflected in this code. It seems like one possible way around that would be to build a directory with a "debian" directory under it, a fake "changelog", and then call debchange to write the data out, and parse it. Too bad there's not a direct hook into debchange to get that information. Can _formatdate, if email doesn't exist, use rfc822.formatdate()? Ditto for _parseaddr? It looks pretty good. However, when trying to build a .deb of my jotweb2 package, it's failing with: [...] dh_testdir dh_testroot dh_installchangelogs- dh_installdocs cp: cannot stat `doc': No such file or directory dh_installdocs: command returned error code 256 [...] I'm not sure exactly why. I do have a "doc" directory in my main package directory, but I don't reference to it in my setup.py or MANIFEST. Adding it to the MANIFEST doesn't seem to help this. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 From noreply at sourceforge.net Tue Nov 9 16:50:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 9 16:50:49 2004 Subject: [Patches] [ python-Patches-1063059 ] distutils and python 1.5.2 Message-ID: Patches item #1063059, was opened at 2004-11-09 04:40 Message generated for change (Comment added) made by dairiki You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063059&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Davide Alberani (alberanid) Assigned to: Nobody/Anonymous (nobody) Summary: distutils and python 1.5.2 Initial Comment: distutils is supposed to be compatible with Python 1.5.2. In the attachment there's a small patch, against the current CVS, that fixes some incompatibilities. Changes: * install_lib.py: reference to os.extsep * build_py.py: unrolled three list comprehensions to loops * build_py.py: modified a funct(*seq) to apply(funct, seq) * bdist_rpm.py: string.replace() instead of strObject.replace() I've tried the patch with some _simple_ packages, and it seems to work correctly, but I've not a great knowledge of the distutils internals, so _double check everything_, especially the loops I've written in the place of list comprehensions. Known issues: * command/register.py could not be ported to 1.5.2 because it uses modules like "urllib2"; for this reason running python1.5 ./setup.py --help-commands fails. I'm not sure what should be done (remove the "register" command if python version < 2.0?) ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-09 07:50 Message: Logged In: YES user_id=45814 I don't know how correct it is, but according to the following post, http://mail.python.org/pipermail/distutils-sig/2004-September/004168.html the compatibility target for the current distutils is Python 2.1, not Python 1.5. (The install_lib.py reference to os.extsep needs to be fixing in any case, since os.extsep only exists in Pythons >= 2.3.) Other References: http://sourceforge.net/tracker/index.php?func=detail&aid=1058960&group_id=5470&atid=105470 http://sourceforge.net/tracker/index.php?func=detail&aid=1058937&group_id=5470&atid=105470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063059&group_id=5470 From noreply at sourceforge.net Tue Nov 9 19:04:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 9 19:04:58 2004 Subject: [Patches] [ python-Patches-1063059 ] distutils and python 1.5.2 Message-ID: Patches item #1063059, was opened at 2004-11-09 13:40 Message generated for change (Comment added) made by alberanid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063059&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Davide Alberani (alberanid) Assigned to: Nobody/Anonymous (nobody) Summary: distutils and python 1.5.2 Initial Comment: distutils is supposed to be compatible with Python 1.5.2. In the attachment there's a small patch, against the current CVS, that fixes some incompatibilities. Changes: * install_lib.py: reference to os.extsep * build_py.py: unrolled three list comprehensions to loops * build_py.py: modified a funct(*seq) to apply(funct, seq) * bdist_rpm.py: string.replace() instead of strObject.replace() I've tried the patch with some _simple_ packages, and it seems to work correctly, but I've not a great knowledge of the distutils internals, so _double check everything_, especially the loops I've written in the place of list comprehensions. Known issues: * command/register.py could not be ported to 1.5.2 because it uses modules like "urllib2"; for this reason running python1.5 ./setup.py --help-commands fails. I'm not sure what should be done (remove the "register" command if python version < 2.0?) ---------------------------------------------------------------------- >Comment By: Davide Alberani (alberanid) Date: 2004-11-09 19:04 Message: Logged In: YES user_id=170840 Wooops, someone should remove all these "this file should be compatible with 1.5.2" notes. :-) Anyway (even if I'm glad that 1.5 is gone ;-) I'll make my patches available though my home page. Thank you for your note! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-09 16:50 Message: Logged In: YES user_id=45814 I don't know how correct it is, but according to the following post, http://mail.python.org/pipermail/distutils-sig/2004-September/004168.html the compatibility target for the current distutils is Python 2.1, not Python 1.5. (The install_lib.py reference to os.extsep needs to be fixing in any case, since os.extsep only exists in Pythons >= 2.3.) Other References: http://sourceforge.net/tracker/index.php?func=detail&aid=1058960&group_id=5470&atid=105470 http://sourceforge.net/tracker/index.php?func=detail&aid=1058937&group_id=5470&atid=105470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063059&group_id=5470 From noreply at sourceforge.net Wed Nov 10 06:28:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 10 06:28:21 2004 Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket special linux socket names Message-ID: Patches item #1062014, was opened at 2004-11-07 13:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) >Assigned to: Jeremy Hylton (jhylton) Summary: fix for 764437 AF_UNIX socket special linux socket names Initial Comment: The patch addresses two things: 1. the socket name (obtained using getsockname() or getpeername() ) will now be correct in case of the special linux socket names (starting with 0 byte) 2. the socket module now has a new constant: UNIX_PATH_MAX , that can be used to build correctly-sized path names. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-08 06:05 Message: Logged In: YES user_id=129426 Not only does it need a new regression test, but if it is accepted as-is, the socket module docs need to be updated too (mention the new constant for use with the special naming case) ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 15:11 Message: Logged In: YES user_id=469548 As you noted on IRC: this needs a new regression test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470 From noreply at sourceforge.net Wed Nov 10 07:40:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 10 07:40:30 2004 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 12:55 Message generated for change (Comment added) made by mdr0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- >Comment By: Mark D. Roth (mdr0) Date: 2004-11-10 00:40 Message: Logged In: YES user_id=994239 Here's a new version of BaseSMTPServer with the following changes: * Added lots of documentation. * Changed code style to conform with PEP 8. * Added allow_host() method. * Added smtp_NOOP() method. * Improved interface to process_message() and access-control methods. Please let me know what you think. Thanks! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 16:20 Message: Logged In: YES user_id=341410 Hrm, nevemind, I just noticed mdr0's post. I'll leave the rest up to someone who has the authority to make decisions. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 16:11 Message: Logged In: YES user_id=341410 Re: features Aside from NOOP (which is easily added), the provided BaseSMTPServer seems to offer the same amount of functionality as smtpd (ignoring DebuggingServer, PureProxy and MailmanProxy, which are trivially borrowed from smtpd). Re: What's the benefit... Someone who wanted to use a synchronous SMTP server would have one available. I think that we should probably wait until the original author answers how this relates to smtpd.py, and perhaps decide then. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-07 01:11 Message: Logged In: YES user_id=994239 Yes, I am aware of smtpd.py. My understanding is (although please correct me if I'm wrong) that the asyncore/asynchat framework will not be able to service network clients if the found_terminator() method performs an operation that blocks. The BaseSMTPServer class doesn't suffer from that problem, because it's threaded. If you're interested in integrating this module, I'd be happy to clean it up to conform with the Python style guidelines, add documentation, and implement the allow_host() method. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 03:43 Message: Logged In: YES user_id=92689 I just wanted to check whether the author _knows_ smtpd.py, since he doesn't mention it. Maybe I should put it more bluntly: What's the benefit of having an incompatible, less featureful, threaded version of smtpd.py in the library? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 03:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 01:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Wed Nov 10 08:36:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 10 08:36:32 2004 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 10:55 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-09 23:36 Message: Logged In: YES user_id=341410 It still has a couple tabs, but I don't believe that is a big deal. I think it fits in with the standard SocketServer framework, and that it would make sense to add it, but I don't have any authority to make decisions. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-09 22:40 Message: Logged In: YES user_id=994239 Here's a new version of BaseSMTPServer with the following changes: * Added lots of documentation. * Changed code style to conform with PEP 8. * Added allow_host() method. * Added smtp_NOOP() method. * Improved interface to process_message() and access-control methods. Please let me know what you think. Thanks! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 14:20 Message: Logged In: YES user_id=341410 Hrm, nevemind, I just noticed mdr0's post. I'll leave the rest up to someone who has the authority to make decisions. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 14:11 Message: Logged In: YES user_id=341410 Re: features Aside from NOOP (which is easily added), the provided BaseSMTPServer seems to offer the same amount of functionality as smtpd (ignoring DebuggingServer, PureProxy and MailmanProxy, which are trivially borrowed from smtpd). Re: What's the benefit... Someone who wanted to use a synchronous SMTP server would have one available. I think that we should probably wait until the original author answers how this relates to smtpd.py, and perhaps decide then. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-06 23:11 Message: Logged In: YES user_id=994239 Yes, I am aware of smtpd.py. My understanding is (although please correct me if I'm wrong) that the asyncore/asynchat framework will not be able to service network clients if the found_terminator() method performs an operation that blocks. The BaseSMTPServer class doesn't suffer from that problem, because it's threaded. If you're interested in integrating this module, I'd be happy to clean it up to conform with the Python style guidelines, add documentation, and implement the allow_host() method. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 01:43 Message: Logged In: YES user_id=92689 I just wanted to check whether the author _knows_ smtpd.py, since he doesn't mention it. Maybe I should put it more bluntly: What's the benefit of having an incompatible, less featureful, threaded version of smtpd.py in the library? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 01:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-05 23:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Wed Nov 10 09:36:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 10 09:37:05 2004 Subject: [Patches] [ python-Patches-1038854 ] Fix struct.pack on 64-bit archs (broken on 2.*) Message-ID: Patches item #1038854, was opened at 2004-10-02 07:07 Message generated for change (Comment added) made by sgatwasetde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Grundmann (sgatwasetde) Assigned to: Nobody/Anonymous (nobody) Summary: Fix struct.pack on 64-bit archs (broken on 2.*) Initial Comment: Description: The code in the struct module assumes that sizeof(long) == sizeof(int) which is wrong on (most) 64-bit architectures (linux on amd64 with a 32-bit userland is an exception). How To Repeat: on a 32-bit platform struct.pack behaves as expected: $ uname -m -r -s FreeBSD 4.10-STABLE i386 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert on a 64-bit platform it treats integers as longs (it does not check for over/underflows and returns the lower 4 byte): $ uname -m -r -s FreeBSD 5.2-CURRENT sparc64 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" '\x00\x00\x00\x00' Fix: in python/python/dist/src/Modules/structmodule.c: np_uint() and np_int() have to check for over/underflows using MAX_UINT, MAX_INT, MIN_INT as np_ushort() and np_short() already do for MAX_USHORT, ... the attached patch does this (diff was generated using diff -rNu and Revision 2.62 of python/python/dist/src/Modules/structmodule.c) ---------------------------------------------------------------------- >Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-11-10 09:36 Message: Logged In: YES user_id=1131807 The patch breaks test_binhex on 32 and 64 bit architectures because Lib/binhex.py is using struct.pack('>h' ...) to pack an unsigned short (which is wrong but does work with the current version of Modules/structmodule.c because of the lack of range checking). The patch breaks test_gzip (and test_tarfile) on 64 bit architectures because Lib/gzip.py is using write32 (which uses to pack('I',...) fail to detect the overflow in the same way? If so, can you also provide the patch for these 4 other routines? Finally, it would be nice to add a test case in Lib/test/test_struct.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 From noreply at sourceforge.net Wed Nov 10 17:07:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 10 17:07:31 2004 Subject: [Patches] [ python-Patches-1063914 ] Tkinter clipboard_get method (new in Tk 8.4) Message-ID: Patches item #1063914, was opened at 2004-11-10 16:07 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=1063914&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Martin v. L?wis (loewis) Summary: Tkinter clipboard_get method (new in Tk 8.4) Initial Comment: When Tkinter was patched to include the new Tk 8.4 stuff the clipboard_get method was left out. The attached diff -c file should fix this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063914&group_id=5470 From noreply at sourceforge.net Wed Nov 10 22:31:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 10 22:31:25 2004 Subject: [Patches] [ python-Patches-1038854 ] Fix struct.pack on 64-bit archs (broken on 2.*) Message-ID: Patches item #1038854, was opened at 2004-10-02 05:07 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Grundmann (sgatwasetde) Assigned to: Nobody/Anonymous (nobody) Summary: Fix struct.pack on 64-bit archs (broken on 2.*) Initial Comment: Description: The code in the struct module assumes that sizeof(long) == sizeof(int) which is wrong on (most) 64-bit architectures (linux on amd64 with a 32-bit userland is an exception). How To Repeat: on a 32-bit platform struct.pack behaves as expected: $ uname -m -r -s FreeBSD 4.10-STABLE i386 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert on a 64-bit platform it treats integers as longs (it does not check for over/underflows and returns the lower 4 byte): $ uname -m -r -s FreeBSD 5.2-CURRENT sparc64 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" '\x00\x00\x00\x00' Fix: in python/python/dist/src/Modules/structmodule.c: np_uint() and np_int() have to check for over/underflows using MAX_UINT, MAX_INT, MIN_INT as np_ushort() and np_short() already do for MAX_USHORT, ... the attached patch does this (diff was generated using diff -rNu and Revision 2.62 of python/python/dist/src/Modules/structmodule.c) ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-11-10 21:31 Message: Logged In: YES user_id=4771 This indicate that similar breakage will probably occur in user code if we add range checking. Do we want to take the risk? It looks overkill, but what about issuing a warning and turning it into an error in the next version? ---------------------------------------------------------------------- Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-11-10 08:36 Message: Logged In: YES user_id=1131807 The patch breaks test_binhex on 32 and 64 bit architectures because Lib/binhex.py is using struct.pack('>h' ...) to pack an unsigned short (which is wrong but does work with the current version of Modules/structmodule.c because of the lack of range checking). The patch breaks test_gzip (and test_tarfile) on 64 bit architectures because Lib/gzip.py is using write32 (which uses to pack('I',...) fail to detect the overflow in the same way? If so, can you also provide the patch for these 4 other routines? Finally, it would be nice to add a test case in Lib/test/test_struct.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 From noreply at sourceforge.net Wed Nov 10 23:21:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 10 23:24:27 2004 Subject: [Patches] [ python-Patches-1063914 ] Tkinter clipboard_get method (new in Tk 8.4) Message-ID: Patches item #1063914, was opened at 2004-11-10 17:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063914&group_id=5470 Category: Tkinter >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Martin v. L?wis (loewis) Summary: Tkinter clipboard_get method (new in Tk 8.4) Initial Comment: When Tkinter was patched to include the new Tk 8.4 stuff the clipboard_get method was left out. The attached diff -c file should fix this... ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-11-10 23:21 Message: Logged In: YES user_id=21627 It's too late for 2.4; retargetting for 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063914&group_id=5470 From noreply at sourceforge.net Wed Nov 10 23:24:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 10 23:24:44 2004 Subject: [Patches] [ python-Patches-1063059 ] distutils and python 1.5.2 Message-ID: Patches item #1063059, was opened at 2004-11-09 13:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063059&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Davide Alberani (alberanid) Assigned to: Nobody/Anonymous (nobody) Summary: distutils and python 1.5.2 Initial Comment: distutils is supposed to be compatible with Python 1.5.2. In the attachment there's a small patch, against the current CVS, that fixes some incompatibilities. Changes: * install_lib.py: reference to os.extsep * build_py.py: unrolled three list comprehensions to loops * build_py.py: modified a funct(*seq) to apply(funct, seq) * bdist_rpm.py: string.replace() instead of strObject.replace() I've tried the patch with some _simple_ packages, and it seems to work correctly, but I've not a great knowledge of the distutils internals, so _double check everything_, especially the loops I've written in the place of list comprehensions. Known issues: * command/register.py could not be ported to 1.5.2 because it uses modules like "urllib2"; for this reason running python1.5 ./setup.py --help-commands fails. I'm not sure what should be done (remove the "register" command if python version < 2.0?) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-11-10 23:24 Message: Logged In: YES user_id=21627 This is now fixed in PEP 291 1.13, which lists 2.1 as the backwards compatibility target; the HEAD CVS has been updated accordingly. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 19:04 Message: Logged In: YES user_id=170840 Wooops, someone should remove all these "this file should be compatible with 1.5.2" notes. :-) Anyway (even if I'm glad that 1.5 is gone ;-) I'll make my patches available though my home page. Thank you for your note! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-09 16:50 Message: Logged In: YES user_id=45814 I don't know how correct it is, but according to the following post, http://mail.python.org/pipermail/distutils-sig/2004-September/004168.html the compatibility target for the current distutils is Python 2.1, not Python 1.5. (The install_lib.py reference to os.extsep needs to be fixing in any case, since os.extsep only exists in Pythons >= 2.3.) Other References: http://sourceforge.net/tracker/index.php?func=detail&aid=1058960&group_id=5470&atid=105470 http://sourceforge.net/tracker/index.php?func=detail&aid=1058937&group_id=5470&atid=105470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063059&group_id=5470 From noreply at sourceforge.net Thu Nov 11 11:05:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 11 11:05:20 2004 Subject: [Patches] [ python-Patches-954628 ] Replacement for webbrowser.py which has problems. Message-ID: Patches item #954628, was opened at 2004-05-15 22:02 Message generated for change (Comment added) made by mfranklin1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954628&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michel Van den Bergh (vdbergh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Replacement for webbrowser.py which has problems. Initial Comment: I have been checking out webbrowser.py. Unfortunately this module has some obvious problems (tested on CVS version under Linux with mozilla) (*) If you open an url (with the option "new window") and the browser is not already running then it opens *two* windows: the home page and your url. This is different for example from the default behaviour on Windows and also quite ugly. (**) There is another related problem: if you open a url and the browser is not already running then the code starts a new browser, sleeps 4 seconds and then issues a "-remote" command. Using a timed sleep is very bad programming and *extremely fragile*. Indeed I had failures because the delay (PROCESS_CREATION_DELAY) was not long enough. At the very least the -remote command should be tried a couple of times. BUT: there is no reason *at all* to issue a -remote command in this case. All browsers I know accept a url as argument. So one can just start a new browser with the url as argument. There are two pending patches for webbrowser.py but they don't address the above problems. Therefore I made a new version of webbrowser.py (from the latest CVS) that addresses them. Along the way I made a few other non-intrusive changes. They are listed below. Added PYTHONBROWSER environment variable since Mandrake 10.0 already sets BROWSER. Added opera, epiphany,firefox,firebird. Firebird and firefox and the rewritten code for Galeon are not tested Changed default on windows to be "startfile" (instead of Netscape). Changed _tryorder on X into something more reasonable for these days. ---------------------------------------------------------------------- Comment By: Martin Franklin (mfranklin1) Date: 2004-11-11 10:05 Message: Logged In: YES user_id=482545 Great work... couple of points I just tested on my fedora c2 box (with firefox & opera installed...) The try order did not include firefox. Also I believe (at least on my system) opera can be treated just like the netscape browsers, it supports the same command line flags. As to the tryorder *I* would personally have firefox up front because if you have it installed the chances are you want to use it instead of mozzilla (same goes for opera) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954628&group_id=5470 From noreply at sourceforge.net Thu Nov 11 14:55:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 11 14:55:23 2004 Subject: [Patches] [ python-Patches-1063914 ] Tkinter clipboard_get method (new in Tk 8.4) Message-ID: Patches item #1063914, was opened at 2004-11-10 16:07 Message generated for change (Comment added) made by mfranklin1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063914&group_id=5470 Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Martin v. L?wis (loewis) Summary: Tkinter clipboard_get method (new in Tk 8.4) Initial Comment: When Tkinter was patched to include the new Tk 8.4 stuff the clipboard_get method was left out. The attached diff -c file should fix this... ---------------------------------------------------------------------- >Comment By: Martin Franklin (mfranklin1) Date: 2004-11-11 13:55 Message: Logged In: YES user_id=482545 Thanks Martin I wasn't sure... I wanted to point out that this method raises a TclError if it is called when the clipboard is empty... not sure if that is pythonic or not... perhaps I could catch it and return an empty string? Perhaps I should bring this up on the Tkinter mail list... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-10 22:21 Message: Logged In: YES user_id=21627 It's too late for 2.4; retargetting for 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063914&group_id=5470 From noreply at sourceforge.net Thu Nov 11 17:18:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 11 17:18:48 2004 Subject: [Patches] [ python-Patches-1054967 ] bdist_deb - Debian packager Message-ID: Patches item #1054967, was opened at 2004-10-26 17:48 Message generated for change (Comment added) made by dairiki You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 Category: Distutils and setup.py Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Sean Reifschneider (jafo) Summary: bdist_deb - Debian packager Initial Comment: Here's a first crack at a bdist_deb. This patch implements two new distutils commands: bdist_deb: Build Debian packages debianize: Create and populate a top-level debian subdirectory. (Essentially dh_make for distutils packages.) There is a slightly detailed README.bdist_deb included in the patches. I'm open to suggestions for improvements and bug-fixes. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-11 08:18 Message: Logged In: YES user_id=45814 Another updated patch set. The only change is a bug fix: when using a hand-build set of debian/* files, dh_make will now deduce the correct Debian revision and build architecture. (Bug reported by Bastian Kleineidam.) Patches, as always are on today's CVS version of distutils. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 07:39 Message: Logged In: YES user_id=170840 I've created a patch to make your bdist_deb/dh_make commands compatible with Python 1.5.2; it can be found here: http://erlug.linux.it/~da/tmp/distutils-cvs_debpy152-20041109.patch Beware that I've tested it for a very short time, so double check everything (especially the permissions on file/umasks). Moreover, the patch changes also some other files like build_py.py, install_lib.py, bdist_rpm.py, that were not 1.5.2 compatible - these changes are part of another patch I've posted today. HTH. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-08 13:38 Message: Logged In: YES user_id=45814 Another updated patch set: As suggested by Bastian Kleineidam, when the source distribution includes it's own debian subdirectory, bdist_deb (rather than just crapping out) will now skip the dh_make stage, and just run debuild. As always, patches on the current CVS version of distutils are attached below. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-02 14:20 Message: Logged In: YES user_id=45814 Here's try number three! Changes are mostly fixes for woody. The README.bdist_deb (included in the patch set) enumerates the changes in more detail. (I've bitten the bullet and installed woody on one of my machines, so I'm fairly confident it should work now.) The patches, on todays CVS are, as always, attached below. ==== Note to Davide, Thank you, again, very much for all the testing. A couple of the lintian warnings ('prerm-does-not-remove-usr-doc-link' and 'postinst-does-not-set-usr-doc-link') that are listed in your test suite output are due, I think, to your mixed system. Specifically, I suspect you've got the woody version of lintian (which wants to see symlinks from /usr/doc/ to /usr/share/doc/), but a later version of debhelper. (Woody's dh_installdocs (in the debhelper package) automatically generates those links, later versions don't; /usr/doc has been phased out.) Anyhow, I'm not going to fix those warnings (unless it turns out that you're seeing them on your pure woody system.) On package with python scripts (in /usr/bin) Woody's lintian generates an 'unusual-interpreter' warning which I think is spurious (i.e. it is not a valid warning.) (Lintian 1.20.17 doesn't recognize things like /usr/bin/python2.1 as a valid interpreter --- it seems valid enough to me.) Best Regards, Jeff ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-30 01:57 Message: Logged In: YES user_id=170840 I've tried the 29/10 patch with my home system (dpkg-dev 1.10, debhelper 4.1.90 and dh-make 0.30) and another "pure woody" system (dpkg-dev 1.9.21, debhelper 4.0.2 and dh-make 0.30). I've used your test suite and some of my personal projects (using both bdist_deb and dh_make); as far as I can tell, it works very well. :-) bdist_deb always worked as expected, producing good debian packages. I've used dh_make and then I've run "dpkg-buildpackage -rfakeroot" and I got some errors (but I'm not sure they depends on your code). Also your test suite produced some failures. Here you can find the output of "dpkg-buildpackage -rfakeroot" and of your tests suite (both were running on my home system): http://erlug.linux.it/~da/tmp/dpkg-buildpackage http://erlug.linux.it/~da/tmp/testsuite Thank you for your great effort! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-10-29 12:38 Message: Logged In: YES user_id=45814 Thanks for the comments. Here's a second attempt. Changes include: It might work with woody. (I'd appreciate it if you could try again, Davide) 'debianize' command renamed to 'dh_make'. Use debchange to create debian/changelog. This eliminates the need to duplicate debchange's logic to deduce the packagers name and e-mail. A more complete test script. Patches are on today's CVS. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-27 07:47 Message: Logged In: YES user_id=170840 I've a woody with some packages backported from sarge (debhelper 4.1.90 and dpkg-dev 1.10). Running python2.3 ./setup.py bdist_deb with some of my projects, I got the error: dpkg-buildpackage: unknown option or argument --check-dirname-level=1 Debian dpkg-buildpackage . Commenting out the "check-dirname-level" and "check-dirname-regex" options in the bdist_deb.py file the script can go on, but it exits with the error: debian/rules:11: *** first argument to `word' function must be greater than 0. Stop. Hope this helps. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-10-26 20:44 Message: Logged In: YES user_id=81797 I'm just doing a review of this code. A couple of things: There's been some concern expressed about get_default_maintainer. Namely, that if debchange changes it's algorithm, it won't be reflected in this code. It seems like one possible way around that would be to build a directory with a "debian" directory under it, a fake "changelog", and then call debchange to write the data out, and parse it. Too bad there's not a direct hook into debchange to get that information. Can _formatdate, if email doesn't exist, use rfc822.formatdate()? Ditto for _parseaddr? It looks pretty good. However, when trying to build a .deb of my jotweb2 package, it's failing with: [...] dh_testdir dh_testroot dh_installchangelogs- dh_installdocs cp: cannot stat `doc': No such file or directory dh_installdocs: command returned error code 256 [...] I'm not sure exactly why. I do have a "doc" directory in my main package directory, but I don't reference to it in my setup.py or MANIFEST. Adding it to the MANIFEST doesn't seem to help this. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 From noreply at sourceforge.net Thu Nov 11 21:24:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 11 21:24:59 2004 Subject: [Patches] [ python-Patches-643943 ] Fix for os.path.expanduser for Win2000 Message-ID: Patches item #643943, was opened at 2002-11-26 05:25 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=643943&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Ralph Nichols (ralphn) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for os.path.expanduser for Win2000 Initial Comment: On windows 2000, environment varables are recursively expanded, so the comand os.path.expanduser('~\test') will typically yeld "%USERPROFILE%\test". This patch to ntpath.py will recursively expand the '%' quoted varables until either of the following happen: a) It hits an environment varable it has already seen b) The environment variable is not part of the environment. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-11 21:24 Message: Logged In: YES user_id=469548 Closing per last comment. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-10-19 23:14 Message: Logged In: YES user_id=341410 There is a more complete os.path.expanduser patch for NT based systems here: http://python.org/sf/957650 I would suggest closing this patch for two reasons: 1. The submitter did not provide test cases nor output. 2. The issues solved by this patch are subsumed by the patch provided in the url above. If the submitter can offer test cases and an updated patch (against some reasonably current CVS), the submitter's patch is still incomplete with regards to the equivalent posix expanduser code, and I would suggest closing this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=643943&group_id=5470 From noreply at sourceforge.net Thu Nov 11 21:29:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 11 21:29:57 2004 Subject: [Patches] [ python-Patches-632934 ] Problem at the end of misformed mailbox Message-ID: Patches item #632934, was opened at 2002-11-03 17:50 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=632934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R?mi Peyronnet (rpeyron) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Problem at the end of misformed mailbox Initial Comment: I had a problem with a not well formed mailbox (maybe ambiguous carriage return chars, due to both use under windows and linux) : the function mailbox.readlines (lib/mailbox.py:66) entered in an indefinite cycle. I found that the self.stop value was too big for the file, and that the index of self.pos could not go that far. The function readlines will call ever and ever readline, which will return always the same 1-length string. I solved this by comparing the fp.pos before and after the read operation. If it the same, we re probably at the end of the file, or there is a problem, and we should go out. As I do not know much about the Python internals, the following patch may not be good : C:\Python222\Lib>diff "Copie de mailbox.py" mailbox.py 63c63,68 < self.pos = self.fp.tell() --- > data = self.fp.readline(length) > self_fp_tell = self.fp.tell() > if self.pos == self_fp_tell: > return '' > else: > self.pos = self_fp_tell Regards ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-11 21:29 Message: Logged In: YES user_id=469548 R?mi, could you attach the mailbox (or a similar mailbox) that triggers the problem? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-21 21:03 Message: Logged In: YES user_id=31435 Assigned to Barry. Maybe y'all can polish this one off during the email sprint? ---------------------------------------------------------------------- Comment By: R?mi Peyronnet (rpeyron) Date: 2003-12-27 19:48 Message: Logged In: YES user_id=641559 This problem seems to exist in 2.3 version too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=632934&group_id=5470 From noreply at sourceforge.net Thu Nov 11 23:20:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 11 23:20:52 2004 Subject: [Patches] [ python-Patches-1038854 ] Fix struct.pack on 64-bit archs (broken on 2.*) Message-ID: Patches item #1038854, was opened at 2004-10-02 07:07 Message generated for change (Comment added) made by sgatwasetde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Grundmann (sgatwasetde) Assigned to: Nobody/Anonymous (nobody) Summary: Fix struct.pack on 64-bit archs (broken on 2.*) Initial Comment: Description: The code in the struct module assumes that sizeof(long) == sizeof(int) which is wrong on (most) 64-bit architectures (linux on amd64 with a 32-bit userland is an exception). How To Repeat: on a 32-bit platform struct.pack behaves as expected: $ uname -m -r -s FreeBSD 4.10-STABLE i386 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert on a 64-bit platform it treats integers as longs (it does not check for over/underflows and returns the lower 4 byte): $ uname -m -r -s FreeBSD 5.2-CURRENT sparc64 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" '\x00\x00\x00\x00' Fix: in python/python/dist/src/Modules/structmodule.c: np_uint() and np_int() have to check for over/underflows using MAX_UINT, MAX_INT, MIN_INT as np_ushort() and np_short() already do for MAX_USHORT, ... the attached patch does this (diff was generated using diff -rNu and Revision 2.62 of python/python/dist/src/Modules/structmodule.c) ---------------------------------------------------------------------- >Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-11-11 23:20 Message: Logged In: YES user_id=1131807 Issuing a warning instead of an error might be a good idea (to give the user-base some time adapt). But then we still have to deal with the fact that the some python modules are broken on 64 bit (at least big-endian). The gzip module for example does not work correctly even with the old code (because of stuctmodule). And there is user code out there that relies on correct overflow detection (which was the reason i submitted the patch). Another way would be to omit the overflow detection completely and heave the user take care of it. This will break a lot of applications but is imho more consistent then the old behavior (check some cases on some architectures). Personally i would like to have a structmodule in python 2.4 that works a one would expect (overflow detection) but that is not my decision to make. The fact that code which is under control of the python project uses struct.pack (...) in erroneous ways should be fixed (even if it does work on 32 bit archs atm). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-11-10 22:31 Message: Logged In: YES user_id=4771 This indicate that similar breakage will probably occur in user code if we add range checking. Do we want to take the risk? It looks overkill, but what about issuing a warning and turning it into an error in the next version? ---------------------------------------------------------------------- Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-11-10 09:36 Message: Logged In: YES user_id=1131807 The patch breaks test_binhex on 32 and 64 bit architectures because Lib/binhex.py is using struct.pack('>h' ...) to pack an unsigned short (which is wrong but does work with the current version of Modules/structmodule.c because of the lack of range checking). The patch breaks test_gzip (and test_tarfile) on 64 bit architectures because Lib/gzip.py is using write32 (which uses to pack('I',...) fail to detect the overflow in the same way? If so, can you also provide the patch for these 4 other routines? Finally, it would be nice to add a test case in Lib/test/test_struct.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 From noreply at sourceforge.net Fri Nov 12 16:48:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 12 16:49:03 2004 Subject: [Patches] [ python-Patches-1065257 ] httplib: allowing stream-type body part in requests Message-ID: Patches item #1065257, was opened at 2004-11-12 15:48 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=1065257&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alessandro Forghieri (alien_life_form) Assigned to: Nobody/Anonymous (nobody) Summary: httplib: allowing stream-type body part in requests Initial Comment: Greetings. The attached patch makes it possible to use a file-like object in httplib requests (useful to PUT large files without exhausting the machine memory - think a DAV server). The supplied object must be able to read(). If Content-Length support is desired, the body object must either have a __length__ method (so len(body) works) OR have a stat-able "name" property (file objects are in the second category). Having applied this patch the following works: import httplib import base64 hh={} auth = base64.encodestring("%s:%s" % ("guest","guest")).rstrip() hh['Authorization']='Basic %s' % auth conn=HTTPConnection('localhost',8080) conn.debuglevel=99 thestream=open(r'\tmp\huge.pdf','rb') conn.request('PUT', '/dav/streamed', thestream,hh) thestream.close() rsp=conn.getresponse() print rsp.status,"-",rsp.reason,repr(rsp.msg.dict),rsp.read() conn.close() Opening in 'rb' mode - on windoze - is important for this to work, or the content length header will be wrong, which is probably BAD. Alessandro Forghieri ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1065257&group_id=5470 From betamagalhaes34kjd4 at hotmail.com Fri Nov 12 17:56:04 2004 From: betamagalhaes34kjd4 at hotmail.com (Roberta Magalhães) Date: Fri Nov 12 17:55:53 2004 Subject: [Patches] Cadastros de e-mails Message-ID: <20041112165551.D66471E4005@bag.python.org> Cadastros de e-mails para mala direta e e-mail marketing. Listas atualizadas e personalizadas. Visite agora: http://www.gueb.de/dvgamail MALA DIRETA, email, E-MAILS PARA MALAS DIRETAS, E-mails por segmenta??o, listas, emails por segmento, Programas gr?tis, Listas, divulga??o por e-mail, spam, softwares gratuitos, mala direta, listas de e-mails, divulga??o de sites e promo??o de home pages, http://www.gueb.de/dvgamail From noreply at sourceforge.net Sat Nov 13 12:14:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 13 12:14:32 2004 Subject: [Patches] [ python-Patches-1050475 ] Fix various x86_64 build issues Message-ID: Patches item #1050475, was opened at 2004-10-20 06:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1050475&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Nobody/Anonymous (nobody) Summary: Fix various x86_64 build issues Initial Comment: This patch does the following: Puts the correct library directories for linux x86_64 systems into setup.py search paths. Fixes a type-casting bug in the _tkinter module that would cause incorrect pointer printing on 64-bit systems (a pointer was cast to an int). Adds imageop and rgbimg to the list of expected to be skipped tests on 64-bit platforms With these changes, I get a clean build and a clean "make test". I also ran the regression suite in '-uall' mode. This was mostly good, and the few errors that occurred do not appear related to x86_64. (Well, with the possible exception of some linux audio-related cores which I don't know about yet) /Bob ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-11-13 12:14 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as setup.py 1.204 regrtest.py 1.165 _tkinter.c 1.168 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1050475&group_id=5470 From ricardobssilverio2kd at mail.com Sun Nov 14 00:05:38 2004 From: ricardobssilverio2kd at mail.com (Ricardo Silverio) Date: Sun Nov 14 00:05:24 2004 Subject: [Patches] e-mails para mala direta Message-ID: <20041113230521.A10751E4002@bag.python.org> MALA DIRETA, email, E-MAILS PARA MALAS DIRETAS, E-mails por segmenta??o, listas, emails por segmento Cadastros de e-mails para mala direta e e-mail marketing. Listas atualizadas e personalizadas. http://www.estacion.de/maladireta Listas de e-mails, divulga??o de sites e promo??o de home pages,Programas gr?tis, Listas, divulga??o por e-mail, spam, softwares gratuitos, mala direta, http://www.estacion.de/maladireta From noreply at sourceforge.net Sun Nov 14 02:36:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 14 02:36:58 2004 Subject: [Patches] [ python-Patches-1065986 ] Fix pydoc crashing on unicode strings Message-ID: Patches item #1065986, was opened at 2004-11-14 03:36 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=1065986&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Fix pydoc crashing on unicode strings Initial Comment: The pydoc module currently only outputs ASCII and crashes with UnicodeEncodeError when printing a unicode string (in contexts where it prints the str rather than a repr, e.g. docstrings or variables like `__credits__`). The most ironic example of it is that since patch 1009389 was committed, ``pydoc.py pydoc`` crashes on its own `__credits__`! This patch changes pydoc help functions to return unicode strings only when needed; it returns ASCII strings if all characters are from ASCII. Therefore there should be no compatibility problems. For output, all pager functions were changed to encode to the locale's preferred encoding and HTML output was changed to always use UTF-8. cgitb.py, DocXMLRPCServer.py and/or SimpleXMLRPCServer.py seems to rely on pydoc to some degree. I didn't touch them, so they might still be broken in this respect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1065986&group_id=5470 From noreply at sourceforge.net Sun Nov 14 02:39:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 14 02:39:37 2004 Subject: [Patches] [ python-Patches-1009389 ] Non-ascii in non-unicode __credits__ in Lib/pydoc.py Message-ID: Patches item #1009389, was opened at 2004-08-15 04:35 Message generated for change (Comment added) made by cben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 Category: Documentation Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Non-ascii in non-unicode __credits__ in Lib/pydoc.py Initial Comment: There are non-ASCII chars in pydoc.__credits__ (the "o/" in "Mynd you, mo/o/se bites Kan be pretty nasti..."). In 2.3, a locale declaration of Latin-1 was added to pydoc.py. So now Python does not complain -- but a string object (carrying no encoding info) with Latin-1 bytes is still created and anynoby running in a non-Latin-1 locale will not interpret the string correctly. The patch fixes it by making pydoc.__credits__ a Unicode string. *Note that this may break code* that prints pydoc.__credits__ (in locales that can't encode it) or otherwise assumes it's a string. Not that such code exists anywhere... Wait, ``import pydoc; help(pydoc)`` in "C" locale now crashes ! This is too ironic, IMHO, *don't commit* until pydoc learns to handle unicode robustly... ---------------------------------------------------------------------- >Comment By: Cherniavsky Beni (cben) Date: 2004-11-14 03:39 Message: Logged In: YES user_id=36166 I told you not to commit! Now ``pydoc.py pydoc`` crashes. Patch 1065986 fixes this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 19:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as pydoc.py 1.96. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 From noreply at sourceforge.net Sun Nov 14 11:21:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 14 11:21:32 2004 Subject: [Patches] [ python-Patches-1009389 ] Non-ascii in non-unicode __credits__ in Lib/pydoc.py Message-ID: Patches item #1009389, was opened at 2004-08-15 03:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 Category: Documentation Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Non-ascii in non-unicode __credits__ in Lib/pydoc.py Initial Comment: There are non-ASCII chars in pydoc.__credits__ (the "o/" in "Mynd you, mo/o/se bites Kan be pretty nasti..."). In 2.3, a locale declaration of Latin-1 was added to pydoc.py. So now Python does not complain -- but a string object (carrying no encoding info) with Latin-1 bytes is still created and anynoby running in a non-Latin-1 locale will not interpret the string correctly. The patch fixes it by making pydoc.__credits__ a Unicode string. *Note that this may break code* that prints pydoc.__credits__ (in locales that can't encode it) or otherwise assumes it's a string. Not that such code exists anywhere... Wait, ``import pydoc; help(pydoc)`` in "C" locale now crashes ! This is too ironic, IMHO, *don't commit* until pydoc learns to handle unicode robustly... ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-11-14 11:21 Message: Logged In: YES user_id=21627 Ok, I have now backed-out the patch again. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-11-14 02:39 Message: Logged In: YES user_id=36166 I told you not to commit! Now ``pydoc.py pydoc`` crashes. Patch 1065986 fixes this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 18:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as pydoc.py 1.96. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 From noreply at sourceforge.net Sun Nov 14 11:21:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 14 11:21:46 2004 Subject: [Patches] [ python-Patches-1009389 ] Non-ascii in non-unicode __credits__ in Lib/pydoc.py Message-ID: Patches item #1009389, was opened at 2004-08-15 03:35 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Non-ascii in non-unicode __credits__ in Lib/pydoc.py Initial Comment: There are non-ASCII chars in pydoc.__credits__ (the "o/" in "Mynd you, mo/o/se bites Kan be pretty nasti..."). In 2.3, a locale declaration of Latin-1 was added to pydoc.py. So now Python does not complain -- but a string object (carrying no encoding info) with Latin-1 bytes is still created and anynoby running in a non-Latin-1 locale will not interpret the string correctly. The patch fixes it by making pydoc.__credits__ a Unicode string. *Note that this may break code* that prints pydoc.__credits__ (in locales that can't encode it) or otherwise assumes it's a string. Not that such code exists anywhere... Wait, ``import pydoc; help(pydoc)`` in "C" locale now crashes ! This is too ironic, IMHO, *don't commit* until pydoc learns to handle unicode robustly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-14 11:21 Message: Logged In: YES user_id=21627 Ok, I have now backed-out the patch again. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-11-14 02:39 Message: Logged In: YES user_id=36166 I told you not to commit! Now ``pydoc.py pydoc`` crashes. Patch 1065986 fixes this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 18:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as pydoc.py 1.96. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 From noreply at sourceforge.net Sun Nov 14 11:22:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 14 11:22:36 2004 Subject: [Patches] [ python-Patches-1065986 ] Fix pydoc crashing on unicode strings Message-ID: Patches item #1065986, was opened at 2004-11-14 02:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1065986&group_id=5470 Category: Library (Lib) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Fix pydoc crashing on unicode strings Initial Comment: The pydoc module currently only outputs ASCII and crashes with UnicodeEncodeError when printing a unicode string (in contexts where it prints the str rather than a repr, e.g. docstrings or variables like `__credits__`). The most ironic example of it is that since patch 1009389 was committed, ``pydoc.py pydoc`` crashes on its own `__credits__`! This patch changes pydoc help functions to return unicode strings only when needed; it returns ASCII strings if all characters are from ASCII. Therefore there should be no compatibility problems. For output, all pager functions were changed to encode to the locale's preferred encoding and HTML output was changed to always use UTF-8. cgitb.py, DocXMLRPCServer.py and/or SimpleXMLRPCServer.py seems to rely on pydoc to some degree. I didn't touch them, so they might still be broken in this respect. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-11-14 11:22 Message: Logged In: YES user_id=21627 This is a too major change so short before the 2.4 release, so postponing it 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1065986&group_id=5470 From noreply at sourceforge.net Sun Nov 14 23:48:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 14 23:48:42 2004 Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304) Message-ID: Patches item #677103, was opened at 2003-01-29 16:49 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: PYTHONBYTECODEBASE patch (PEP 304) Initial Comment: This is just a placeholder patch related to PEP 304. Feel free to comment on it. It's far from complete at this point. The first patch is just to see if we can do all the proper detection at startup. These checks have to be performed before any .py files are imported, otherwise you'd have some .pyc files dumped out before the machinery is ready to go. The first patch contains mods to sysmodule.c with next to no concern for platform independence. There is a small shell script and a few expected output files which are used to test setting of various values. These should probably be wrapped into regular PyUnit tests which popen() the interpreter with different settings, but this seemed quicker as a start. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-11-14 16:48 Message: Logged In: YES user_id=44345 Patch updated for current CVS (~ 2.4b2). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-31 11:37 Message: Logged In: YES user_id=44345 Another patch. This one fixes the problems of the one I withdrew yesterday. There are still problems: * A half dozen regression tests fail for various reasons which I haven't completely investigated. * Nothing has been done for Windows. Someone will have to step up to the plate for this. I can't build on Windows. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 16:51 Message: Logged In: YES user_id=44345 While not technically broken, the patch I just posted is a bit bent. Withdrawing for a little fixup... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 16:33 Message: Logged In: YES user_id=44345 Here's an updated context diff. It seems to do the right thing on my Mac OS X system. It won't currently do anything on Windows ( need help there). No more test cases, but if PYTHONBYTECODEBASE points to a valid directory, the .pyc files seem to get put in all the right places. To get the behavior, you'll have to configure --with-bytecodebase. Feedback, please... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-29 16:52 Message: Logged In: YES user_id=44345 second upload try - what the hell is with SF? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 From noreply at sourceforge.net Mon Nov 15 00:12:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 15 00:12:36 2004 Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304) Message-ID: Patches item #677103, was opened at 2003-01-29 16:49 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: PYTHONBYTECODEBASE patch (PEP 304) Initial Comment: This is just a placeholder patch related to PEP 304. Feel free to comment on it. It's far from complete at this point. The first patch is just to see if we can do all the proper detection at startup. These checks have to be performed before any .py files are imported, otherwise you'd have some .pyc files dumped out before the machinery is ready to go. The first patch contains mods to sysmodule.c with next to no concern for platform independence. There is a small shell script and a few expected output files which are used to test setting of various values. These should probably be wrapped into regular PyUnit tests which popen() the interpreter with different settings, but this seemed quicker as a start. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-11-14 17:12 Message: Logged In: YES user_id=44345 *sigh* - let's try again... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-14 16:48 Message: Logged In: YES user_id=44345 Patch updated for current CVS (~ 2.4b2). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-31 11:37 Message: Logged In: YES user_id=44345 Another patch. This one fixes the problems of the one I withdrew yesterday. There are still problems: * A half dozen regression tests fail for various reasons which I haven't completely investigated. * Nothing has been done for Windows. Someone will have to step up to the plate for this. I can't build on Windows. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 16:51 Message: Logged In: YES user_id=44345 While not technically broken, the patch I just posted is a bit bent. Withdrawing for a little fixup... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 16:33 Message: Logged In: YES user_id=44345 Here's an updated context diff. It seems to do the right thing on my Mac OS X system. It won't currently do anything on Windows ( need help there). No more test cases, but if PYTHONBYTECODEBASE points to a valid directory, the .pyc files seem to get put in all the right places. To get the behavior, you'll have to configure --with-bytecodebase. Feedback, please... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-29 16:52 Message: Logged In: YES user_id=44345 second upload try - what the hell is with SF? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 From noreply at sourceforge.net Wed Nov 17 02:28:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 17 02:28:26 2004 Subject: [Patches] [ python-Patches-1067760 ] fix for 1067728: Better handling of float arguments to seek Message-ID: Patches item #1067760, was opened at 2004-11-17 01: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=1067760&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Church (churchr) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 1067728: Better handling of float arguments to seek Initial Comment: Instead of converting all float arguments to ints, this first attempts to convert the argument to a PyLong, and then the old conversion code takes over. The upshot is that the limit of floating point arguments to seek() is raised from (2 ** 32) - 1 to somewhere above (2 ** 62). Perhaps a better way to handle this would be to not accept floating point arguments to seek(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470 From noreply at sourceforge.net Wed Nov 17 12:44:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 17 12:44:53 2004 Subject: [Patches] [ python-Patches-1009389 ] Non-ascii in non-unicode __credits__ in Lib/pydoc.py Message-ID: Patches item #1009389, was opened at 2004-08-14 18:35 Message generated for change (Comment added) made by ping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Non-ascii in non-unicode __credits__ in Lib/pydoc.py Initial Comment: There are non-ASCII chars in pydoc.__credits__ (the "o/" in "Mynd you, mo/o/se bites Kan be pretty nasti..."). In 2.3, a locale declaration of Latin-1 was added to pydoc.py. So now Python does not complain -- but a string object (carrying no encoding info) with Latin-1 bytes is still created and anynoby running in a non-Latin-1 locale will not interpret the string correctly. The patch fixes it by making pydoc.__credits__ a Unicode string. *Note that this may break code* that prints pydoc.__credits__ (in locales that can't encode it) or otherwise assumes it's a string. Not that such code exists anywhere... Wait, ``import pydoc; help(pydoc)`` in "C" locale now crashes ! This is too ironic, IMHO, *don't commit* until pydoc learns to handle unicode robustly... ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2004-11-17 03:44 Message: Logged In: YES user_id=45338 I'm so sorry this has caused so much trouble. The silly moose comment is my fault; it can just be removed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-14 02:21 Message: Logged In: YES user_id=21627 Ok, I have now backed-out the patch again. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-11-13 17:39 Message: Logged In: YES user_id=36166 I told you not to commit! Now ``pydoc.py pydoc`` crashes. Patch 1065986 fixes this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 09:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as pydoc.py 1.96. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 From noreply at sourceforge.net Wed Nov 17 12:45:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 17 12:45:23 2004 Subject: [Patches] [ python-Patches-1065986 ] Fix pydoc crashing on unicode strings Message-ID: Patches item #1065986, was opened at 2004-11-13 17:36 Message generated for change (Comment added) made by ping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1065986&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Fix pydoc crashing on unicode strings Initial Comment: The pydoc module currently only outputs ASCII and crashes with UnicodeEncodeError when printing a unicode string (in contexts where it prints the str rather than a repr, e.g. docstrings or variables like `__credits__`). The most ironic example of it is that since patch 1009389 was committed, ``pydoc.py pydoc`` crashes on its own `__credits__`! This patch changes pydoc help functions to return unicode strings only when needed; it returns ASCII strings if all characters are from ASCII. Therefore there should be no compatibility problems. For output, all pager functions were changed to encode to the locale's preferred encoding and HTML output was changed to always use UTF-8. cgitb.py, DocXMLRPCServer.py and/or SimpleXMLRPCServer.py seems to rely on pydoc to some degree. I didn't touch them, so they might still be broken in this respect. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2004-11-17 03:45 Message: Logged In: YES user_id=45338 I'm so sorry this has caused so much trouble. The silly moose comment is my fault; it can be removed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-14 02:22 Message: Logged In: YES user_id=21627 This is a too major change so short before the 2.4 release, so postponing it 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1065986&group_id=5470 From noreply at sourceforge.net Wed Nov 17 22:20:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 17 22:20:06 2004 Subject: [Patches] [ python-Patches-1068277 ] os.path.exists returns False if no permission Message-ID: Patches item #1068277, was opened at 2004-11-17 21:20 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=1068277&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Robert Brewer (aminusfu) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists returns False if no permission Initial Comment: A single new sentence for os.path.exists description, which makes it clear that it may return False even if the path actually exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068277&group_id=5470 From noreply at sourceforge.net Thu Nov 18 06:01:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 18 06:01:32 2004 Subject: [Patches] [ python-Patches-1068456 ] small update for pdb docs Message-ID: Patches item #1068456, was opened at 2004-11-17 21:01 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=1068456&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: small update for pdb docs Initial Comment: Description of new functionality implemented in the patch 896011 (the original patch is already closed, so submitting it as a new patch) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068456&group_id=5470 From noreply at sourceforge.net Thu Nov 18 07:14:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 18 07:14:51 2004 Subject: [Patches] [ python-Patches-1068456 ] small update for pdb docs Message-ID: Patches item #1068456, was opened at 2004-11-18 00:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068456&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: small update for pdb docs Initial Comment: Description of new functionality implemented in the patch 896011 (the original patch is already closed, so submitting it as a new patch) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-18 01:14 Message: Logged In: YES user_id=80475 Okay, clarified the text. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068456&group_id=5470 From noreply at sourceforge.net Fri Nov 19 20:00:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 19 20:00:23 2004 Subject: [Patches] [ python-Patches-1069624 ] incomplete support for AF_PACKET in socketmodule.c Message-ID: Patches item #1069624, was opened at 2004-11-19 19: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=1069624&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: incomplete support for AF_PACKET in socketmodule.c Initial Comment: A comment in the source documents the AF_PACKET address format: - an AF_PACKET socket address is a tuple containing a string specifying the ethernet interface and an integer specifying the Ethernet protocol number to be received. For example: ("eth0",0x1234). Optional 3rd,4th,5th elements in the tuple specify packet-type and ha-type/addr -- these are ignored by networking code, but accepted since they are returned by the getsockname() method. The part that says "these are ignored by networking code," is clearly innacurate when comparing with the packet(7) man page: "(...)Packets sent through a SOCK_DGRAM packet socket get a suitable physical layer header based on the information in the sockaddr_ll destination address before they are queued.(...)" Attached patch copies the passed in addr into the sockaddr structure. It is against Python 2.3.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1069624&group_id=5470 From noreply at sourceforge.net Fri Nov 19 20:19:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 19 20:19:55 2004 Subject: [Patches] [ python-Patches-1069624 ] incomplete support for AF_PACKET in socketmodule.c Message-ID: Patches item #1069624, was opened at 2004-11-19 19:00 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1069624&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: incomplete support for AF_PACKET in socketmodule.c Initial Comment: A comment in the source documents the AF_PACKET address format: - an AF_PACKET socket address is a tuple containing a string specifying the ethernet interface and an integer specifying the Ethernet protocol number to be received. For example: ("eth0",0x1234). Optional 3rd,4th,5th elements in the tuple specify packet-type and ha-type/addr -- these are ignored by networking code, but accepted since they are returned by the getsockname() method. The part that says "these are ignored by networking code," is clearly innacurate when comparing with the packet(7) man page: "(...)Packets sent through a SOCK_DGRAM packet socket get a suitable physical layer header based on the information in the sockaddr_ll destination address before they are queued.(...)" Attached patch copies the passed in addr into the sockaddr structure. It is against Python 2.3.4. ---------------------------------------------------------------------- >Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-11-19 19:19 Message: Logged In: YES user_id=908 And just now I actually tested this patch. It works! While before the ethernet frame was sent with broadcast destination address, now it goes with a correct destination address. This should go into python 2.3.x as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1069624&group_id=5470 From noreply at sourceforge.net Sat Nov 20 16:36:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 20 16:36:17 2004 Subject: [Patches] [ python-Patches-1070046 ] xmlrpclib - marshalling new-style classes. Message-ID: Patches item #1070046, was opened at 2004-11-20 16:36 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=1070046&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Pastor (gabrielpastor) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib - marshalling new-style classes. Initial Comment: This bug is linked to bug 469972. Tested with python 2.3.4 Bug desciption: Using xmlrpclib today (version 1.0.1) we can marshall old-style classes, but new style classes cannot be marshalled. E.g. import xmlrpclib class NewObject(object): def __init__(self): self.mytype = 'new' class OldObject: def __init__(self): self.mytype = 'old' print xmlrpclib.dumps((OldObject(),)) # result OK, marshalled as a struct print xmlrpclib.dumps((NewObject(),)) # TypeError: cannot marshal # objects So the module doesn't behave in the same way with new-style classes. Bug analysis: The problem is that xmlrpclib try to guess how to marshall an object using the type() method (see line 612), but old-style classes have type 'InstanceType' whereas new-style classes are of type 'ObjectType'. Furthermore as described in bug 469972 we don't know how to marshal class sub-classing builtin types (string, int, etc) Patch proposed: The problem is in the _dump method,. We have this code : try: f = self.dispatch[type(value)] except KeyError: # here goes the patch ! Currently with new-style classes we have a KeyError exception since the ObjectType is not in the key list of self.dispatch. As all objects(string , dict, user defined classes...) in Python now have type 'ObjectType' we cannot just add a line: dispatch[ObjectType] = dump_instance In the KeyError, the patch checks if the object has a dictionnary. Because in this case it is probably a good candidate for being marshalled as a struct. And then the patch checks that the object doesn't inherit from a basic type (int, string etc.. : in fact all the types that are 'normally' marshalled). And if these 2 conditions are OK, this object is marshalled like old-style classes. The proposed patch doesn't change xmlrpclib behaviour for all basic types, and old-style classes since only the 'except KeyError' was changed. Gabriel Pastor ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1070046&group_id=5470 From noreply at sourceforge.net Sat Nov 20 22:58:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 20 22:58:26 2004 Subject: [Patches] [ python-Patches-1070218 ] Add BLANK_LINE to token.py Message-ID: Patches item #1070218, was opened at 2004-11-20 15:58 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=1070218&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: Add BLANK_LINE to token.py Initial Comment: The parser module generates an ast node number 54 for an entirely blank line. These lines are apparently ignored by the real parser, and don't have a real definition in include\token.h. Presumably because of that they don't have an entry in token.py. However, this broke an app where I hardcoded the number and recent language features have changed the mapping of numbers to token names. I think there should be a BLANK_LINE defined in token.py so that it can be referred to by name, even if it's not used in the real parser. While dealing with parsermodule generated ast-trees, "symbol.sym_name[node] or token.tok_name[node]" should always be true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1070218&group_id=5470 From noreply at sourceforge.net Mon Nov 22 01:41:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 22 01:41:29 2004 Subject: [Patches] [ python-Patches-1070218 ] Add BLANK_LINE to token.py Message-ID: Patches item #1070218, was opened at 2004-11-20 15:58 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1070218&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: Add BLANK_LINE to token.py Initial Comment: The parser module generates an ast node number 54 for an entirely blank line. These lines are apparently ignored by the real parser, and don't have a real definition in include\token.h. Presumably because of that they don't have an entry in token.py. However, this broke an app where I hardcoded the number and recent language features have changed the mapping of numbers to token names. I think there should be a BLANK_LINE defined in token.py so that it can be referred to by name, even if it's not used in the real parser. While dealing with parsermodule generated ast-trees, "symbol.sym_name[node] or token.tok_name[node]" should always be true. ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2004-11-21 18:41 Message: Logged In: YES user_id=699438 A few clarifications: On further review, the node number 54 comes from tokenize.py, not the parsermodule. I also meant to say that "symbol.sym_name.has_key(node) or token.tok_name.has_key(node)" should always be true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1070218&group_id=5470 From noreply at sourceforge.net Mon Nov 22 23:51:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 22 23:51:29 2004 Subject: [Patches] [ python-Patches-632934 ] Problem at the end of misformed mailbox Message-ID: Patches item #632934, was opened at 2002-11-03 17:50 Message generated for change (Comment added) made by rpeyron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=632934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R?mi Peyronnet (rpeyron) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Problem at the end of misformed mailbox Initial Comment: I had a problem with a not well formed mailbox (maybe ambiguous carriage return chars, due to both use under windows and linux) : the function mailbox.readlines (lib/mailbox.py:66) entered in an indefinite cycle. I found that the self.stop value was too big for the file, and that the index of self.pos could not go that far. The function readlines will call ever and ever readline, which will return always the same 1-length string. I solved this by comparing the fp.pos before and after the read operation. If it the same, we re probably at the end of the file, or there is a problem, and we should go out. As I do not know much about the Python internals, the following patch may not be good : C:\Python222\Lib>diff "Copie de mailbox.py" mailbox.py 63c63,68 < self.pos = self.fp.tell() --- > data = self.fp.readline(length) > self_fp_tell = self.fp.tell() > if self.pos == self_fp_tell: > return '' > else: > self.pos = self_fp_tell Regards ---------------------------------------------------------------------- >Comment By: R?mi Peyronnet (rpeyron) Date: 2004-11-22 23:51 Message: Logged In: YES user_id=641559 Sorry, I did not keep the mailbox. I may re-use this script in a few weeks/months, and if it does the same thing I will attach one. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-11 21:29 Message: Logged In: YES user_id=469548 R?mi, could you attach the mailbox (or a similar mailbox) that triggers the problem? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-21 21:03 Message: Logged In: YES user_id=31435 Assigned to Barry. Maybe y'all can polish this one off during the email sprint? ---------------------------------------------------------------------- Comment By: R?mi Peyronnet (rpeyron) Date: 2003-12-27 19:48 Message: Logged In: YES user_id=641559 This problem seems to exist in 2.3 version too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=632934&group_id=5470 From noreply at sourceforge.net Tue Nov 23 15:14:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 23 15:14:26 2004 Subject: [Patches] [ python-Patches-1071739 ] bug#1021756: more informative error message Message-ID: Patches item #1071739, was opened at 2004-11-23 16: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=1071739&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: bug#1021756: more informative error message Initial Comment: The following patch offers a better explanation in case the MS VC++ (free) toolkit is installed but the .NET Framework SDK is not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071739&group_id=5470 From noreply at sourceforge.net Tue Nov 23 15:35:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 23 15:35:17 2004 Subject: [Patches] [ python-Patches-1071755 ] raise error for common mistake with subprocess Message-ID: Patches item #1071755, was opened at 2004-11-23 14:35 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=1071755&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Craig-Wood (ncw) Assigned to: Nobody/Anonymous (nobody) Summary: raise error for common mistake with subprocess Initial Comment: subprocess has a very easy to mistake error in it - forgetting to pass the command as a list. Eg >>> import subprocess >>> subprocess.call("ls") BaseHTTPServer.py dummy_threading.py pickletools.py socket.py Bastion.py email pipes.py sre.py [...] dummy_thread.py pickle.pyc sndhdr.py zipfile.py 0 >>> subprocess.call("ls", "-l") BaseHTTPServer.py dummy_threading.py pickletools.py socket.py Bastion.py email pipes.py sre.py [...] dummy_thread.py pickle.pyc sndhdr.py zipfile.py 0 >>> # Note no error, warning or anything, but no "ls -l" either And with the patch... >>> subprocess.call("ls", "-l") Traceback (most recent call last): File "", line 1, in ? File "subprocess.py", line 428, in call return Popen(*args, **kwargs).wait() File "subprocess.py", line 508, in __init__ raise TypeError("bufsize must be an integer - " TypeError: bufsize must be an integer - did you forget to pass your arguments in a list? >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071755&group_id=5470 From noreply at sourceforge.net Tue Nov 23 15:45:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 23 15:45:26 2004 Subject: [Patches] [ python-Patches-1071764 ] a new subprocess.call which raises an error on non-zero rc Message-ID: Patches item #1071764, was opened at 2004-11-23 14: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=1071764&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Craig-Wood (ncw) Assigned to: Nobody/Anonymous (nobody) Summary: a new subprocess.call which raises an error on non-zero rc Initial Comment: The attached patch introduces a 3rd utility function - xcall() to the subprocess module. This function acts just like call but raises errors if the command had a non-zero return code. This saves writing if call(...): raise OSError(...) It is most useful for shell script replacement programming. Checking the return codes of commands called is often forgotten in shell programming. When you've moved up to python because shell is too limiting (usually about 10 lines of shell in my case ;-) you want to make sure that all your commands work so you write robust code. I consider raising an exception to be much more pythonic than checking a return code (ie "Errors should never pass silently" from Zen of Python) Eg # An easy to miss error >>> subprocess.call(["mkdir", "a/b"]) mkdir: cannot create directory `a/b': No such file or directory 1 >>> # user forgot to check non-zero return code # becomes an impossible to miss exception >>> subprocess.xcall(["mkdir", "a/b"]) mkdir: cannot create directory `a/b': No such file or directory Traceback (most recent call last): File "", line 1, in ? File "subprocess.py", line 462, in xcall raise CalledProcessError(rc, "Command %s returned non zero exit status" % args[0]) subprocess.CalledProcessError: [Errno 1] Command ['mkdir', 'a/b'] returned non zero exit status >>> See attached patch for more! Its been tested under python 2.3 on windows and linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470 From noreply at sourceforge.net Tue Nov 23 17:18:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 23 17:19:07 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-11-23 17:18 Message: Logged In: YES user_id=192186 After long delay I finally found time to look at this. I decided to go other way that doesn't need soo much modifications. Instead of adding directories during copying and messing all the code, it now just postproceses filelist and generates directory list out of that. This leads to much smaller patch and need to modify just one file. I'd like to hear comments from you. I currently tested just few packages and I'll give it more testing in next days. Patch is against 2.4c1. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:09 Message: Logged In: YES user_id=21627 Alternatively, adding --record-dirs to the install command would be acceptable as well, so you could post-process the directory list, e.g. with awk. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:07 Message: Logged In: YES user_id=21627 This might work. bdist_rpm would have to invoke the install command, but only to compute the file list, instead of actually performing copying. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-04 22:33 Message: Logged In: YES user_id=192186 It's pripary purpose is IMHO to allow building of rpms when you distribute some python stuff. It is good for this case. The problem for distributions, is that all packages need to be handled same way (in case they use some automatically building system), so you can not differ whether it is packaged some python stuff or kernel. So separate spec file and sources is the only solution. Generating spec file doesn't help much as it can get changed every version and vendor has own additional information in spec file, which would require hand merging. Another idea I just got is to generate just file list using separate bdist_rpm and use it separately, but I'm not sure whether it is doable - information about file list is not probably available there, is it? It would be used like: python setup.py install --root=$RPM_BUILD_ROOT python setup.py bdist_rpm --filelist=INSTALLED_FILES ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 22:19 Message: Logged In: YES user_id=21627 It is unfortunate that bdist_rpm is not useful to generate RPMs for distribution, because this is the primary purpose of that command: generating RPMs. So if the command does not meet your needs, we should change it to make it meet your needs. E.g. would it help if bdist_rpm would generate the .spec file for you? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-03 19:50 Message: Logged In: YES user_id=192186 As I said bdist_rpm is not suitable for building packages in distribution - all packages are built same way using spec file and sources (+patches). And this building packages for distribution (I work for SUSE) is main goal why I did this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:20 Message: Logged In: YES user_id=21627 I see. Wouldn't it better if the bdist_rpm command would generate a .spec file that completely contains all directives? Then, this could be enhanced to make use of more features of RPMs, such as %doc, %docdir, %verify, etc. It would also allow to keep RPM specifics out of the install command. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 23:04 Message: Logged In: YES user_id=192186 It does extend --record with directory entries. This resulting file is then used by rpm: %install python setup.py install --root=$RPM_BUILD_ROOT --record-rpm=INSTALLED_FILES %files -f INSTALLED_FILES %defattr(-,root,root) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:00 Message: Logged In: YES user_id=21627 Then I don't understand how your patch works: Does it not generate %dir lines for the .spec file? And isn't the spec file generated by the bdist_rpm command? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Tue Nov 23 18:11:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 23 18:11:49 2004 Subject: [Patches] [ python-Patches-1071911 ] Add support for db 4.3 Message-ID: Patches item #1071911, was opened at 2004-11-23 18:11 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=1071911&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for db 4.3 Initial Comment: Hi, attached patch adds support for db 4.3. It doens't cover almost no new constants (only one that was at least in 4.2), but just allows compiling. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071911&group_id=5470 From noreply at sourceforge.net Tue Nov 23 20:06:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 23 20:06:48 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-11-23 17:18 Message: Logged In: YES user_id=192186 After long delay I finally found time to look at this. I decided to go other way that doesn't need soo much modifications. Instead of adding directories during copying and messing all the code, it now just postproceses filelist and generates directory list out of that. This leads to much smaller patch and need to modify just one file. I'd like to hear comments from you. I currently tested just few packages and I'll give it more testing in next days. Patch is against 2.4c1. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:09 Message: Logged In: YES user_id=21627 Alternatively, adding --record-dirs to the install command would be acceptable as well, so you could post-process the directory list, e.g. with awk. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:07 Message: Logged In: YES user_id=21627 This might work. bdist_rpm would have to invoke the install command, but only to compute the file list, instead of actually performing copying. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-04 22:33 Message: Logged In: YES user_id=192186 It's pripary purpose is IMHO to allow building of rpms when you distribute some python stuff. It is good for this case. The problem for distributions, is that all packages need to be handled same way (in case they use some automatically building system), so you can not differ whether it is packaged some python stuff or kernel. So separate spec file and sources is the only solution. Generating spec file doesn't help much as it can get changed every version and vendor has own additional information in spec file, which would require hand merging. Another idea I just got is to generate just file list using separate bdist_rpm and use it separately, but I'm not sure whether it is doable - information about file list is not probably available there, is it? It would be used like: python setup.py install --root=$RPM_BUILD_ROOT python setup.py bdist_rpm --filelist=INSTALLED_FILES ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 22:19 Message: Logged In: YES user_id=21627 It is unfortunate that bdist_rpm is not useful to generate RPMs for distribution, because this is the primary purpose of that command: generating RPMs. So if the command does not meet your needs, we should change it to make it meet your needs. E.g. would it help if bdist_rpm would generate the .spec file for you? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-03 19:50 Message: Logged In: YES user_id=192186 As I said bdist_rpm is not suitable for building packages in distribution - all packages are built same way using spec file and sources (+patches). And this building packages for distribution (I work for SUSE) is main goal why I did this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:20 Message: Logged In: YES user_id=21627 I see. Wouldn't it better if the bdist_rpm command would generate a .spec file that completely contains all directives? Then, this could be enhanced to make use of more features of RPMs, such as %doc, %docdir, %verify, etc. It would also allow to keep RPM specifics out of the install command. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 23:04 Message: Logged In: YES user_id=192186 It does extend --record with directory entries. This resulting file is then used by rpm: %install python setup.py install --root=$RPM_BUILD_ROOT --record-rpm=INSTALLED_FILES %files -f INSTALLED_FILES %defattr(-,root,root) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:00 Message: Logged In: YES user_id=21627 Then I don't understand how your patch works: Does it not generate %dir lines for the .spec file? And isn't the spec file generated by the bdist_rpm command? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Wed Nov 24 01:08:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 24 01:08:20 2004 Subject: [Patches] [ python-Patches-728278 ] Multiple webbrowser.py bug fixes / improvements Message-ID: Patches item #728278, was opened at 2003-04-27 00:02 Message generated for change (Comment added) made by sdeibel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728278&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stephan R.A. Deibel (sdeibel) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Multiple webbrowser.py bug fixes / improvements Initial Comment: In using webbrowser.py we uncovered and fixed a number of problems and made some improvements in usability and consistency of behavior. Appended below is a summary of the changes made. This list is also found at the top of the uploaded file, which was based on the version of webbrowser.py found in Python 2.3a2. Sorry to submit so many changes at once but they were all made in a period of a few days when we went through this module for use in Wing IDE. I'm also submitting some unit tests for the module. I've tried to review everything carefully, further review is definately needed. Feel free to contact me if you have questions or comments or want me to make changes and resubmit. Hope this is helpful. - Stephan ---------------------------------------------------------------------- >Comment By: Stephan R.A. Deibel (sdeibel) Date: 2004-11-23 19:08 Message: Logged In: YES user_id=12608 I'm uploading a newer version of the webbrowser.py file, which contains a small fix to avoid failing when there is an empty ("") BROWSER environment variable set. The diff is just this: --- wingwebbrowser.py 20 Feb 2004 23:45:26 -0000 1.3 +++ wingwebbrowser.py 10 Nov 2004 16:51:36 -0000 1.4 @@ -210,6 +210,8 @@ def _splitcommand(cmd): """Extract command name and args from command line""" + if cmd == '': + return '', '' if cmd[0] in ('"', "'"): name = cmd[1:cmd[1:].find(cmd[0])+1] args = cmd[len(name)+2:].strip() @@ -603,7 +605,8 @@ # Treat choices in same way as if passed into get() but do register # and prepend to _tryorder for cmdline in _userchoices: - _synthesize(cmdline, -1, True) + if cmdline != '': + _synthesize(cmdline, -1, True) cmdline = None # to make del work if _userchoices was empty del cmdline del _userchoices ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-29 10:50 Message: Logged In: YES user_id=6656 Is now. ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2003-04-29 10:46 Message: Logged In: YES user_id=12608 Yes, I intended it to be post-2.3. The Group popup choices doesn't include 2.4, however. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-04-29 07:51 Message: Logged In: YES user_id=21627 Because this is quite a large change, I recommend to postpone it after 2.3. ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2003-04-27 00:32 Message: Logged In: YES user_id=12608 Jeez, here is the list of changes in this patch which I meant to append to the original report. Bugs fixed: * Don't apply lower() to command lines or commands that are going to be executed * Don't confuse browser name/id with command line used to launch the browser * Require that browser commands be executable * Identify user-provided strings as a command line by looking for any args and not just for %s * Handle spaces in user-provided command names, either if quoted on the user-provided command line or escaped with back slashes * Use '%s' instead of "%s", which avoids character interpretation on Unix command lines * Escape and quote urls more safely to prevent crafting urls that result in command lines that execute arbitrary commands * Fixed Galeon so it doesn't hang up the app until the browser is quit * Added the Mac OS X support that doesn't make bad environment assumptions on OS 10.1 * Fixed win32 use of Netscape, which before would never work because the _tryorder entry was being pruned out * Leave found items in _browsers and _tryorder on OS X (but prepend the OS X specific support in _tryorder). OS X is Unix so these are useful there. * Now add %s to end of command lines if they don't contain %s already, for compatibility e.g. with KDE's default value for BROWSER environment * Now add '&' to end of Unix command lines that are going to be launched from GenericBrowser to avoid hanging up on user-provided command lines * Added additional quoting of command names, so some of the browser classes can work with a renamed browser with a space in the executable name * Added a number of return values / checks where before there were bad assumptions in the code that might have led to errors Other internal changes made: * Added unit tests * Removed the loop in get() which always returned in the first iteration * _tryorder more tightly coupled with registering in _browsers, and removed potentially problematic last-ditch GenericBrowser registering clause and the prune-_tryorder clauses from the end of the module * _iscommand also returns true if cmd is an existing file name, and it returns the full path or None instead of just True and False * _synthesize registers and returns GenericBrowser if synthesis fails but the user-provided command line looks valid * Some additional uses of True and False instead of 1 and 0 Changes to the public interface: * Added optional update_tryorder arg to register() (default value is same as previous action of this function) * Open/open_new return False if command definately failed and True if it may have succeeded (both previously returned None in all cases) * Get() returns a GenericCommand if 'using' is given and doesn't name or synthesize a browser (previously it did this correctly only when %s was in the given command line) * Values passed via BROWSER environment will be registered and synthesized in the same way as 'using' arg values are treated in get() ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2003-04-27 00:14 Message: Logged In: YES user_id=12608 Oops, correcting the upload ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728278&group_id=5470 From noreply at sourceforge.net Wed Nov 24 12:27:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 24 12:27:52 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Comment added) made by remyblank You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Remy Blank (remyblank) Date: 2004-11-24 12:27 Message: Logged In: YES user_id=568100 Anything new about skipping tests? I'm still very interested. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-10-04 22:04 Message: Logged In: YES user_id=568100 I have just run the unit tests from Zope 2.7.2 (2358 tests) on Python 2.3.3, first with the original unittest.py, then with the patch. There was no difference in output, except for the total duration. That may give a hint about backward compatibility. ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2004-09-30 16:20 Message: Logged In: YES user_id=21477 Yes, that's right, and I would consider providing a number of such decorators at a later date. I've just spent a little time chatting to my colleage Joe Walnes (of nMock fame) about all this; he's more of an nUnit authority than I am. Categories are particularly interesting. In theory, it would be possible to get the same effect using TestSuites, but in practice tool support (including unittest.main()) discourages the use of TestSuites in favour of magic discovery of test cases; categories would be a better way of allowing tools to dynamically construct suites. @ignore could be considered equivalent to @category("ignored") in a certain sense. Skipping is not quite the same as ignoring, since it's determined at run-time, and so I think it is appropriate to add methods to explicitly support it. Interesting times indeed. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-30 15:46 Message: Logged In: YES user_id=568100 Speaking of decorators, the NUnit example is quite instructive, re. their use of attributes to mark classes as test cases, methods as test methods, grouping tests by category, and for that matter ignoring tests temporarily. I expect all of this can be done with decorators: @testMethod to mark individual tests, @category("LongRunning"), @ignore, @explicit, ... And if I'm not mistaken all of this can be added without breaking backward compatibility. Interesting times lay ahead! ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2004-09-30 13:31 Message: Logged In: YES user_id=21477 I've been really tied up; sorry for the delayed response, but I've been reading all the comments on this patch. Overall, I'm leaning in favour of accepting this patch, probably with some minor changes to the way skipped tests are reported. The concept of skipping is one that has been kept out of JUnit, but is found in NUnit and is well regarded there. In my XP coaching work ThoughtWorks I see an obscenely large number of JUnit tests, and a common mistake is to comment out test method bodies, leading to "false passes". Explicit support for skipping in unittest would mitigate this. I agree with Remy that the decorator example, though ingenious, has the wrong result; skipped tests will be reported as successes. In order for a test method to decide if it should be skipped, it will often need information from 'self' that was gathered during setUp() -- this makes decorators cumbersome for this. Also, a decorator solution would not allow test methods to skip if the setUp() method itself decides to skip(). Please give me a few more days on this, and I'll work on integrating and tweaking the patch. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-30 11:37 Message: Logged In: YES user_id=568100 I strongly disagree. Skipped tests should not just be transformed into passed tests, but must be recorded as skipped and reported to the user. Knowing that a test skipped is important information. The Python regression tests (although I'm not familiar with them) provide the same "skip" functionality, and I don't think people would be happy to replace it with just "pass". The decorator approach is an interesting idea, though, and could be combined with skipIf() so as to provide the other advantages you mention, namely single definition and appearance prior to definition. Something along the following: def rootOnly(f): """Decorator to skip tests that require root access""" def wrapper(self): self.skipIf(os.getuid() != 0, "Must be root") self.f() wrapper.__doc__ = f.__doc__ return wrapper class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" @rootOnly def testReadingAsRoot(self): """Reading /etc/shadow as root""" open("/etc/shadow").close() Note that I'm not yet familiar with decorators, so the wrapper() function might not be the correct way to do this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-30 10:04 Message: Logged In: YES user_id=80475 After more thought, I think decorators offer a cleaner, more complete solution without further complicating the unittest module. def rootonly(f): "Decorator to skip tests that require root access" if os.geteuid() == 0: return f return lambda self: 0 @rootonly def testReadingAsRoot(self): . . . Note the rootonly() decorator need only be defined once instead of writing a full self.skipIf(condition) inside every test. Also, it appears prior to the definition rather than inside. The approach is more flexible than the original proposal though it does lack a reporting mechanism. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-29 08:36 Message: Logged In: YES user_id=1038590 I'd certainly find such a feature handy - when testing different variations of an embedded firmware image, it would make it much easier to enable/disable different tests based on the capabilities of the firmware. Ditto for the original example of cross-platform testing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-26 12:13 Message: Logged In: YES user_id=80475 The skipIf() method is sufficient. From there, it is trivial to roll your own resource check. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-26 11:10 Message: Logged In: YES user_id=9205 This is a nice patch. I am wondering if it can be extended to support the resource idea used in the python regression tests. That is the user has a --resource option to give a list of available resources and a test only runs if its requested resources are available. Otherwise it will be skipped. Example: TestDemo.py --resource=network --resource=audio ... would supply the network and audio resource. Or does it make more sense to put this in a separate patch? ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 10:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Wed Nov 24 14:01:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 24 14:02:14 2004 Subject: [Patches] [ python-Patches-1043356 ] Enhancing '-m' to support packages Message-ID: Patches item #1043356, was opened at 2004-10-09 07:44 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043356&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Enhancing '-m' to support packages Initial Comment: Thomas Heller posted "python -m pychecker.checker