From noreply at sourceforge.net Sun Jan 1 07:17:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Dec 2005 22:17:41 -0800 Subject: [Patches] [ python-Patches-1391204 ] dict.merge Message-ID: Patches item #1391204, was opened at 2005-12-27 08:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1391204&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Core (C code) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) >Assigned to: Guido van Rossum (gvanrossum) Summary: dict.merge Initial Comment: If you want to update a dictionary with another one, you can simply use update : a = dict(a=1,c=3) b = dict(a=0,b=2) a.update(b) assert a == dict(a=0,b=2,c=3) However, sometimes you want to merge the second dict into the first, all while keeping the values that are already defined in the first. This is useful if you want to insert default values in the dictionary without overriding what is already defined. Currently this can be done in a few different ways, but all are awkward and/or inefficient : a = dict(a=1,c=3) b = dict(a=0,b=2) Method 1: for k in b: if k not in a: a[k] = b[k] Method 2: temp = dict(b) temp.update(a) a = temp This patch adds a merge() method to the dict object, with the same signature and usage as the update() method. Under the hood, it simply uses PyDict_Merge() with the override parameter set to 0 instead of 1. There's nothing new, therefore : the C API already provides this functionality (though it is not used in the dictobject.c scope), so why not expose it ? The result is : a = dict(a=1,c=3) b = dict(a=0,b=2) a.merge(b) assert a == dict(a=1,b=2,c=3) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-01 01:17 Message: Logged In: YES user_id=80475 The example is only slightly complicated by the implicit requirement to keep b unchanged; otherwise, it is easy enough to swap the dicts before updating: a,b=b,a; a.update(b). Anyway, I do not think the use case is sufficiently common or cumbersome to warrant making the mapping API more complex. Guido? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1391204&group_id=5470 From noreply at sourceforge.net Sun Jan 1 18:55:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jan 2006 09:55:53 -0800 Subject: [Patches] [ python-Patches-1391204 ] dict.merge Message-ID: Patches item #1391204, was opened at 2005-12-27 08:00 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1391204&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Guido van Rossum (gvanrossum) Summary: dict.merge Initial Comment: If you want to update a dictionary with another one, you can simply use update : a = dict(a=1,c=3) b = dict(a=0,b=2) a.update(b) assert a == dict(a=0,b=2,c=3) However, sometimes you want to merge the second dict into the first, all while keeping the values that are already defined in the first. This is useful if you want to insert default values in the dictionary without overriding what is already defined. Currently this can be done in a few different ways, but all are awkward and/or inefficient : a = dict(a=1,c=3) b = dict(a=0,b=2) Method 1: for k in b: if k not in a: a[k] = b[k] Method 2: temp = dict(b) temp.update(a) a = temp This patch adds a merge() method to the dict object, with the same signature and usage as the update() method. Under the hood, it simply uses PyDict_Merge() with the override parameter set to 0 instead of 1. There's nothing new, therefore : the C API already provides this functionality (though it is not used in the dictobject.c scope), so why not expose it ? The result is : a = dict(a=1,c=3) b = dict(a=0,b=2) a.merge(b) assert a == dict(a=1,b=2,c=3) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-01-01 12:55 Message: Logged In: YES user_id=6380 I don't think we need to provide every possible permutation of existing operations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-01 01:17 Message: Logged In: YES user_id=80475 The example is only slightly complicated by the implicit requirement to keep b unchanged; otherwise, it is easy enough to swap the dicts before updating: a,b=b,a; a.update(b). Anyway, I do not think the use case is sufficiently common or cumbersome to warrant making the mapping API more complex. Guido? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1391204&group_id=5470 From noreply at sourceforge.net Mon Jan 2 21:23:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 12:23:11 -0800 Subject: [Patches] [ python-Patches-1395552 ] add support for thread function result storage Message-ID: Patches item #1395552, was opened at 2006-01-02 21:23 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=1395552&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: tosi-in (tosi-in) Assigned to: Nobody/Anonymous (nobody) Summary: add support for thread function result storage Initial Comment: Here comes a little add-on for python's threading library: It provides a way of reading a thread function's result after the termination. after a thread, which was created using safe_result = True as a constructor parameter, the thread object will gain the function result as a parameter, called "result". If the thread function did not return till the result attribute access, an AttributeError is raised. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1395552&group_id=5470 From noreply at sourceforge.net Tue Jan 3 03:14:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 18:14:55 -0800 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 09:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Neal Norwitz (nnorwitz) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-02 18:14 Message: Logged In: YES user_id=33168 I updated the docs from the v2 patch. It doesn't seem to need backporting. I didn't love the duplication, but it's not a big deal, so I kept it. I modified the wording some to be a bit. Committed revision 41887. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-28 15:17 Message: Logged In: YES user_id=261020 jjlee> and was always documented as such To be precise, it was documented under .revert(). I attach an improved doc patch (loaderror_docs_v2.patch, obsoleting loaderror_docs.patch) that moves that into the .load() method docs, and makes the .revert() docs refer to that. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-28 15:04 Message: Logged In: YES user_id=261020 Thanks Neil (and thanks for applying my other cookielib patch). I've attached a doc patch. I don't like to repeat the wording (as the patch does), but it seems necessary here -- do you agree? The re-raise should not be changed, since CookieJar.load() may legitimately raise exactly IOError in addition to LoadError (and was always documented as such). For example, the IOError should be re-raised when the cookies file does not exist. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-23 13:32 Message: Logged In: YES user_id=33168 Should there be doc changes for LoadError subclassing IOError? Should the re-raise of IOError be changed to raise LoadError? Committed revision 41798. Committed revision 41799. (Misc/NEWS) Committed revision 41800. (2.4) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-05 14:54 Message: Logged In: YES user_id=261020 OK, another patch applied since March causes loaderror_v2.patch to add a class statement which is already present in the patched file. loaderror_v3.patch fixes that. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 15:09 Message: Logged In: YES user_id=261020 jjlee> It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) Sorry, FWLIW, it *does* apply cleanly, I just had the wrong -p argument to patch. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 12:20 Message: Logged In: YES user_id=261020 Patch loaderror_v2.patch implements MvL's suggestion (see followup 2005-03-04 14:52), and includes tests. It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) and the tests pass. Can it be committed, and preferably backported to the 2.4 maintenance branch? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-05 07:28 Message: Logged In: YES user_id=261020 This comment is not relevant to the patch, just a comment on my own comment: > Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Hmm, that's not true: four bugs might have been picked up if I'd released a final version of the <=2.4 backwards-compatible ClientCookie 0.9 version (with the interface changes from ClientCookie 0.4 to cookielib), then released a ClientCookie 1.0 after Python 2.4 came out (there was enough time without needing to wait for 2.5). That's what I should have done, instead of trying to protect ClientCookie users from two rounds of interface changes. Live and learn, I suppose. OTOH, no guilt on 1117339 or 1028908 (except regret that I was suddenly unable to work on it for a period up to the 2.4 beta release, hence missing deadline to get the latter applied before it was released). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 15:56 Message: Logged In: YES user_id=261020 Revised patch attached. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 10:39 Message: Logged In: YES user_id=261020 Re IOError: OK, I'll submit a revised patch. Yes, I agree on your first para, with hindsight. I attempted to avoid making users change interfaces twice (once for a release of a Python 2.4 candidate, once for 2.4 itself). Stupid idea, especially since the changes (though "minor") touched a lot of code. Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Thanks for your attention to these bugs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 06:52 Message: Logged In: YES user_id=21627 I see. In retrospect, it might have been best to reject the cookielib for Python 2.4, and wait for it to get a stable interface and implementation. Without the time machine, we have to accept the consequences, though, so we cannot break existing code. Therefore, I now propose that LoadError becomes a subclass a *permanent* subclass of IOError, thus preserving the historical interface. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 06:40 Message: Logged In: YES user_id=261020 >>> open('bad_cookies.txt', 'w').write("blah") >>> import cookielib >>> mcj = cookielib.MozillaCookieJar(filename="bad_cookies.txt") >>> mcj.load() Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\lib\cookielib.py", line 1727, in load self._really_load(f, filename, ignore_discard, ignore_expires) File "c:\Python24\lib\_MozillaCookieJar.py", line 53, in _really_load raise IOError( IOError: bad_cookies.txt does not look like a Netscape format cookies file >>> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 06:27 Message: Logged In: YES user_id=21627 Can you give an example of an invalid cookies file? How does the library respond to it right now? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 06:16 Message: Logged In: YES user_id=261020 LoadError is not currently not used anywhere. Without LoadError, how would one distinguish (for the purpose of error handling) an error due to, on the one hand, a missing file, insufficient permissions, etc. (IOError) from an error due, on the other hand, to an invalid cookies file (LoadError)? This is already a problem with IOError, of course, but I don't see why we should make it worse. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 03:03 Message: Logged In: YES user_id=21627 Is it true that LoadError is currently not used anywhere? If so, I think it would be best to eliminate this exception, both from the code and the documentation. To support code that might refer to LoadError already, you could make it a synonym to IOError. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-11 10:57 Message: Logged In: YES user_id=261020 I agree the backport (but not the trunk) should have LoadError derive from IOError. I'd be happy for comments to go in noting the change in all places where LoadError is raised, if that's considered good practice. Any committers reading: should I submit an updated patch with just those added comments? Should I submit a patch for the backport, with just that change plus the added (IOError) for backwards-compat.? (Jim: Besides the point for the matter at hand, but I should point out that the "pretty-for-printing" cookielib docs and the docstrings in cookielib.py form almost disjoint sets. Most of the documentation lives under Doc/lib, the stuff in the module source is the more obscure detail. And of course, you have just demonstrated to yourself how not reading the docs leaves you with an incomplete understanding of the intent, which can be useful! Not that I *ever* do that, of course ;-) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 08:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 14:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 08:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Tue Jan 3 03:37:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 18:37:38 -0800 Subject: [Patches] [ python-Patches-1395715 ] Nit: incorrect subsection LaTeX label in cookielib docs Message-ID: Patches item #1395715, was opened at 2006-01-03 02: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=1395715&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Nit: incorrect subsection LaTeX label in cookielib docs Initial Comment: Just a nit: The actual human-readable title is correct, and I don't believe there are any intended references to the LaTeX label in question, so the label could even be deleted if that's preferable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1395715&group_id=5470 From noreply at sourceforge.net Tue Jan 3 08:14:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 23:14:55 -0800 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 loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Rejected 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: Martin v. L??wis (loewis) Date: 2006-01-03 08:14 Message: Logged In: YES user_id=21627 Rejecting the patch due to lack of response from submitter. If you ever want to work on it again, please create a new patch in the tracker. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-03-07 22:12 Message: Logged In: YES user_id=21627 Please read the code carefully. The "this or that compiler" tests are primarily used in environments which *don't* use autoconf. For all other systems, configure does detect all the HAVE_ variables - see pyconfig.h.in. As "using MingW on Linux" should be an autoconf-based process, you should make sure that process works correctly. ---------------------------------------------------------------------- Comment By: Matthias Kramm (kramm) Date: 2005-03-07 11:29 Message: Logged In: YES user_id=1146139 That's a problem which isn't introduced by this patch. In posixmodule.c, a lot of code fragments already read like #if _THISORTHATCOMPILER_ #define HAVE_FUNCTION_FOO #define HAVE_FUNCTION_BAR #endif That is, autoconf only determines the used compiler, and posixmodule.c uses that to make assumptions about which functions are present. That's also exactly what breaks MingW compilation- as posixmodule.c doesn't know anything about MingW as compiler, it defaults on gcc, and hence derives the wrong set of available functions. This patches fixes that in making posixmodule.c "MingW-aware". I don't know why posixmodule.c was implemented in that way, instead of making autoconf determine all those HAVE_ flags- maybe that's a question which should go to python-dev at python.org. But for now, as that's what the current implementation does, this patch is consistent with that approach. Greetings Matthias ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-03-04 14:59 Message: Logged In: YES user_id=21627 I don't understand why the patch is necessary. Why doesn't autoconf determine that all these functions are present? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-01 11: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 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 Tue Jan 3 08:17:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 23:17:53 -0800 Subject: [Patches] [ python-Patches-1160169 ] skip winsound for Windows/IA64 build Message-ID: Patches item #1160169, was opened at 2005-03-09 21:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1160169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Trent Mick (tmick) Assigned to: Martin v. L??wis (loewis) Summary: skip winsound for Windows/IA64 build Initial Comment: Skip the winsound project for "ReleaseItanium" configuration builds on Windows. The current winsound.c cannot build for Window/IA64 because the used _outp() and _inp() port I/O routines in conio.h (at least the one that is part of the current MS Platform SDK) are hidden inside: #ifdef _M_IX86 ... #endif /* _M_IX86 */ See: C:\Program Files\Microsoft SDK\include\Win64\crt\conio.h ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-03 08:17 Message: Logged In: YES user_id=21627 I'm rejecting this patch. The right solution is to conditionalize the entire W9X block in winsound.c to _M_IX86. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1160169&group_id=5470 From noreply at sourceforge.net Tue Jan 3 08:40:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 23:40:02 -0800 Subject: [Patches] [ python-Patches-1307806 ] PCbuild vcproj project files need a cleanup Message-ID: Patches item #1307806, was opened at 2005-09-29 12:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1307806&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: PCbuild vcproj project files need a cleanup Initial Comment: The Visual Studio .NET vcproj files were probably generated by importing the older Visual C++ 6.0 dsp files and saving them back into the new format. The convertor is not perfect. The bigest problem it has it's the handling of the configuration macro defines. Instead of defining the used macros once for each configuration, it defines them for each individual file. This causes file bloat and could cause problems when new files are added to the project since we could get builds with mixed defines due to the $(NoInherit) flag which makes the compiler ignore global defines. For example, the current pythoncore.vcproj file has 100 KB. A cleaned up version is less than 25 KB. NOW: CLEANED-UP: There are a couple of files which require custom options: ..\Modules\getbuildinfo.c - PreprocessorDefinitions="BUILD=67" ..\PC\import_nt.c - AdditionalIncludeDirectories="..\Python" ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-03 08:40 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r41897. If you have further simplifications that you would like to see implemented, please submit another patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 05:47 Message: Logged In: YES user_id=33168 Thanks. I'm moving this to patches. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2005-10-03 23:32 Message: Logged In: YES user_id=1067739 Attached patch with cleaned up .vcproj files. VCCLCompilerTool: removed PrecompiledHeaderFile, AssemblerListingLocation, ObjectFile, ProgramDataBaseFileName entires. They are defined by default to the same values. VCMIDLTool: removed all entries. VCResourceCompilerTool: removed all entries for all but a couple of projects which actually have resource files. Removed FileConfiguration entries for all project files which don't need it. There's still stuff which could be cleaned up, I've only removed the biggest offenders. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 21:56 Message: Logged In: YES user_id=33168 Can you provide a patch (attach to this bug report if possible) for what the new file should look like? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1307806&group_id=5470 From noreply at sourceforge.net Tue Jan 3 16:58:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 07:58:09 -0800 Subject: [Patches] [ python-Patches-1396093 ] Further .vcproj cleanups Message-ID: Patches item #1396093, was opened at 2006-01-03 17: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=1396093&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Further .vcproj cleanups Initial Comment: The #1307806 patch failed to apply completely in r41897, probably because it was generated for Python 2.4.2 which didn't include the AST files. I've attached a patch which will complete the cleanup of pythoncore.vcproj and which also cleans up _elementtree.vcproj. Note that there is a bug in the current pythoncore.vcproj: The BUILD macro is defined as 60, it should be at least 67 as it was in Python 2.4.2. I didn't fix this since I don't know what's the correct BUILD number for Python 2.5 (68?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 From noreply at sourceforge.net Tue Jan 3 17:02:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 08:02:01 -0800 Subject: [Patches] [ python-Patches-1396093 ] Further .vcproj cleanups Message-ID: Patches item #1396093, was opened at 2006-01-03 16:58 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Further .vcproj cleanups Initial Comment: The #1307806 patch failed to apply completely in r41897, probably because it was generated for Python 2.4.2 which didn't include the AST files. I've attached a patch which will complete the cleanup of pythoncore.vcproj and which also cleans up _elementtree.vcproj. Note that there is a bug in the current pythoncore.vcproj: The BUILD macro is defined as 60, it should be at least 67 as it was in Python 2.4.2. I didn't fix this since I don't know what's the correct BUILD number for Python 2.5 (68?). ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-01-03 17:02 Message: Logged In: YES user_id=11105 The build number is usually set to the correct value shortly before a binary release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 From noreply at sourceforge.net Wed Jan 4 15:53:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 06:53:37 -0800 Subject: [Patches] [ python-Patches-1396919 ] FreeBSD is system scope threads capable Message-ID: Patches item #1396919, was opened at 2006-01-04 16:53 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=1396919&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Valts (valdiic) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD is system scope threads capable Initial Comment: I was a little bit disapointed when I mentioned that Python 2.4 uses libpthread library on FreeBSD 5 but avoids using system scope threads. I tried digging google to clarify why it is so and found out that it was because one of threading regression tests (test_threaded_import) failed on FreeBSD 5 (https:// sourceforge.net/tracker/? func=detail&atid=305470&aid=902444&group_id=5470). I compiled Python on my FreeBSD 5.4-RELEASE-p8 and ran all the regression tests (I executed regrtest.py) and saw no errors at all. I tried test_threaded_import and the test was successful. I don't see any reason why to avoid using system scope threads specially on FreeBSD. I know that using userland scope threads is quite faster because there is no need for kernel activities in context switching. But as far as I know most of servers (where speed is important) are SMP boxes. Userland scope threads don't use capabilities of multiple CPU's, so it should be reasonable to use system scope threads. To make it even better it could be good idea to make use of configuration parameter which determines which kind of threads has to be used. Since I'm not autoconf guru I made a patch which just removes checking against FreeBSD in thread_pthread.h Regards, Valts. mailto:valdiic at one.lv ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396919&group_id=5470 From noreply at sourceforge.net Wed Jan 4 22:05:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 13:05:30 -0800 Subject: [Patches] [ python-Patches-1395715 ] Nit: incorrect subsection LaTeX label in cookielib docs Message-ID: Patches item #1395715, was opened at 2006-01-03 03:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1395715&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Nit: incorrect subsection LaTeX label in cookielib docs Initial Comment: Just a nit: The actual human-readable title is correct, and I don't believe there are any intended references to the LaTeX label in question, so the label could even be deleted if that's preferable. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-04 22:05 Message: Logged In: YES user_id=1188172 Thanks, corrected in rev. 41913/41912. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1395715&group_id=5470 From noreply at sourceforge.net Thu Jan 5 13:28:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 04:28:06 -0800 Subject: [Patches] [ python-Patches-1397711 ] Fix dict and set docs, re: immutability Message-ID: Patches item #1397711, was opened at 2006-01-05 07: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=1397711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix dict and set docs, re: immutability Initial Comment: This patch resolves bug #1368768. As mentioned in the bug description, the documentation for sets and dicts incorrectly reports that set members and dict keys must be immutable. This patch corrects this, changing references to immutability to hashability and inserting footnotes describing what is meant by "hashable". The patch is a diff against Doc/lib/libstdtypes.tex from SVN revision 41926. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397711&group_id=5470 From noreply at sourceforge.net Thu Jan 5 16:59:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 07:59:13 -0800 Subject: [Patches] [ python-Patches-1397848 ] dictnotes.txt Message-ID: Patches item #1397848, was opened at 2006-01-05 10:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397848&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: dictnotes.txt Initial Comment: Please add the reasoning behind no-resize-on-shrinkage. This replacement version does so by adding two additional tunable parameters and one paragraph at the end of the tunable parameters section. It does document that the current CPython does not use (or even directly represent) these parameters, and explains why. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397848&group_id=5470 From noreply at sourceforge.net Thu Jan 5 17:55:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 08:55:58 -0800 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-10 06:05 Message generated for change (Comment added) made by xudong888 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 00:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-09 00:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 23:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 22:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 22:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 10:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 19:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-14 01:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-10 04:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-27 00:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-21 09:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Thu Jan 5 18:24:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 09:24:37 -0800 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-09 17:05 Message generated for change (Comment added) made by goertzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- >Comment By: Daniel Goertzen (goertzen) Date: 2006-01-05 11:24 Message: Logged In: YES user_id=843814 After configure you run "make". But did you use configure as the instructions say? You cannot just use "./configure". Good luck, Dan. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-05 10:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 10:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 09:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 08:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 08:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-07 20:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 06:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-13 12:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-09 15:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-26 11:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-20 20:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Thu Jan 5 19:18:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 10:18:51 -0800 Subject: [Patches] [ python-Patches-1397960 ] File-iteration and read* method protection Message-ID: Patches item #1397960, was opened at 2006-01-05 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=1397960&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: File-iteration and read* method protection Initial Comment: This patch causes the readline, readlines, read and readinto methods of file objects (as well as PyFile_ReadLine() called on actual fileobjects) to raise an exception if (and only if) there is data in the file-iteration buffer. Currently, if any of these methods are called during file-iteration (with a non-empty buffer), the read* methods return data following the buffer, causing the data to seem out of order. Or, if all of the file's remaining data is in the buffer, truncated. The patch is only supposed to raise an error when, previously, the file's data would get corrupted. It doesn't prevent mixing iteration and read*-methods in harmless situations (methods followed by iteration, iteration until EOF followed by methods, or iteration until an exact buffer boundary, followed by methods.) The exception currently raised is ValueError, because it seems least inappropriate. Also, read* on closed files raises ValueError (probably for the same reason.) The test_file test has been ammended to include tests for this behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397960&group_id=5470 From noreply at sourceforge.net Thu Jan 5 21:09:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 12:09:15 -0800 Subject: [Patches] [ python-Patches-1397848 ] dictnotes.txt Message-ID: Patches item #1397848, was opened at 2006-01-05 10:59 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397848&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Raymond Hettinger (rhettinger) Summary: dictnotes.txt Initial Comment: Please add the reasoning behind no-resize-on-shrinkage. This replacement version does so by adding two additional tunable parameters and one paragraph at the end of the tunable parameters section. It does document that the current CPython does not use (or even directly represent) these parameters, and explains why. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397848&group_id=5470 From jturek at biometrics2000.com Thu Jan 5 17:52:20 2006 From: jturek at biometrics2000.com (Joseph Turek) Date: Thu, 05 Jan 2006 11:52:20 -0500 Subject: [Patches] Best Price On Viagra - NO PRESCRIPTION NEEDED Message-ID: <7.0.0.16.2.20060105115144.023c7028@biometrics2000.com> Hi: I need ZOVIRAX Can you supply this in a cream Joe Joseph J. Turek Biometrics 2000 Corporation 120 Carando Drive Springfield, MA 01104 v:413-736-9700 f:413-736-9718 cell:413-530-2921 e-mail jturek at biometrics2000.com visit us at: www.biometrics2000.com The information in this e-mail message is intended for the confidential use of the addressees only. Recipients should not file copies of this e-mail with publicly accessible records. If you are not an addressee or an authorized agent responsible for delivering this e-mail to a designated addressee, you have received this e-mail in error, and any further review, dissemination distribution, copying or forwarding of this e-mail is strictly prohibited. If you received this e-mail in error, please notify us immediately at the number shown above or by reply to this e-mail. Thank you. >Joseph J. Turek >Biometrics 2000 Corporation >120 Carando Drive >Springfield, MA 01104 >v:413-736-9700 >f:413-736-9718 >e-mail jturek at biometrics2000.com >visit us at: www.biometrics2000.com > >The information in this e-mail message is intended for the >confidential use of the addressees only. Recipients should not file >copies of this e-mail with publicly accessible records. If you are >not an addressee or an authorized agent responsible for delivering >this e-mail to a designated addressee, you have received this e-mail >in error, and any further review, dissemination distribution, >copying or forwarding of this e-mail is strictly prohibited. If you >received this e-mail in error, please notify us immediately at the >number shown above or by reply to this e-mail. Thank you. From noreply at sourceforge.net Thu Jan 5 21:55:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 12:55:18 -0800 Subject: [Patches] [ python-Patches-1397711 ] Fix dict and set docs, re: immutability Message-ID: Patches item #1397711, was opened at 2006-01-05 07:28 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dict and set docs, re: immutability Initial Comment: This patch resolves bug #1368768. As mentioned in the bug description, the documentation for sets and dicts incorrectly reports that set members and dict keys must be immutable. This patch corrects this, changing references to immutability to hashability and inserting footnotes describing what is meant by "hashable". The patch is a diff against Doc/lib/libstdtypes.tex from SVN revision 41926. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397711&group_id=5470 From noreply at sourceforge.net Thu Jan 5 22:20:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 13:20:18 -0800 Subject: [Patches] [ python-Patches-1339673 ] cross compile and mingw support Message-ID: Patches item #1339673, was opened at 2005-10-27 16:18 Message generated for change (Comment added) made by rmt38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Nieuwenhuizen (janneke-sf) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile and mingw support Initial Comment: The cross compile patch is similar to what I did for Guile and has still some bits from Daniel Goertzen's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 The mingw patch is based on Matthias Kramm's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 but adds autoconf tests and does have his C modifications. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ---------------------------------------------------------------------- Comment By: Richard Tew (rmt38) Date: 2006-01-05 21:20 Message: Logged In: YES user_id=1417949 Hi, I patched Python 2.4.2 source code download with this (can't get CVS as bandwidth is limited). context-cross.patch fails on one chunk of Makefile.pre.in, although hand application fixed it. Otherwise, context- mingw-2.patch applied cleanly. With both applied, I did the following: export BASECFLAGS="-mcpu=arm9tdmi -mcpu=arm9tdmi -ffast- math -mthumb -mthumb-interwork -DARM9 -D__NDS__" export CFLAGS="-mcpu=arm9tdmi -mcpu=arm9tdmi -ffast-math - mthumb -mthumb-interwork -DARM9 -D__NDS__" export LDFLAGS="-specs=ds_arm9.specs -g -mthumb -mthumb- interwork -Wl,-Map,libpython2.4.map" sh configure --host=arm-elf This is what eventually happened: PATH=/usr/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/s ystem32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/ATI Technologies/ATI Control Panel:/c/PROGRA~1/COMMON~1/SONICS~1/:/c/Program Files/Common Files/Adobe/AGL:/usr/bin:/c/devkitpro/devkitarm/bin:. cc - c -I -I./Include -o Parser/acceler.x Parser/acceler.c /bin/sh: Files/ATI: No such file or directory make: *** [Parser/acceler.x] Error 127 Looks like the patch needs to handle paths with spaces in, in the PATH. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2005-11-04 13:59 Message: Logged In: YES user_id=1368960 The second mingw patch actually produces a working python, fixing * loadable dll modules * argv0 relocation * posixflavour nt -- Jan. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2005-10-27 16:20 Message: Logged In: YES user_id=1368960 .... and does NOT have his C modifications ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 From noreply at sourceforge.net Fri Jan 6 01:31:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 16:31:16 -0800 Subject: [Patches] [ python-Patches-1339673 ] cross compile and mingw support Message-ID: Patches item #1339673, was opened at 2005-10-27 18:18 Message generated for change (Comment added) made by janneke-sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Nieuwenhuizen (janneke-sf) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile and mingw support Initial Comment: The cross compile patch is similar to what I did for Guile and has still some bits from Daniel Goertzen's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 The mingw patch is based on Matthias Kramm's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 but adds autoconf tests and does have his C modifications. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ---------------------------------------------------------------------- >Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2006-01-06 01:31 Message: Logged In: YES user_id=1368960 > Looks like the patch needs to handle paths with spaces in, > in the PATH. Why do you think that? You will find that no autotooled package will build or install in directories with spaces. If this would be possible at all, it would be a separate feature. I do not see a dependency with cross compilation or mingw building. ---------------------------------------------------------------------- Comment By: Richard Tew (rmt38) Date: 2006-01-05 22:20 Message: Logged In: YES user_id=1417949 Hi, I patched Python 2.4.2 source code download with this (can't get CVS as bandwidth is limited). context-cross.patch fails on one chunk of Makefile.pre.in, although hand application fixed it. Otherwise, context- mingw-2.patch applied cleanly. With both applied, I did the following: export BASECFLAGS="-mcpu=arm9tdmi -mcpu=arm9tdmi -ffast- math -mthumb -mthumb-interwork -DARM9 -D__NDS__" export CFLAGS="-mcpu=arm9tdmi -mcpu=arm9tdmi -ffast-math - mthumb -mthumb-interwork -DARM9 -D__NDS__" export LDFLAGS="-specs=ds_arm9.specs -g -mthumb -mthumb- interwork -Wl,-Map,libpython2.4.map" sh configure --host=arm-elf This is what eventually happened: PATH=/usr/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/s ystem32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/ATI Technologies/ATI Control Panel:/c/PROGRA~1/COMMON~1/SONICS~1/:/c/Program Files/Common Files/Adobe/AGL:/usr/bin:/c/devkitpro/devkitarm/bin:. cc - c -I -I./Include -o Parser/acceler.x Parser/acceler.c /bin/sh: Files/ATI: No such file or directory make: *** [Parser/acceler.x] Error 127 Looks like the patch needs to handle paths with spaces in, in the PATH. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2005-11-04 14:59 Message: Logged In: YES user_id=1368960 The second mingw patch actually produces a working python, fixing * loadable dll modules * argv0 relocation * posixflavour nt -- Jan. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2005-10-27 18:20 Message: Logged In: YES user_id=1368960 .... and does NOT have his C modifications ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 From noreply at sourceforge.net Fri Jan 6 06:46:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 21:46:16 -0800 Subject: [Patches] [ python-Patches-1339673 ] cross compile and mingw support Message-ID: Patches item #1339673, was opened at 2005-10-27 16:18 Message generated for change (Comment added) made by rmt38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Nieuwenhuizen (janneke-sf) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile and mingw support Initial Comment: The cross compile patch is similar to what I did for Guile and has still some bits from Daniel Goertzen's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 The mingw patch is based on Matthias Kramm's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 but adds autoconf tests and does have his C modifications. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ---------------------------------------------------------------------- Comment By: Richard Tew (rmt38) Date: 2006-01-06 05:46 Message: Logged In: YES user_id=1417949 > Why do you think that? You will find that no autotooled > package will build or install in directories with spaces Perhaps I was not clear enough. The problem is not that I am building in those directories, it is that the patch sets the PATH environment variable as a prefix to the compilation command (in the same line). And on Windows, it is not uncommon for directories in Program Files and other directories with spaces in their names to be in the path. This breaks the correctness of the command line and the execution of it. Take another look at the erroneous command: PATH=/usr/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/s ystem32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/ATI Technologies/ATI Control Panel:/c/PROGRA~1/COMMON~1/SONICS~1/:/c/Program Files/Common Files/Adobe/AGL:/usr/bin:/c/devkitpro/devkitarm/bin:. cc - c -I -I./Include -o Parser/acceler.x Parser/acceler.c And the error: /bin/sh: Files/ATI: No such file or directory make: *** [Parser/acceler.x] Error 127 Hope this helps. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2006-01-06 00:31 Message: Logged In: YES user_id=1368960 > Looks like the patch needs to handle paths with spaces in, > in the PATH. Why do you think that? You will find that no autotooled package will build or install in directories with spaces. If this would be possible at all, it would be a separate feature. I do not see a dependency with cross compilation or mingw building. ---------------------------------------------------------------------- Comment By: Richard Tew (rmt38) Date: 2006-01-05 21:20 Message: Logged In: YES user_id=1417949 Hi, I patched Python 2.4.2 source code download with this (can't get CVS as bandwidth is limited). context-cross.patch fails on one chunk of Makefile.pre.in, although hand application fixed it. Otherwise, context- mingw-2.patch applied cleanly. With both applied, I did the following: export BASECFLAGS="-mcpu=arm9tdmi -mcpu=arm9tdmi -ffast- math -mthumb -mthumb-interwork -DARM9 -D__NDS__" export CFLAGS="-mcpu=arm9tdmi -mcpu=arm9tdmi -ffast-math - mthumb -mthumb-interwork -DARM9 -D__NDS__" export LDFLAGS="-specs=ds_arm9.specs -g -mthumb -mthumb- interwork -Wl,-Map,libpython2.4.map" sh configure --host=arm-elf This is what eventually happened: PATH=/usr/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/s ystem32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/ATI Technologies/ATI Control Panel:/c/PROGRA~1/COMMON~1/SONICS~1/:/c/Program Files/Common Files/Adobe/AGL:/usr/bin:/c/devkitpro/devkitarm/bin:. cc - c -I -I./Include -o Parser/acceler.x Parser/acceler.c /bin/sh: Files/ATI: No such file or directory make: *** [Parser/acceler.x] Error 127 Looks like the patch needs to handle paths with spaces in, in the PATH. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2005-11-04 13:59 Message: Logged In: YES user_id=1368960 The second mingw patch actually produces a working python, fixing * loadable dll modules * argv0 relocation * posixflavour nt -- Jan. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2005-10-27 16:20 Message: Logged In: YES user_id=1368960 .... and does NOT have his C modifications ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 From noreply at sourceforge.net Fri Jan 6 11:57:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jan 2006 02:57:57 -0800 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-10 06:05 Message generated for change (Comment added) made by xudong888 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 18:57 Message: Logged In: YES user_id=1420135 Thank you for your rapid answer.But I still can't solve my question.I can't find the whole instructions. Can you give me the whole instructions by EMAIL,my email is xudong888 at 163.com,thanks. My "host" system is mips embbed_linux,the release of the linux kernel is 2.4.xx and the CPU type is MIPS 4Kc.There are no python installed on this system.My "build" system is i86 and operate system is RedHat9.0,and has installed python2.4.1 and cross-compiling Tools mipsel-linux-gcc.I can cross compile C program for the "host" system.I have writed some program with python language.I can get the binary from python script by use freeze.py on the "build" system. Now I want to run the binary on the "host" system.Can you tell me how should I do. in addition,I don't know what parameter I should input to use this patch. finally,I'm sorry for my poor English.I like python very much,but I can't get help in chinese. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-01-06 01:24 Message: Logged In: YES user_id=843814 After configure you run "make". But did you use configure as the instructions say? You cannot just use "./configure". Good luck, Dan. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 00:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-09 00:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 23:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 22:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 22:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 10:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 19:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-14 01:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-10 04:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-27 00:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-21 09:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Fri Jan 6 12:08:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jan 2006 03:08:55 -0800 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-10 06:05 Message generated for change (Comment added) made by xudong888 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 19:08 Message: Logged In: YES user_id=1420135 If you have accounts of MSN,please add me.My accounts is xudong_888 at hotmail.com. I am very impatient.I hope I can get some help from you.Thanks. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 18:57 Message: Logged In: YES user_id=1420135 Thank you for your rapid answer.But I still can't solve my question.I can't find the whole instructions. Can you give me the whole instructions by EMAIL,my email is xudong888 at 163.com,thanks. My "host" system is mips embbed_linux,the release of the linux kernel is 2.4.xx and the CPU type is MIPS 4Kc.There are no python installed on this system.My "build" system is i86 and operate system is RedHat9.0,and has installed python2.4.1 and cross-compiling Tools mipsel-linux-gcc.I can cross compile C program for the "host" system.I have writed some program with python language.I can get the binary from python script by use freeze.py on the "build" system. Now I want to run the binary on the "host" system.Can you tell me how should I do. in addition,I don't know what parameter I should input to use this patch. finally,I'm sorry for my poor English.I like python very much,but I can't get help in chinese. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-01-06 01:24 Message: Logged In: YES user_id=843814 After configure you run "make". But did you use configure as the instructions say? You cannot just use "./configure". Good luck, Dan. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 00:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-09 00:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 23:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 22:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 22:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 10:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 19:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-14 01:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-10 04:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-27 00:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-21 09:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Sat Jan 7 19:11:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jan 2006 10:11:12 -0800 Subject: [Patches] [ python-Patches-1399309 ] ConfigParser to save with order Message-ID: Patches item #1399309, was opened at 2006-01-07 15: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=1399309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser to save with order Initial Comment: ConfigParser saves the data in a not-predefined order. This is because it keeps, internally, the information in dictionaries. This patch orders the info to be saved in the file through the ConfigParser write() method. This patch does not let the user to specify the order. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1399309&group_id=5470 From noreply at sourceforge.net Sun Jan 8 11:09:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 02:09:46 -0800 Subject: [Patches] [ python-Patches-881820 ] look in libbsd.a also for openpty and forkpty Message-ID: Patches item #881820, was opened at 2004-01-22 00:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=881820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David Dyck (dcd) Assigned to: Martin v. L??wis (loewis) Summary: look in libbsd.a also for openpty and forkpty Initial Comment: fix bug [ 880996 ] 2.3.3 make fails build posix_openpty' where libbsd.a contains openpty (and forkpty) instead of libutil.a. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-08 11:09 Message: Logged In: YES user_id=21627 Thanks for the patch. These things should be cascaded, so it should look in libbsd only if it was not found in libutil. I adjusted the patch, and applied it as r41975 and r41976. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 09:16 Message: Logged In: YES user_id=33168 Martin, do you have any problem with this patch? I'm inclined to accept it unless there's a reason not to. If you think it's ok, is it also ok to backport to 2.4? It looks very simple, but I'm still a bit more hesitant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=881820&group_id=5470 From noreply at sourceforge.net Sun Jan 8 11:46:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 02:46:06 -0800 Subject: [Patches] [ python-Patches-1177307 ] UTF-8-Sig codec Message-ID: Patches item #1177307, was opened at 2005-04-05 21:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177307&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Martin v. L??wis (loewis) Summary: UTF-8-Sig codec Initial Comment: This patch implements a UTF-8-Sig codec. This codec works like UTF-8 but adds a BOM on writing and skips (at most) one BOM on reading. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-08 11:46 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as 41977. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-26 17:51 Message: Logged In: YES user_id=89016 OK, here's a text that explains what the BOM is used for in various Unicode encodings. I hope that this can be turned into something useful. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-09 20:53 Message: Logged In: YES user_id=21627 The place is right, but I feel this documentation is incomplete still. The library reference should explain somewhere what the difference between utf-8 and utf-8-sig is. Perhaps a footnote could be added. I think I would prefer a separate subsection on the BOM, explaining byte order in UTF-{16,32}, and how the BOM can be used as a magic signature for UTF-8. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-09 15:41 Message: Logged In: YES user_id=89016 This version (diff3.txt) of the patch adds a note to Misc/NEWS and a section to Doc/lib/libcodecs.tex. Is this the correct place to add the documentation? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-07 23:51 Message: Logged In: YES user_id=21627 The patch looks fine, but lacks documentation changes. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-05 22:28 Message: Logged In: YES user_id=89016 This second version of the patch will return starting bytes immediately, if they don't look like a BOM. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177307&group_id=5470 From noreply at sourceforge.net Sun Jan 8 11:49:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 02:49:20 -0800 Subject: [Patches] [ python-Patches-1299675 ] fix for distutils "upload" command Message-ID: Patches item #1299675, was opened at 2005-09-23 05:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1299675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Martin v. L??wis (loewis) Summary: fix for distutils "upload" command Initial Comment: This patch fixes distutils/command/upload.py so it can talk to an improved PyPI interface. Specifically, it allows upload of a file for an un"register"ed release. Should be applied against CVS HEAD. Thanks! ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-08 11:49 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r41978. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1299675&group_id=5470 From noreply at sourceforge.net Sun Jan 8 22:45:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 13:45:16 -0800 Subject: [Patches] [ python-Patches-1399935 ] enhance unittest to define tests that *should* fail Message-ID: Patches item #1399935, was opened at 2006-01-08 13: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=1399935&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: enhance unittest to define tests that *should* fail Initial Comment: As discussed here: http://mail.python.org/pipermail/python-dev/2006-January/059503.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1399935&group_id=5470 From noreply at sourceforge.net Mon Jan 9 10:02:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 01:02:40 -0800 Subject: [Patches] [ python-Patches-1400181 ] unicode formats floats according to locale Message-ID: Patches item #1400181, was opened at 2006-01-09 01: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=1400181&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: unicode formats floats according to locale Initial Comment: import locale locale.setlocale(locale.LC_NUMERIC, 'de_DE') u'%.1f' % 1.0 assert '1.0' == u'%.1f' % 1.0 Fails with HEAD and 2.4 because the locale is used and 1,0 is generated rather than 1.0. I tried to come up with a test case, but it always passes when run with the test suite. I could only reproduce in the interpreter. Both the fix and test are attached. The test has some debugging to try and figure out the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 From noreply at sourceforge.net Mon Jan 9 12:43:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 03:43:03 -0800 Subject: [Patches] [ python-Patches-1400181 ] unicode formats floats according to locale Message-ID: Patches item #1400181, was opened at 2006-01-09 10:02 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: unicode formats floats according to locale Initial Comment: import locale locale.setlocale(locale.LC_NUMERIC, 'de_DE') u'%.1f' % 1.0 assert '1.0' == u'%.1f' % 1.0 Fails with HEAD and 2.4 because the locale is used and 1,0 is generated rather than 1.0. I tried to come up with a test case, but it always passes when run with the test suite. I could only reproduce in the interpreter. Both the fix and test are attached. The test has some debugging to try and figure out the problem. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-09 12:43 Message: Logged In: YES user_id=38388 The patch looks good. What's strange is that if you run the snippet in Python 2.3 you don't get the assertion error (at least I don't). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 From noreply at sourceforge.net Mon Jan 9 14:08:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 05:08:55 -0800 Subject: [Patches] [ python-Patches-1400181 ] unicode formats floats according to locale Message-ID: Patches item #1400181, was opened at 2006-01-09 09:02 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: unicode formats floats according to locale Initial Comment: import locale locale.setlocale(locale.LC_NUMERIC, 'de_DE') u'%.1f' % 1.0 assert '1.0' == u'%.1f' % 1.0 Fails with HEAD and 2.4 because the locale is used and 1,0 is generated rather than 1.0. I tried to come up with a test case, but it always passes when run with the test suite. I could only reproduce in the interpreter. Both the fix and test are attached. The test has some debugging to try and figure out the problem. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-01-09 13:08 Message: Logged In: YES user_id=908 I can confirm the patch compiles and fixes the problem. I also can't reproduce the problem except from the python shell. Weird. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-09 11:43 Message: Logged In: YES user_id=38388 The patch looks good. What's strange is that if you run the snippet in Python 2.3 you don't get the assertion error (at least I don't). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 From noreply at sourceforge.net Mon Jan 9 19:50:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 10:50:25 -0800 Subject: [Patches] [ python-Patches-1397960 ] File-iteration and read* method protection Message-ID: Patches item #1397960, was opened at 2006-01-05 13:18 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397960&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: File-iteration and read* method protection Initial Comment: This patch causes the readline, readlines, read and readinto methods of file objects (as well as PyFile_ReadLine() called on actual fileobjects) to raise an exception if (and only if) there is data in the file-iteration buffer. Currently, if any of these methods are called during file-iteration (with a non-empty buffer), the read* methods return data following the buffer, causing the data to seem out of order. Or, if all of the file's remaining data is in the buffer, truncated. The patch is only supposed to raise an error when, previously, the file's data would get corrupted. It doesn't prevent mixing iteration and read*-methods in harmless situations (methods followed by iteration, iteration until EOF followed by methods, or iteration until an exact buffer boundary, followed by methods.) The exception currently raised is ValueError, because it seems least inappropriate. Also, read* on closed files raises ValueError (probably for the same reason.) The test_file test has been ammended to include tests for this behaviour. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-09 13:50 Message: Logged In: YES user_id=764593 Since you're already adding the if-test (to be able to raise an error), why not just read the data from the buffer if there is one, instead of raising an error? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397960&group_id=5470 From noreply at sourceforge.net Mon Jan 9 20:17:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 11:17:25 -0800 Subject: [Patches] [ python-Patches-1400181 ] unicode formats floats according to locale Message-ID: Patches item #1400181, was opened at 2006-01-09 10:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: unicode formats floats according to locale Initial Comment: import locale locale.setlocale(locale.LC_NUMERIC, 'de_DE') u'%.1f' % 1.0 assert '1.0' == u'%.1f' % 1.0 Fails with HEAD and 2.4 because the locale is used and 1,0 is generated rather than 1.0. I tried to come up with a test case, but it always passes when run with the test suite. I could only reproduce in the interpreter. Both the fix and test are attached. The test has some debugging to try and figure out the problem. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-09 20:17 Message: Logged In: YES user_id=1188172 Confirmed here too. Your test fails with unpatched HEAD when run from regrtest (I have de_DE locale in the environment). ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-01-09 14:08 Message: Logged In: YES user_id=908 I can confirm the patch compiles and fixes the problem. I also can't reproduce the problem except from the python shell. Weird. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-09 12:43 Message: Logged In: YES user_id=38388 The patch looks good. What's strange is that if you run the snippet in Python 2.3 you don't get the assertion error (at least I don't). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 From noreply at sourceforge.net Mon Jan 9 20:33:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 11:33:09 -0800 Subject: [Patches] [ python-Patches-1400181 ] unicode formats floats according to locale Message-ID: Patches item #1400181, was opened at 2006-01-09 09:02 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: unicode formats floats according to locale Initial Comment: import locale locale.setlocale(locale.LC_NUMERIC, 'de_DE') u'%.1f' % 1.0 assert '1.0' == u'%.1f' % 1.0 Fails with HEAD and 2.4 because the locale is used and 1,0 is generated rather than 1.0. I tried to come up with a test case, but it always passes when run with the test suite. I could only reproduce in the interpreter. Both the fix and test are attached. The test has some debugging to try and figure out the problem. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-01-09 19:33 Message: Logged In: YES user_id=6656 One thing that can interfere with the shell but not in a test script is readline... ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-09 19:17 Message: Logged In: YES user_id=1188172 Confirmed here too. Your test fails with unpatched HEAD when run from regrtest (I have de_DE locale in the environment). ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-01-09 13:08 Message: Logged In: YES user_id=908 I can confirm the patch compiles and fixes the problem. I also can't reproduce the problem except from the python shell. Weird. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-09 11:43 Message: Logged In: YES user_id=38388 The patch looks good. What's strange is that if you run the snippet in Python 2.3 you don't get the assertion error (at least I don't). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 From noreply at sourceforge.net Tue Jan 10 07:06:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 22:06:49 -0800 Subject: [Patches] [ python-Patches-1400181 ] unicode formats floats according to locale Message-ID: Patches item #1400181, was opened at 2006-01-09 01:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) >Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: unicode formats floats according to locale Initial Comment: import locale locale.setlocale(locale.LC_NUMERIC, 'de_DE') u'%.1f' % 1.0 assert '1.0' == u'%.1f' % 1.0 Fails with HEAD and 2.4 because the locale is used and 1,0 is generated rather than 1.0. I tried to come up with a test case, but it always passes when run with the test suite. I could only reproduce in the interpreter. Both the fix and test are attached. The test has some debugging to try and figure out the problem. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-09 22:06 Message: Logged In: YES user_id=33168 Committed revision 41996. Committed revision 41997. (2.4) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-01-09 11:33 Message: Logged In: YES user_id=6656 One thing that can interfere with the shell but not in a test script is readline... ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-09 11:17 Message: Logged In: YES user_id=1188172 Confirmed here too. Your test fails with unpatched HEAD when run from regrtest (I have de_DE locale in the environment). ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-01-09 05:08 Message: Logged In: YES user_id=908 I can confirm the patch compiles and fixes the problem. I also can't reproduce the problem except from the python shell. Weird. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-09 03:43 Message: Logged In: YES user_id=38388 The patch looks good. What's strange is that if you run the snippet in Python 2.3 you don't get the assertion error (at least I don't). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 From noreply at sourceforge.net Tue Jan 10 07:08:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 22:08:06 -0800 Subject: [Patches] [ python-Patches-1400181 ] unicode formats floats according to locale Message-ID: Patches item #1400181, was opened at 2006-01-09 01:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: unicode formats floats according to locale Initial Comment: import locale locale.setlocale(locale.LC_NUMERIC, 'de_DE') u'%.1f' % 1.0 assert '1.0' == u'%.1f' % 1.0 Fails with HEAD and 2.4 because the locale is used and 1,0 is generated rather than 1.0. I tried to come up with a test case, but it always passes when run with the test suite. I could only reproduce in the interpreter. Both the fix and test are attached. The test has some debugging to try and figure out the problem. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-09 22:08 Message: Logged In: YES user_id=33168 mwh, good point. I need to keep that in mind. mal, that's an interesting note about 2.3. Same for me, it works. I guess unicode formatting changed between 2.3 and 2.4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-09 22:06 Message: Logged In: YES user_id=33168 Committed revision 41996. Committed revision 41997. (2.4) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-01-09 11:33 Message: Logged In: YES user_id=6656 One thing that can interfere with the shell but not in a test script is readline... ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-09 11:17 Message: Logged In: YES user_id=1188172 Confirmed here too. Your test fails with unpatched HEAD when run from regrtest (I have de_DE locale in the environment). ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-01-09 05:08 Message: Logged In: YES user_id=908 I can confirm the patch compiles and fixes the problem. I also can't reproduce the problem except from the python shell. Weird. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-09 03:43 Message: Logged In: YES user_id=38388 The patch looks good. What's strange is that if you run the snippet in Python 2.3 you don't get the assertion error (at least I don't). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1400181&group_id=5470 From noreply at sourceforge.net Tue Jan 10 08:14:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 23:14:04 -0800 Subject: [Patches] [ python-Patches-1173998 ] Python crashes in pyexpat.c if malformed XML is parsed Message-ID: Patches item #1173998, was opened at 2005-03-31 02:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173998&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: pdecat (pdecat) >Assigned to: Neal Norwitz (nnorwitz) Summary: Python crashes in pyexpat.c if malformed XML is parsed Initial Comment: If a malformed XML file (containing non unicode characters) is parsed with pyexpat, python crashes. Most details on request. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-09 23:14 Message: Logged In: YES user_id=33168 A similar patch was commited to pyexpat.c in 39631 from Patch #1309009. Thanks. ---------------------------------------------------------------------- Comment By: pdecat (pdecat) Date: 2005-08-23 03:29 Message: Logged In: YES user_id=1210681 Sorry, I don't have the malformed XML file anymore. I've tried and failed to reproduce the problem by hand. The ParsedXML product lets expat determine the encoding itself : def createParser(self): """Create a new parser object.""" return expat.ParserCreate() If you have a look at my patch, it's a real simple one-liner (ok two ;) that checks the return value of the STRING_CONV_FUNC is not NULL before using it. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-08-22 20:59 Message: Logged In: YES user_id=3066 I realize this has sat too long; sorry. Can you send an example XML file for which this crashes for you? Do you let Expat determine and handle the encoding itself, or do you override the detected encoding when you create the parser? ---------------------------------------------------------------------- Comment By: pdecat (pdecat) Date: 2005-03-31 05:00 Message: Logged In: YES user_id=1210681 STRING_CONV_FUNC returns NULL if the string is contains non-ascii and non-unicode characters. ---------------------------------------------------------------------- Comment By: pdecat (pdecat) Date: 2005-03-31 04:18 Message: Logged In: YES user_id=1210681 Maybe security related, as it can lead to denial of service: it crashes a Zope server using the ParsedXML product simply by uploading a malformed XML file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173998&group_id=5470 From noreply at sourceforge.net Tue Jan 10 11:46:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 02:46:13 -0800 Subject: [Patches] [ python-Patches-1397960 ] File-iteration and read* method protection Message-ID: Patches item #1397960, was opened at 2006-01-05 19:18 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397960&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: File-iteration and read* method protection Initial Comment: This patch causes the readline, readlines, read and readinto methods of file objects (as well as PyFile_ReadLine() called on actual fileobjects) to raise an exception if (and only if) there is data in the file-iteration buffer. Currently, if any of these methods are called during file-iteration (with a non-empty buffer), the read* methods return data following the buffer, causing the data to seem out of order. Or, if all of the file's remaining data is in the buffer, truncated. The patch is only supposed to raise an error when, previously, the file's data would get corrupted. It doesn't prevent mixing iteration and read*-methods in harmless situations (methods followed by iteration, iteration until EOF followed by methods, or iteration until an exact buffer boundary, followed by methods.) The exception currently raised is ValueError, because it seems least inappropriate. Also, read* on closed files raises ValueError (probably for the same reason.) The test_file test has been ammended to include tests for this behaviour. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-01-10 11:46 Message: Logged In: YES user_id=34209 It's more code. More to maintain, more to break. For instance, if the buffer has some data but not enough, you have to read more into the buffer, and I have a nagging suspicion the iteration buffer doesn't take nonblocking files into account right. I'd rather not change all that unless normal (non-iteration) operation uses the buffer in the first place, and that is going to subtly change some of the file semantics (like mixing reading and writing.) The current rule is "don't mix iteration and read*-methods", all this patch does is to enforce that when necessary, not to change that rule. I'd love to overhaul fileobject.c completely, changing it all to buffered mode unless explicitly asked not to. It would probably reduce fileobject.c in size by half :) But that's not a minor change, and Guido already said he wanted to replace most C stdio for Py3K, where possible (and I agree.) If we can achieve the same effect with reasonable backward- and forward-compatibility in 2.6, that would be great, but I'm not going to rush anything to get it in 2.5. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-09 19:50 Message: Logged In: YES user_id=764593 Since you're already adding the if-test (to be able to raise an error), why not just read the data from the buffer if there is one, instead of raising an error? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397960&group_id=5470 From noreply at sourceforge.net Tue Jan 10 15:45:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 06:45:25 -0800 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-10 06:05 Message generated for change (Comment added) made by xudong888 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-10 22:45 Message: Logged In: YES user_id=1420135 I have resolved my question,now I can run python on the mips machine,and can run some binary build by python.Can I also cross compile pygame for python?But the pygame source does't has 'configure' and 'Makefiel' files,setup.py instead in source package.How should I do? Thanks :-) ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 19:08 Message: Logged In: YES user_id=1420135 If you have accounts of MSN,please add me.My accounts is xudong_888 at hotmail.com. I am very impatient.I hope I can get some help from you.Thanks. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 18:57 Message: Logged In: YES user_id=1420135 Thank you for your rapid answer.But I still can't solve my question.I can't find the whole instructions. Can you give me the whole instructions by EMAIL,my email is xudong888 at 163.com,thanks. My "host" system is mips embbed_linux,the release of the linux kernel is 2.4.xx and the CPU type is MIPS 4Kc.There are no python installed on this system.My "build" system is i86 and operate system is RedHat9.0,and has installed python2.4.1 and cross-compiling Tools mipsel-linux-gcc.I can cross compile C program for the "host" system.I have writed some program with python language.I can get the binary from python script by use freeze.py on the "build" system. Now I want to run the binary on the "host" system.Can you tell me how should I do. in addition,I don't know what parameter I should input to use this patch. finally,I'm sorry for my poor English.I like python very much,but I can't get help in chinese. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-01-06 01:24 Message: Logged In: YES user_id=843814 After configure you run "make". But did you use configure as the instructions say? You cannot just use "./configure". Good luck, Dan. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 00:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-09 00:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 23:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 22:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 22:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 10:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 19:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-14 01:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-10 04:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-27 00:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-21 09:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:46:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:46:26 -0800 Subject: [Patches] [ python-Patches-1366311 ] SRE engine do not release the GIL Message-ID: Patches item #1366311, was opened at 2005-11-25 14:57 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1366311&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: SRE engine do not release the GIL Initial Comment: In a multi-threaded program that does lots of regular expression searching, some of them on very long strings with complex regex we've noticed that everything stops when a regular expression is searching. One of the issue is that the re engine does not release the interpreter lock while it is running. All the other threads are therefore blocked for the entire time it takes to do the regular expression search. See the thread in python-dev about it: http://mail.python.org/pipermail/python-dev/2005-November/058316.html ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2005-11-28 15:11 Message: Logged In: YES user_id=1388768 Thanks for your comments. I've updated the patch to fix your issues, but without introducing a per-state object lock. What I did instead is to mark a state as not supporting concurrency when a scanner object creates it. So the GIL will not be released for scanners objects at all. For consistency match also release the GIL now, if possible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-11-25 22:38 Message: Logged In: YES user_id=4771 The patch looks good, but I wonder if it is safe. The SRE_STATE structure that SRE_SEARCH_INNER uses is potentially visible to the application-level Python code, via the (undocumented) scanner objects: >>> r = re.compile(r"hello") >>> s = r.scanner("big string in which to search") >>> s.search() <_sre.SRE_Match object at 0x12345678> Each call to s.search() continues the previous search with the same SRE_STATE. The problem with releasing the GIL as you do is that several threads could call s.search() concurrently, which would most probably crash CPython. This probably means that you need to add a lock in SRE_STATE and acquire it while searching, to serialize its usage. Of course, we should then be careful about what overhead this gives to applications that use regexps on a lot of small strings... Another note: for consistency, match() should also release the GIL if search() does. ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2005-11-25 15:02 Message: Logged In: YES user_id=1388768 I'm attaching a diff to this bug that remove this limitation if it sane to do so. If a search is done on a string or a unicode object (which by definition are immutable) the GIL is released and reacquired everytime a search is done. I've tested this patch in both a simple tests (start a thread with a greedy regex on a monstruous string and verify that the othe python threads are still active) and by running our internal application verifying that nothing is blocking anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1366311&group_id=5470 From noreply at sourceforge.net Wed Jan 11 00:20:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 15:20:16 -0800 Subject: [Patches] [ python-Patches-1402224 ] Need warning that `dl` module can cause segfaults/crashes Message-ID: Patches item #1402224, was opened at 2006-01-10 23: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=1402224&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: Need warning that `dl` module can cause segfaults/crashes Initial Comment: The `dl` module can cause segfaults/crashes if used incorrectly. I recommend the following (or similar) wording be put at the top of the module documentation (preferable in red ;) The `dl` module bypasses the Python type system and error handling. If used incorrectly it may cause segmentation faults, crashes or other incorrect behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402224&group_id=5470 From noreply at sourceforge.net Wed Jan 11 01:24:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 16:24:45 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 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=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Nobody/Anonymous (nobody) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Wed Jan 11 03:03:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 18:03:43 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-10 19:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Nobody/Anonymous (nobody) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 21:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Wed Jan 11 03:16:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 18:16:51 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 Message generated for change (Comment added) made by crutcher_gmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Nobody/Anonymous (nobody) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 18:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 18:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Wed Jan 11 19:12:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 10:12:33 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 Message generated for change (Comment added) made by crutcher_gmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Nobody/Anonymous (nobody) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 10:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 18:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 18:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Wed Jan 11 22:48:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 13:48:50 -0800 Subject: [Patches] [ python-Patches-1101097 ] Feed style codec API Message-ID: Patches item #1101097, was opened at 2005-01-12 19:14 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Feed style codec API Initial Comment: The attached patch implements a feed style codec API by adding feed methods to StreamReader and StreamWriter (see SF patch #998993 for a history of this issue). ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-01-11 22:48 Message: Logged In: YES user_id=89016 The second version of the patch is updated for the current svn head and includes patches to the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 From noreply at sourceforge.net Thu Jan 12 00:11:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 15:11:41 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 Message generated for change (Comment added) made by crutcher_gmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Nobody/Anonymous (nobody) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 15:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 10:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 18:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 18:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Thu Jan 12 02:21:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 17:21:10 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-10 19:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) >Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 20:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 18:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 13:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 21:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 21:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Thu Jan 12 07:11:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 22:11:02 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-11 01:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-12 07:11 Message: Logged In: YES user_id=21627 I think the history is this: it originates from python.org/sf/215126, which requested that you can pass dict subtypes to eval. Armin noted that eval will always produce LOAD/STORE_NAME, so just modifying these opcodes is sufficient to fulfil the feature request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-12 02:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-12 00:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 19:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 03:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 03:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Thu Jan 12 07:23:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 22:23:48 -0800 Subject: [Patches] [ python-Patches-1103116 ] AF_NETLINK sockets basic support Message-ID: Patches item #1103116, was opened at 2005-01-15 23:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103116&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Philippe Biondi (drphil) Assigned to: Nobody/Anonymous (nobody) Summary: AF_NETLINK sockets basic support Initial Comment: This patch adds everything needed to manipulate NETLINK addresses so that it is possible to use NETLINK sockets. Nothing is done in the patch for autoconf stuff, even if the following should do the trick : --- configure.in.ori 2005-01-10 17:09:32.000000000 +0100 +++ configure.in 2005-01-06 18:53:18.000000000 +0100 @@ -967,7 +967,7 @@ sys/audioio.h sys/bsdtty.h sys/file.h sys/loadavg.h sys/lock.h sys/mkdev.h \ sys/modem.h \ sys/param.h sys/poll.h sys/select.h sys/socket.h sys/time.h sys/times.h \ -sys/un.h sys/utsname.h sys/wait.h pty.h libutil.h \ +sys/un.h linux/netlink.h sys/utsname.h sys/wait.h pty.h libutil.h \ sys/resource.h netpacket/packet.h sysexits.h bluetooth.h \ bluetooth/bluetooth.h) AC_HEADER_DIRENT --- pyconfig.h.ori 2005-01-10 17:11:11.000000000 +0100 +++ pyconfig.h 2005-01-06 19:27:33.000000000 +0100 @@ -559,6 +559,9 @@ /* Define to 1 if you have the header file. */ #define HAVE_SYS_UN_H 1 +/* Define to 1 if you have the header file. */ +#define HAVE_LINUX_NETLINK_H 1 + /* Define to 1 if you have the header file. */ #define HAVE_SYS_UTSNAME_H 1 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-12 07:23 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Philippe Biondi (drphil) Date: 2005-01-16 01:28 Message: Logged In: YES user_id=340305 This additionnal patch give a more correct use of PyArg_ParseTuple --- socketmodule.c.ori 2005-01-15 23:55:47.000000000 +0100 +++ socketmodule.c 2005-01-16 01:25:54.000000000 +0100 @@ -1106,7 +1106,7 @@ args->ob_type->tp_name); return 0; } - if (!PyArg_ParseTuple(args, "II", &pid, &groups)) + if (!PyArg_ParseTuple(args, "II:getsockaddrarg", &pid, &groups)) return 0; addr->nl_family = AF_NETLINK; addr->nl_pid = pid; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103116&group_id=5470 From noreply at sourceforge.net Thu Jan 12 08:50:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 23:50:46 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 Message generated for change (Comment added) made by crutcher_gmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 23:50 Message: Logged In: YES user_id=1424288 Well, why fix it for eval but not for exec? I don't think the time hit is noticeable, I ran 'time make test' twice each on the trunk with and without the patch. Here are the results: Trunk: real 9m17.117s user 3m30.930s sys 0m35.417s real 9m9.471s user 3m31.484s sys 0m34.978s Patch: real 9m32.469s user 3m40.134s sys 0m36.140s real 9m6.779s user 3m27.529s sys 0m34.716s ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 22:11 Message: Logged In: YES user_id=21627 I think the history is this: it originates from python.org/sf/215126, which requested that you can pass dict subtypes to eval. Armin noted that eval will always produce LOAD/STORE_NAME, so just modifying these opcodes is sufficient to fulfil the feature request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 17:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 15:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 10:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 18:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 18:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Thu Jan 12 15:20:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 06:20:18 -0800 Subject: [Patches] [ python-Patches-1101097 ] Feed style codec API Message-ID: Patches item #1101097, was opened at 2005-01-12 19:14 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: M.-A. Lemburg (lemburg) Summary: Feed style codec API Initial Comment: The attached patch implements a feed style codec API by adding feed methods to StreamReader and StreamWriter (see SF patch #998993 for a history of this issue). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-12 15:20 Message: Logged In: YES user_id=38388 I don't like the name of the methods, since feed style APIs usually take data and store in the object's state whereas the method you are suggesting is merely an encode method that takes the current state into account. The idea is to allow incremental processing. This is not what your versions implement. The StreamWriter would have to grow buffering for this. The .feed() method on the StreamReader would have to be adjusted to store the input in the .charbuffer only and not return anything. If you just want to make the code easier to follow, I'd suggest you use private methods, e.g. ._stateful_encode() and ._stateful_decode() - which is what these method do implement. Please also explain "If only the \method{feed()} method is used, \var{stream} will be ignored and can be \constant{None}.". I don't see this being true - .write() will still require a .stream object. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-01-11 22:48 Message: Logged In: YES user_id=89016 The second version of the patch is updated for the current svn head and includes patches to the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 From noreply at sourceforge.net Thu Jan 12 16:41:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 07:41:08 -0800 Subject: [Patches] [ python-Patches-1101097 ] Feed style codec API Message-ID: Patches item #1101097, was opened at 2005-01-12 19:14 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Feed style codec API Initial Comment: The attached patch implements a feed style codec API by adding feed methods to StreamReader and StreamWriter (see SF patch #998993 for a history of this issue). ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-01-12 16:41 Message: Logged In: YES user_id=89016 Basically what I want to have is a decoupling of the stateful encoding/decoding from the stream API. An example: Suppose I have a generator: def foo(): yield u"Hello" yield u"World" I want to wrap this generator into another generator that does a stateful encoding of the strings from the first generator: def encode(it, encoding, errors): writer = codecs.getwriter(encoding)(None, errors) for data in it: yield writer.feed(data) for x in encode(foo(), "utf-16", "strict"): print repr(x) '\xff\xfeH\x00e\x00l\x00l\x00o\x00' 'W\x00o\x00r\x00l\x00d\x00' The writer itself shouldn't write anything to the stream (in fact, there is no stream), it should just encode what it gets fed and spit out the result. The reason why StreamWriter.feed() is implemented the way it is, is that currently there are no Python encodings where encode(string)[1] != len(string). If we want to handle that case the StreamWriter would have to grow a charbuffer. Should I add that to the patch? For decoding I want the same functionality: def blocks(name, size=8192): f = open(name, "rb") while True: data = f.read(size) if data: yield data else: break def decode(it, encoding, errors): reader = codecs.getreader(encoding)(None, errors) for data in it: yield reader.feed(data) decode(blocks("foo.xml")) Again, here the StreamReader doesn't read for a stream, it just decodes what it gets fed and spits it back out. I'm not attached to the name "feed". Of course the natural choice for the method names would be "encode" and "decode", but those are already taken. Would "handle" or "convert" be better names? I don't know what the "this" refers to in "This is not what your versions implement". If "this" refers to "The idea is to allow incremental processing", this is exactly what the patch tries to achieve: Incremental processing without tying this processing to a stream API. If "this" refers to "feed style APIs usually take data and store it in the object's state" that's true, but that's not the purpose of the patch, so maybe the name *is* misleading. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-12 15:20 Message: Logged In: YES user_id=38388 I don't like the name of the methods, since feed style APIs usually take data and store in the object's state whereas the method you are suggesting is merely an encode method that takes the current state into account. The idea is to allow incremental processing. This is not what your versions implement. The StreamWriter would have to grow buffering for this. The .feed() method on the StreamReader would have to be adjusted to store the input in the .charbuffer only and not return anything. If you just want to make the code easier to follow, I'd suggest you use private methods, e.g. ._stateful_encode() and ._stateful_decode() - which is what these method do implement. Please also explain "If only the \method{feed()} method is used, \var{stream} will be ignored and can be \constant{None}.". I don't see this being true - .write() will still require a .stream object. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-01-11 22:48 Message: Logged In: YES user_id=89016 The second version of the patch is updated for the current svn head and includes patches to the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 From noreply at sourceforge.net Thu Jan 12 22:59:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 13:59:02 -0800 Subject: [Patches] [ python-Patches-1399309 ] ConfigParser to save with order Message-ID: Patches item #1399309, was opened at 2006-01-08 07:11 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1399309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser to save with order Initial Comment: ConfigParser saves the data in a not-predefined order. This is because it keeps, internally, the information in dictionaries. This patch orders the info to be saved in the file through the ConfigParser write() method. This patch does not let the user to specify the order. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2006-01-13 10:59 Message: Logged In: YES user_id=552329 Note that the patch is backwards (new old instead of old new). IMO the 'surgical' editing that has been proposed many times on python-dev and c.l.p would be superior to this. IOW, the original order of the file should be retained (any new entries could be added alphabetically, as here). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1399309&group_id=5470 From noreply at sourceforge.net Fri Jan 13 01:37:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:37:45 -0800 Subject: [Patches] [ python-Patches-1404357 ] Suggested patch for #1403410 Message-ID: Patches item #1404357, was opened at 2006-01-13 01: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=1404357&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Suggested patch for #1403410 Initial Comment: Suggested patch for #1403410 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1404357&group_id=5470 From noreply at sourceforge.net Fri Jan 13 02:00:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 17:00:40 -0800 Subject: [Patches] [ python-Patches-1404374 ] Patch for #1394565 Message-ID: Patches item #1404374, was opened at 2006-01-13 02: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=1404374&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1394565 Initial Comment: Ignore params and querystring for SimpleHttpServer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1404374&group_id=5470 From noreply at sourceforge.net Fri Jan 13 16:32:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 07:32:30 -0800 Subject: [Patches] [ python-Patches-1404374 ] Patch for #1394565 Message-ID: Patches item #1404374, was opened at 2006-01-12 20:00 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1404374&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1394565 Initial Comment: Ignore params and querystring for SimpleHttpServer ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 10:32 Message: Logged In: YES user_id=764593 The related bug is that requesting a file works, but requesting that same file with parameters or a query string will fail. Most servers still return the file, and just ignore the extra information, except for logging purposes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1404374&group_id=5470 From noreply at sourceforge.net Fri Jan 13 16:33:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 07:33:28 -0800 Subject: [Patches] [ python-Patches-1404357 ] Suggested patch for #1403410 Message-ID: Patches item #1404357, was opened at 2006-01-12 19:37 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1404357&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Suggested patch for #1403410 Initial Comment: Suggested patch for #1403410 ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 10:33 Message: Logged In: YES user_id=764593 The related bug is that a reasonably helpful exception gets masked by one that provides almost no help in debugging the root cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1404357&group_id=5470 From noreply at sourceforge.net Fri Jan 13 18:01:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 09:01:00 -0800 Subject: [Patches] [ python-Patches-1404357 ] Suggested patch for #1403410 Message-ID: Patches item #1404357, was opened at 2006-01-13 01:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1404357&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Suggested patch for #1403410 Initial Comment: Suggested patch for #1403410 ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 18:00 Message: Logged In: YES user_id=1188172 Committed as revision 42028,42029. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 16:33 Message: Logged In: YES user_id=764593 The related bug is that a reasonably helpful exception gets masked by one that provides almost no help in debugging the root cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1404357&group_id=5470 From noreply at sourceforge.net Fri Jan 13 18:08:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 09:08:26 -0800 Subject: [Patches] [ python-Patches-1404374 ] Patch for #1394565 Message-ID: Patches item #1404374, was opened at 2006-01-13 02:00 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1404374&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1394565 Initial Comment: Ignore params and querystring for SimpleHttpServer ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 18:08 Message: Logged In: YES user_id=1188172 Thanks, committed in revisions 42030,42031. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 16:32 Message: Logged In: YES user_id=764593 The related bug is that requesting a file works, but requesting that same file with parameters or a query string will fail. Most servers still return the file, and just ignore the extra information, except for logging purposes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1404374&group_id=5470 From noreply at sourceforge.net Fri Jan 13 22:52:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 13:52:31 -0800 Subject: [Patches] [ python-Patches-1391204 ] dict.merge Message-ID: Patches item #1391204, was opened at 2005-12-27 08:00 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1391204&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Guido van Rossum (gvanrossum) Summary: dict.merge Initial Comment: If you want to update a dictionary with another one, you can simply use update : a = dict(a=1,c=3) b = dict(a=0,b=2) a.update(b) assert a == dict(a=0,b=2,c=3) However, sometimes you want to merge the second dict into the first, all while keeping the values that are already defined in the first. This is useful if you want to insert default values in the dictionary without overriding what is already defined. Currently this can be done in a few different ways, but all are awkward and/or inefficient : a = dict(a=1,c=3) b = dict(a=0,b=2) Method 1: for k in b: if k not in a: a[k] = b[k] Method 2: temp = dict(b) temp.update(a) a = temp This patch adds a merge() method to the dict object, with the same signature and usage as the update() method. Under the hood, it simply uses PyDict_Merge() with the override parameter set to 0 instead of 1. There's nothing new, therefore : the C API already provides this functionality (though it is not used in the dictobject.c scope), so why not expose it ? The result is : a = dict(a=1,c=3) b = dict(a=0,b=2) a.merge(b) assert a == dict(a=1,b=2,c=3) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 16:52 Message: Logged In: YES user_id=764593 The times I have wanted it are for configuration settings. If I don't find the answer in the first place, I look in the defaults -- and I would prefer to update the current settings all at once, since I'm going to the trouble of creating creating/finding the defaults dictionary. I don't want to change the defaults, since they typically apply over a wider scope than the current context. Note that this isn't a random permutation -- it is an existing permutation that is already exported to C extensions, and just not to python code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-01-01 12:55 Message: Logged In: YES user_id=6380 I don't think we need to provide every possible permutation of existing operations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-01 01:17 Message: Logged In: YES user_id=80475 The example is only slightly complicated by the implicit requirement to keep b unchanged; otherwise, it is easy enough to swap the dicts before updating: a,b=b,a; a.update(b). Anyway, I do not think the use case is sufficiently common or cumbersome to warrant making the mapping API more complex. Guido? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1391204&group_id=5470 From noreply at sourceforge.net Fri Jan 13 23:09:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 14:09:08 -0800 Subject: [Patches] [ python-Patches-1397711 ] Fix dict and set docs, re: immutability Message-ID: Patches item #1397711, was opened at 2006-01-05 07:28 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dict and set docs, re: immutability Initial Comment: This patch resolves bug #1368768. As mentioned in the bug description, the documentation for sets and dicts incorrectly reports that set members and dict keys must be immutable. This patch corrects this, changing references to immutability to hashability and inserting footnotes describing what is meant by "hashable". The patch is a diff against Doc/lib/libstdtypes.tex from SVN revision 41926. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 17:09 Message: Logged In: YES user_id=764593 Definately an improvement, but it still may not be quite right in the footnote. You don't have to define a __hash__ method; you just need to avoid redefining it (or __eq__) to something that doesn't work. Here is another stab Hashable objects must define or inherit proper \method{__hash__} and \method{__eq__} methods. Most objects do, but some mutable types -- including lists -- redefine equality in such a way that the hash code would not be stable. Instead, their hash functions return -1 to indicate that the object should not be used as a dict key or set member. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397711&group_id=5470 From noreply at sourceforge.net Sat Jan 14 02:53:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 17:53:32 -0800 Subject: [Patches] [ python-Patches-1391204 ] dict.merge Message-ID: Patches item #1391204, was opened at 2005-12-27 08:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1391204&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Guido van Rossum (gvanrossum) Summary: dict.merge Initial Comment: If you want to update a dictionary with another one, you can simply use update : a = dict(a=1,c=3) b = dict(a=0,b=2) a.update(b) assert a == dict(a=0,b=2,c=3) However, sometimes you want to merge the second dict into the first, all while keeping the values that are already defined in the first. This is useful if you want to insert default values in the dictionary without overriding what is already defined. Currently this can be done in a few different ways, but all are awkward and/or inefficient : a = dict(a=1,c=3) b = dict(a=0,b=2) Method 1: for k in b: if k not in a: a[k] = b[k] Method 2: temp = dict(b) temp.update(a) a = temp This patch adds a merge() method to the dict object, with the same signature and usage as the update() method. Under the hood, it simply uses PyDict_Merge() with the override parameter set to 0 instead of 1. There's nothing new, therefore : the C API already provides this functionality (though it is not used in the dictobject.c scope), so why not expose it ? The result is : a = dict(a=1,c=3) b = dict(a=0,b=2) a.merge(b) assert a == dict(a=1,b=2,c=3) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-13 20:53 Message: Logged In: YES user_id=80475 -1 Because it is not hard to do with existing tools, because adding variants makes the interface harder to learn (hmm, was it merge() or update() that behaves thusly?), and because it is not wise to treat this the one-way-to-do-it (i.e. the config default setting use case may be better solved with chainmap(), http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305268 , which doesn't duplicate data and allows subsequent dynamic updates to either the deaults or specified overrides). The existence of underlying C code does not make a case for exposing it in Python. We have lots of internal code used solely for the convenience of the underlying implementation or made part of the C API to simplify coding extensions (usually for things that are trivial in Python but a PITA for an extension). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 16:52 Message: Logged In: YES user_id=764593 The times I have wanted it are for configuration settings. If I don't find the answer in the first place, I look in the defaults -- and I would prefer to update the current settings all at once, since I'm going to the trouble of creating creating/finding the defaults dictionary. I don't want to change the defaults, since they typically apply over a wider scope than the current context. Note that this isn't a random permutation -- it is an existing permutation that is already exported to C extensions, and just not to python code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-01-01 12:55 Message: Logged In: YES user_id=6380 I don't think we need to provide every possible permutation of existing operations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-01 01:17 Message: Logged In: YES user_id=80475 The example is only slightly complicated by the implicit requirement to keep b unchanged; otherwise, it is easy enough to swap the dicts before updating: a,b=b,a; a.update(b). Anyway, I do not think the use case is sufficiently common or cumbersome to warrant making the mapping API more complex. Guido? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1391204&group_id=5470 From noreply at sourceforge.net Sat Jan 14 10:54:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 01:54:56 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-11 00:24 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-01-14 09:54 Message: Logged In: YES user_id=4771 Provided this can be done with no measurable performance hit, I guess that I'm fine with the idea. The patch needs a bit more work, though: I don't see why it should accept dict subclasses as globals but not arbitrary mappings (as it now does for the locals). This is mainly an issue of removing a few checks in various places, like EXEC_STMT and the eval() and execfile() built-ins. There is a missing exception check/clear in the part about LOAD_NAME, after the PyObject_GetItem(f->f_globals, w). A side note: in the current trunk already, LOAD_GLOBAL contains a couple of checks, namely PyString_CheckExact() and hash != -1. We might be able to prove in advance that these two conditions are always true. We could then remove the checks. Not sure the difference measurable, though. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-12 07:50 Message: Logged In: YES user_id=1424288 Well, why fix it for eval but not for exec? I don't think the time hit is noticeable, I ran 'time make test' twice each on the trunk with and without the patch. Here are the results: Trunk: real 9m17.117s user 3m30.930s sys 0m35.417s real 9m9.471s user 3m31.484s sys 0m34.978s Patch: real 9m32.469s user 3m40.134s sys 0m36.140s real 9m6.779s user 3m27.529s sys 0m34.716s ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-12 06:11 Message: Logged In: YES user_id=21627 I think the history is this: it originates from python.org/sf/215126, which requested that you can pass dict subtypes to eval. Armin noted that eval will always produce LOAD/STORE_NAME, so just modifying these opcodes is sufficient to fulfil the feature request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-12 01:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 23:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 18:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 02:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 02:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Sat Jan 14 19:13:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 10:13:35 -0800 Subject: [Patches] [ python-Patches-1103116 ] AF_NETLINK sockets basic support Message-ID: Patches item #1103116, was opened at 2005-01-15 23:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103116&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Philippe Biondi (drphil) Assigned to: Nobody/Anonymous (nobody) Summary: AF_NETLINK sockets basic support Initial Comment: This patch adds everything needed to manipulate NETLINK addresses so that it is possible to use NETLINK sockets. Nothing is done in the patch for autoconf stuff, even if the following should do the trick : --- configure.in.ori 2005-01-10 17:09:32.000000000 +0100 +++ configure.in 2005-01-06 18:53:18.000000000 +0100 @@ -967,7 +967,7 @@ sys/audioio.h sys/bsdtty.h sys/file.h sys/loadavg.h sys/lock.h sys/mkdev.h \ sys/modem.h \ sys/param.h sys/poll.h sys/select.h sys/socket.h sys/time.h sys/times.h \ -sys/un.h sys/utsname.h sys/wait.h pty.h libutil.h \ +sys/un.h linux/netlink.h sys/utsname.h sys/wait.h pty.h libutil.h \ sys/resource.h netpacket/packet.h sysexits.h bluetooth.h \ bluetooth/bluetooth.h) AC_HEADER_DIRENT --- pyconfig.h.ori 2005-01-10 17:11:11.000000000 +0100 +++ pyconfig.h 2005-01-06 19:27:33.000000000 +0100 @@ -559,6 +559,9 @@ /* Define to 1 if you have the header file. */ #define HAVE_SYS_UN_H 1 +/* Define to 1 if you have the header file. */ +#define HAVE_LINUX_NETLINK_H 1 + /* Define to 1 if you have the header file. */ #define HAVE_SYS_UTSNAME_H 1 ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-14 19:13 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as 42046. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-12 07:23 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Philippe Biondi (drphil) Date: 2005-01-16 01:28 Message: Logged In: YES user_id=340305 This additionnal patch give a more correct use of PyArg_ParseTuple --- socketmodule.c.ori 2005-01-15 23:55:47.000000000 +0100 +++ socketmodule.c 2005-01-16 01:25:54.000000000 +0100 @@ -1106,7 +1106,7 @@ args->ob_type->tp_name); return 0; } - if (!PyArg_ParseTuple(args, "II", &pid, &groups)) + if (!PyArg_ParseTuple(args, "II:getsockaddrarg", &pid, &groups)) return 0; addr->nl_family = AF_NETLINK; addr->nl_pid = pid; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103116&group_id=5470 From noreply at sourceforge.net Sat Jan 14 19:19:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 10:19:54 -0800 Subject: [Patches] [ python-Patches-1396093 ] Further .vcproj cleanups Message-ID: Patches item #1396093, was opened at 2006-01-03 16:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Adal Chiriliuc (adalx) >Assigned to: Martin v. L??wis (loewis) Summary: Further .vcproj cleanups Initial Comment: The #1307806 patch failed to apply completely in r41897, probably because it was generated for Python 2.4.2 which didn't include the AST files. I've attached a patch which will complete the cleanup of pythoncore.vcproj and which also cleans up _elementtree.vcproj. Note that there is a bug in the current pythoncore.vcproj: The BUILD macro is defined as 60, it should be at least 67 as it was in Python 2.4.2. I didn't fix this since I don't know what's the correct BUILD number for Python 2.5 (68?). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-14 19:19 Message: Logged In: YES user_id=21627 The build number is gone in Python 2.5, so we should just remove all traces of it; I will do that. For reference, see PCbuild/BUILDno.txt. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-01-03 17:02 Message: Logged In: YES user_id=11105 The build number is usually set to the correct value shortly before a binary release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 From noreply at sourceforge.net Sat Jan 14 19:27:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 10:27:36 -0800 Subject: [Patches] [ python-Patches-1396919 ] FreeBSD is system scope threads capable Message-ID: Patches item #1396919, was opened at 2006-01-04 15:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396919&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Valts (valdiic) >Assigned to: Hye-Shik Chang (perky) Summary: FreeBSD is system scope threads capable Initial Comment: I was a little bit disapointed when I mentioned that Python 2.4 uses libpthread library on FreeBSD 5 but avoids using system scope threads. I tried digging google to clarify why it is so and found out that it was because one of threading regression tests (test_threaded_import) failed on FreeBSD 5 (https:// sourceforge.net/tracker/? func=detail&atid=305470&aid=902444&group_id=5470). I compiled Python on my FreeBSD 5.4-RELEASE-p8 and ran all the regression tests (I executed regrtest.py) and saw no errors at all. I tried test_threaded_import and the test was successful. I don't see any reason why to avoid using system scope threads specially on FreeBSD. I know that using userland scope threads is quite faster because there is no need for kernel activities in context switching. But as far as I know most of servers (where speed is important) are SMP boxes. Userland scope threads don't use capabilities of multiple CPU's, so it should be reasonable to use system scope threads. To make it even better it could be good idea to make use of configuration parameter which determines which kind of threads has to be used. Since I'm not autoconf guru I made a patch which just removes checking against FreeBSD in thread_pthread.h Regards, Valts. mailto:valdiic at one.lv ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-14 19:27 Message: Logged In: YES user_id=21627 perky, you created the original patch. can you please review this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396919&group_id=5470 From noreply at sourceforge.net Sat Jan 14 19:29:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 10:29:10 -0800 Subject: [Patches] [ python-Patches-1381398 ] bind() for netlink sockets Message-ID: Patches item #1381398, was opened at 2005-12-15 10:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1381398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Timo Metsala (metsala) Assigned to: Nobody/Anonymous (nobody) Summary: bind() for netlink sockets Initial Comment: Support for netlink sockets in Linux (AF_NETLINK) doesn't currently include bind()ing to a local address. The attached patch adds this functionality (local address of a netlink socket consists of process id and/or group bitmask). Example use: def get_bound_nl_sock(netlink_family): net_fd = socket.socket(socket.AF_NETLINK, socket.SOCK_RAW, netlink_family) net_fd.bind((os.getpid(),0)) return net_fd Patch made against Python 2.4.2, tested in Linux 2.4.20-8 (Red Hat 9) ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-14 19:29 Message: Logged In: YES user_id=21627 This is outdated now, as #1103116 was applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1381398&group_id=5470 From noreply at sourceforge.net Sat Jan 14 19:40:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 10:40:50 -0800 Subject: [Patches] [ python-Patches-1396093 ] Further .vcproj cleanups Message-ID: Patches item #1396093, was opened at 2006-01-03 16:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Adal Chiriliuc (adalx) Assigned to: Martin v. L??wis (loewis) Summary: Further .vcproj cleanups Initial Comment: The #1307806 patch failed to apply completely in r41897, probably because it was generated for Python 2.4.2 which didn't include the AST files. I've attached a patch which will complete the cleanup of pythoncore.vcproj and which also cleans up _elementtree.vcproj. Note that there is a bug in the current pythoncore.vcproj: The BUILD macro is defined as 60, it should be at least 67 as it was in Python 2.4.2. I didn't fix this since I don't know what's the correct BUILD number for Python 2.5 (68?). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-14 19:40 Message: Logged In: YES user_id=21627 This patch is wrong: for expat, it removes HAVE_EXPAT_H, XML_NS, etc, which are all necessary for expat to be build correctly. Also, can you please create the patches through "svn diff"? Then it is clearer what revision you are diffing against. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-14 19:19 Message: Logged In: YES user_id=21627 The build number is gone in Python 2.5, so we should just remove all traces of it; I will do that. For reference, see PCbuild/BUILDno.txt. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-01-03 17:02 Message: Logged In: YES user_id=11105 The build number is usually set to the correct value shortly before a binary release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 From noreply at sourceforge.net Sat Jan 14 21:38:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 12:38:20 -0800 Subject: [Patches] [ python-Patches-1396093 ] Further .vcproj cleanups Message-ID: Patches item #1396093, was opened at 2006-01-03 17:58 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Adal Chiriliuc (adalx) Assigned to: Martin v. L??wis (loewis) Summary: Further .vcproj cleanups Initial Comment: The #1307806 patch failed to apply completely in r41897, probably because it was generated for Python 2.4.2 which didn't include the AST files. I've attached a patch which will complete the cleanup of pythoncore.vcproj and which also cleans up _elementtree.vcproj. Note that there is a bug in the current pythoncore.vcproj: The BUILD macro is defined as 60, it should be at least 67 as it was in Python 2.4.2. I didn't fix this since I don't know what's the correct BUILD number for Python 2.5 (68?). ---------------------------------------------------------------------- >Comment By: Adal Chiriliuc (adalx) Date: 2006-01-14 22:38 Message: Logged In: YES user_id=1067739 The patch is fine. HAVE_EXPAT_H and other macros are not removed. Instead the individual definition of those macros for each file is removed, which is exactly the purpose of this patch. You can see those macros defined in the "PreprocessorDefinitions" attribute of each compiler tool entry for the three configurations (Debug, Release, Itanium Release). Have you tried to compile the project and failed? I didn't tried it since it would require me to checkout/export the whole HEAD, but I would be very surprised if it didn't work. If that's not an appropiate procedure, feel free to drop this patch. It was created against HEAD at that time. The files which are modified (_elementtree.vcproj and pythoncore.vcproj) haven't change in the meantime. So the patch is still against HEAD. In fact, I've downloaded the current versions of those two files and applied the patch and everything was as intended. So I don't see the purpose of uploading another patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-14 20:40 Message: Logged In: YES user_id=21627 This patch is wrong: for expat, it removes HAVE_EXPAT_H, XML_NS, etc, which are all necessary for expat to be build correctly. Also, can you please create the patches through "svn diff"? Then it is clearer what revision you are diffing against. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-14 20:19 Message: Logged In: YES user_id=21627 The build number is gone in Python 2.5, so we should just remove all traces of it; I will do that. For reference, see PCbuild/BUILDno.txt. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-01-03 18:02 Message: Logged In: YES user_id=11105 The build number is usually set to the correct value shortly before a binary release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 From noreply at sourceforge.net Sat Jan 14 23:39:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 14:39:19 -0800 Subject: [Patches] [ python-Patches-1406159 ] Patch for #1371247 Message-ID: Patches item #1406159, was opened at 2006-01-14 23:39 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=1406159&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1371247 Initial Comment: More complete list of windows_locale as suggested in #1371247 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1406159&group_id=5470 From noreply at sourceforge.net Sat Jan 14 23:49:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 14:49:54 -0800 Subject: [Patches] [ python-Patches-1406159 ] Patch for #1371247 Message-ID: Patches item #1406159, was opened at 2006-01-14 23:39 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1406159&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1371247 Initial Comment: More complete list of windows_locale as suggested in #1371247 ---------------------------------------------------------------------- >Comment By: Peter van Kampen (pterk) Date: 2006-01-14 23:49 Message: Logged In: YES user_id=174455 Fix the hex for spanish ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1406159&group_id=5470 From noreply at sourceforge.net Sun Jan 15 10:27:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Jan 2006 01:27:10 -0800 Subject: [Patches] [ python-Patches-1396093 ] Further .vcproj cleanups Message-ID: Patches item #1396093, was opened at 2006-01-03 16:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Adal Chiriliuc (adalx) Assigned to: Martin v. L??wis (loewis) Summary: Further .vcproj cleanups Initial Comment: The #1307806 patch failed to apply completely in r41897, probably because it was generated for Python 2.4.2 which didn't include the AST files. I've attached a patch which will complete the cleanup of pythoncore.vcproj and which also cleans up _elementtree.vcproj. Note that there is a bug in the current pythoncore.vcproj: The BUILD macro is defined as 60, it should be at least 67 as it was in Python 2.4.2. I didn't fix this since I don't know what's the correct BUILD number for Python 2.5 (68?). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-15 10:27 Message: Logged In: YES user_id=21627 Thanks for the patch, I misread it. Applied as r42055. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2006-01-14 21:38 Message: Logged In: YES user_id=1067739 The patch is fine. HAVE_EXPAT_H and other macros are not removed. Instead the individual definition of those macros for each file is removed, which is exactly the purpose of this patch. You can see those macros defined in the "PreprocessorDefinitions" attribute of each compiler tool entry for the three configurations (Debug, Release, Itanium Release). Have you tried to compile the project and failed? I didn't tried it since it would require me to checkout/export the whole HEAD, but I would be very surprised if it didn't work. If that's not an appropiate procedure, feel free to drop this patch. It was created against HEAD at that time. The files which are modified (_elementtree.vcproj and pythoncore.vcproj) haven't change in the meantime. So the patch is still against HEAD. In fact, I've downloaded the current versions of those two files and applied the patch and everything was as intended. So I don't see the purpose of uploading another patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-14 19:40 Message: Logged In: YES user_id=21627 This patch is wrong: for expat, it removes HAVE_EXPAT_H, XML_NS, etc, which are all necessary for expat to be build correctly. Also, can you please create the patches through "svn diff"? Then it is clearer what revision you are diffing against. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-14 19:19 Message: Logged In: YES user_id=21627 The build number is gone in Python 2.5, so we should just remove all traces of it; I will do that. For reference, see PCbuild/BUILDno.txt. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-01-03 17:02 Message: Logged In: YES user_id=11105 The build number is usually set to the correct value shortly before a binary release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396093&group_id=5470 From noreply at sourceforge.net Mon Jan 16 04:22:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Jan 2006 19:22:58 -0800 Subject: [Patches] [ python-Patches-1407021 ] Doc patch for bug #1396471 Message-ID: Patches item #1407021, was opened at 2006-01-16 04:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407021&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Doc patch for bug #1396471 Initial Comment: Document a bug and work-around in the ftell c-library call on windows when opening files with unix-style line-endings. Also fixes a typo that texcheck.py warned about. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407021&group_id=5470 From noreply at sourceforge.net Mon Jan 16 09:44:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 00:44:19 -0800 Subject: [Patches] [ python-Patches-1407135 ] anonymous mmap Message-ID: Patches item #1407135, was opened at 2006-01-16 09:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: anonymous mmap Initial Comment: make mmap.mmap(-1, size) map anonymous memory on both windows and unix-like systems. If this goes in, I'll also write some documentation. here's some more reasoning: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=1402308&group_id=5470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 From noreply at sourceforge.net Mon Jan 16 12:58:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 03:58:35 -0800 Subject: [Patches] [ python-Patches-1407280 ] ParenMatch: workaround for misinterpreting of closing parens Message-ID: Patches item #1407280, was opened at 2006-01-16 13: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=1407280&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: ParenMatch: workaround for misinterpreting of closing parens Initial Comment: ParenMatch sometimes misinterprets closing parenthesis because it is given a bad keysym. The real bug is probably somewhere in the event handling mechanism or something. Somehow the text widget gets the right signal and the appropriate closing paren is written there. This simple patch checks the last inserted character in the text widget insted of the generated keysym, and acts accordingly. Since the function where the workaround is applied reads text from the text widget from the same index anyways, I think this workaround is actually much cleaner than checking the keysym! Works like a charm on my Python2.4 WinXP installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407280&group_id=5470 From noreply at sourceforge.net Mon Jan 16 21:13:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 12:13:01 -0800 Subject: [Patches] [ python-Patches-1367711 ] Remove usage of UserDict from os.py Message-ID: Patches item #1367711, was opened at 2005-11-27 21:18 Message generated for change (Comment added) made by tds33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None >Priority: 3 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: Remove usage of UserDict from os.py Initial Comment: This patch removes UserDict usage from os.py. It uses the new dict base class instead of UserDict. Patch was generated against Revision 41544 of python subersion repository. ---------------------------------------------------------------------- >Comment By: Wolfgang Langner (tds33) Date: 2006-01-16 21:13 Message: Logged In: YES user_id=600792 The intend was to remove dependency on UserDict. Less imports for a minimal python. If there are general problems with the inheritence from dict than they should be documented. I thought in future UserDict will gone. I investigate this problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-29 19:02 Message: Logged In: YES user_id=4771 Subclassing 'dict' to modify some behavior only works more or less in CPython. There are a lot of (admitedly convoluted) ways to get unexpected effects, where the original methods are called instead of the overridden ones. And it's not future-proof: if new methods are added to 'dict' in the future, say a merge() similar to update() but not replacing existing keys, then they will need to be added to that subclass as well, or the method will misbehave. The advantage of UserDict is to guard against all these problems. For example, with the patch: exec "global a; a=5" in os.environ stores the key 'a' directly in os.environ, bypassing the custom __setitem__(). With UserDict instead, we get an explicit error. This is more a joke, but the new-methods-appearing-later problem is more serious IMHO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367711&group_id=5470 From noreply at sourceforge.net Mon Jan 16 22:56:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 13:56:08 -0800 Subject: [Patches] [ python-Patches-988761 ] re.split emptyok flag (fix for #852532) Message-ID: Patches item #988761, was opened at 2004-07-11 03:25 Message generated for change (Comment added) made by filips You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Fredrik Lundh (effbot) Summary: re.split emptyok flag (fix for #852532) Initial Comment: This patch addresses bug #852532. The underlying problem is that re.split ignores any match it makes that has length zero, which blocks a number of useful possibilities. The attached patch implements a flag 'emptyok', which if set to True, causes re.split to allow zero length matches. My preference would be to just change the behavior of re.split, rather than adding this flag. The old behavior isn't documented (though a couple of cases in test_re.py do depend on it). As a practical matter, though, I realize that there may be some code out there relying on this undocumented behavior. And I'm hoping that this useful feature can be added quickly. Perhaps this new behavior could be made the default in a future version of Python. (Linux 2.6.3 i686) ---------------------------------------------------------------------- Comment By: Filip Salomonsson (filips) Date: 2006-01-16 21:56 Message: Logged In: YES user_id=308203 I agree completely that splitting on non-zero matches should be supported - and that the default behavior should change at some point - but I don't think this patch quite covers it. Taking an example from the dev-python thread back in August of 2004 (http://mail.python.org/pipermail/python-dev/2004-August/047272.html): >>> re.split('x*', 'abxxxcdefxxx', emptyok=True) ['', 'a', 'b', '', 'c', 'd', 'e', 'f', '', ''] To me, this means there's an empty string, beginning and ending in pos 0, followed by a zero-width divider also beginning and ending in the same position, followed by an 'a', etc. That seems awkward to me. I think a more intuitive result would be (I'm omitting the emptyok argument in the following examples): >>> re.split('x*', 'abxxxcdefxxx') ['a', 'b', 'c', 'd', 'e', 'f', ''] That is, empty matches cause a split when they are not adjacent to a non-empty match and not at the beginning or the end of the string. Grouping parentheses would, of course, reveal the empty-string boundaries: >>> re.split('(x*)', 'abxxxcdefxxx') ['', 'a', '', 'b', 'xxx', '', 'c', '', 'd', '', 'e', '', 'f', 'xxx', ''] Using the same approach, these results would also seem perfectly reasonable to me: >>> re.split('(?m)$', 'foo\nbar\nbaz') ['foo', '\nbar', '\nbaz'] >>> re.split('(?m)^', 'foo\nbar\nbaz') ['foo\n', 'bar\n', 'baz'] Splitting a one-character string should be possible only if the pattern matches that character: >>> re.split('\w*', 'a') ['', ''] >>> re.split('\d*', 'a') ['a'] ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2005-12-09 17:04 Message: Logged In: YES user_id=555 This patch seems to have been stalled now for over a year. Could it be applied? Or, alternatively, could someone provide some sort of reason why it shouldn't be? Thanks. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 22:53 Message: Logged In: YES user_id=80475 Fred, what do you think of the proposal. Are the backwards compatability issues worth it? ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-09-03 20:15 Message: Logged In: YES user_id=555 Apparently this patch is stalled, but I'd like to get it in, in some form, for 2.4. The only question, as far as I know, is whether empty matches following non-empty matches "count" or not (they do in the original patch). If I make a patch with the "doesn't count" behavior, could we apply that right away? I'd rather get either behavior in for 2.4 than wait for 2.5... ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-07-28 16:23 Message: Logged In: YES user_id=555 I picked through CVS, python-dev and google and came up with this. The current behavior was present way back in the earliest regsub.py in CVS (dated Sep 1992); subsequent implementation seem to be mirroring this behavior. The CVS comment back in 1992 described split as modeled on nawk. A check of nawk(1) confirms that nawk only splits on non-null matches. Perl (circa 5.6) on the other hand, appears to split the way this patch does (though I wasn't aware of that when I wrote the patch) so that might argue in the other direction. I would note, too, that re.findall and re.finditer tend in this direction ("Empty matches are included in the result unless they touch the beginning of another match."). The python-dev archive doesn't seem to go back far enough to be relevant and I'm not sure how to search it. General googling (python "re.split" empty match) found a few hits. Probably the most relevant is Tim Peters saying "Python won't change here (IMO)" and giving the example that he also gives in a comment to bug #852532 (which this patch addresses). He also wonders in his comment about the possibility of a "design constraint", but I think this patch addresses that concern. As far as I can tell, the current behavior was a design decision made over 10 years ago, between two alternatives that probably didn't matter much at the time. Skipping empty matches probably seemed harmless before lookahead/lookbehind assertions. Now, though, the current behavior seems like a significant hindrance. Furthermore, it ought to be pretty trivial to modify any existing patterns to get the old behavior, should that be desired (e.g., use 'x+' instead of 'x*'). (I didn't notice that re.findall doc when I originally wrote this patch. Perhaps the doc in the patch should be slightly modified to help emphasize the similarity between how re.findall and re.split handle empty matches.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-27 14:08 Message: Logged In: YES user_id=11375 Overall I like the patch and wouldn't mind seeing the change become the default behaviour. However, I'm nervous about possibly not understanding the reason the prohibition on zero-length matches was added in the first place. Can you please do some research in the CVS logs and python-dev archives to figure out why the limitation was implemented in the first place? ---------------------------------------------------------------------- Comment By: Chris King (colander_man) Date: 2004-07-21 12:46 Message: Logged In: YES user_id=573252 Practical example where the current behaviour produces undesirable results (splitting on character transitions): >>> import re >>> re.split(r'(?<=[A-Z])(?=[^a-z])','SOMEstring') ['SOMEstring'] # desired is ['SOME','string'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 From noreply at sourceforge.net Tue Jan 17 06:22:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 21:22:37 -0800 Subject: [Patches] [ python-Patches-1407135 ] anonymous mmap Message-ID: Patches item #1407135, was opened at 2006-01-16 00:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: anonymous mmap Initial Comment: make mmap.mmap(-1, size) map anonymous memory on both windows and unix-like systems. If this goes in, I'll also write some documentation. here's some more reasoning: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=1402308&group_id=5470 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-16 21:22 Message: Logged In: YES user_id=33168 In addition to docs, tests will also be necessary before committing. What if fd == -1 and MAP_ANON is not defined? It seems the state could be inconsistent. Shouldn't an exception be raised in this case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 From noreply at sourceforge.net Tue Jan 17 08:51:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 23:51:54 -0800 Subject: [Patches] [ python-Patches-1407992 ] fix bsddb test associate problems w/bsddb 4.1 Message-ID: Patches item #1407992, was opened at 2006-01-16 23:51 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=1407992&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix bsddb test associate problems w/bsddb 4.1 Initial Comment: I think that's what this patch fixes. Just wanted to get up here and find a BSD DB knowledgable person to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407992&group_id=5470 From noreply at sourceforge.net Tue Jan 17 09:48:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 00:48:10 -0800 Subject: [Patches] [ python-Patches-1407135 ] anonymous mmap Message-ID: Patches item #1407135, was opened at 2006-01-16 09:44 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: anonymous mmap Initial Comment: make mmap.mmap(-1, size) map anonymous memory on both windows and unix-like systems. If this goes in, I'll also write some documentation. here's some more reasoning: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=1402308&group_id=5470 ---------------------------------------------------------------------- >Comment By: Ralf Schmitt (titty) Date: 2006-01-17 09:48 Message: Logged In: YES user_id=17929 quoting ubuntu's mmap man page: MAP_ANONYMOUS The mapping is not backed by any file; the fd and offset arguments are ignored. This flag in conjunction with MAP_SHARED is implemented since Linux 2.4. MAP_ANON Alias for MAP_ANONYMOUS. Deprecated. --- On a glibc 2.1 system (once installed with a 2.2 kernel, now running a 2.4 one) the manpage doesn't even mention MAP_ANON(YMOUS). The patch in it's current form will just fail on system's not defining MAP_ANON (i.e. mmap will fail and an exception will be raised). However, according to Stevens 'Advanced Programming in the Unix Environment', chapter 14.9, there are two ways to mmap anonymous memory. The first one works by using MAP_ANON (4.3+BSD), and the second one works by opening /dev/zero and passing that as a filedescriptor to mmap (SVR4). So, I guess all BSD's and newer Linux Systems would work with this version. Anyway I can send another patch handling that case if you like? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 06:22 Message: Logged In: YES user_id=33168 In addition to docs, tests will also be necessary before committing. What if fd == -1 and MAP_ANON is not defined? It seems the state could be inconsistent. Shouldn't an exception be raised in this case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 From noreply at sourceforge.net Tue Jan 17 09:59:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 00:59:57 -0800 Subject: [Patches] [ python-Patches-1407135 ] anonymous mmap Message-ID: Patches item #1407135, was opened at 2006-01-16 09:44 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: anonymous mmap Initial Comment: make mmap.mmap(-1, size) map anonymous memory on both windows and unix-like systems. If this goes in, I'll also write some documentation. here's some more reasoning: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=1402308&group_id=5470 ---------------------------------------------------------------------- >Comment By: Ralf Schmitt (titty) Date: 2006-01-17 09:59 Message: Logged In: YES user_id=17929 Well, seems like one would also need some special handling for systems only defining one of MAP_ANON/MAP_ANONYOUS: http://www.winehq.org/hypermail/wine-devel/2004/12/0064.html ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 09:48 Message: Logged In: YES user_id=17929 quoting ubuntu's mmap man page: MAP_ANONYMOUS The mapping is not backed by any file; the fd and offset arguments are ignored. This flag in conjunction with MAP_SHARED is implemented since Linux 2.4. MAP_ANON Alias for MAP_ANONYMOUS. Deprecated. --- On a glibc 2.1 system (once installed with a 2.2 kernel, now running a 2.4 one) the manpage doesn't even mention MAP_ANON(YMOUS). The patch in it's current form will just fail on system's not defining MAP_ANON (i.e. mmap will fail and an exception will be raised). However, according to Stevens 'Advanced Programming in the Unix Environment', chapter 14.9, there are two ways to mmap anonymous memory. The first one works by using MAP_ANON (4.3+BSD), and the second one works by opening /dev/zero and passing that as a filedescriptor to mmap (SVR4). So, I guess all BSD's and newer Linux Systems would work with this version. Anyway I can send another patch handling that case if you like? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 06:22 Message: Logged In: YES user_id=33168 In addition to docs, tests will also be necessary before committing. What if fd == -1 and MAP_ANON is not defined? It seems the state could be inconsistent. Shouldn't an exception be raised in this case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 From noreply at sourceforge.net Tue Jan 17 11:34:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 02:34:37 -0800 Subject: [Patches] [ python-Patches-1407135 ] anonymous mmap Message-ID: Patches item #1407135, was opened at 2006-01-16 09:44 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: anonymous mmap Initial Comment: make mmap.mmap(-1, size) map anonymous memory on both windows and unix-like systems. If this goes in, I'll also write some documentation. here's some more reasoning: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=1402308&group_id=5470 ---------------------------------------------------------------------- >Comment By: Ralf Schmitt (titty) Date: 2006-01-17 11:34 Message: Logged In: YES user_id=17929 This patch tries to mmap via /dev/zero if neither MAP_ANON nor MAP_ANONYMOUS is defined and handles the case where only MAP_ANONYMOUS is defined. I've added some tests, and found that test_mmap executed mmap(-1, ...), which probably would have crashed the tests running on OS X. Aren't the tests being run before release on all major platforms? ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 09:59 Message: Logged In: YES user_id=17929 Well, seems like one would also need some special handling for systems only defining one of MAP_ANON/MAP_ANONYOUS: http://www.winehq.org/hypermail/wine-devel/2004/12/0064.html ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 09:48 Message: Logged In: YES user_id=17929 quoting ubuntu's mmap man page: MAP_ANONYMOUS The mapping is not backed by any file; the fd and offset arguments are ignored. This flag in conjunction with MAP_SHARED is implemented since Linux 2.4. MAP_ANON Alias for MAP_ANONYMOUS. Deprecated. --- On a glibc 2.1 system (once installed with a 2.2 kernel, now running a 2.4 one) the manpage doesn't even mention MAP_ANON(YMOUS). The patch in it's current form will just fail on system's not defining MAP_ANON (i.e. mmap will fail and an exception will be raised). However, according to Stevens 'Advanced Programming in the Unix Environment', chapter 14.9, there are two ways to mmap anonymous memory. The first one works by using MAP_ANON (4.3+BSD), and the second one works by opening /dev/zero and passing that as a filedescriptor to mmap (SVR4). So, I guess all BSD's and newer Linux Systems would work with this version. Anyway I can send another patch handling that case if you like? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 06:22 Message: Logged In: YES user_id=33168 In addition to docs, tests will also be necessary before committing. What if fd == -1 and MAP_ANON is not defined? It seems the state could be inconsistent. Shouldn't an exception be raised in this case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 From noreply at sourceforge.net Tue Jan 17 16:17:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 07:17:12 -0800 Subject: [Patches] [ python-Patches-1244861 ] Enable os.startfile and webbrowser.WindowsDefault on Cygwin Message-ID: Patches item #1244861, was opened at 2005-07-25 23:38 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Raymond Hettinger (rhettinger) Summary: Enable os.startfile and webbrowser.WindowsDefault on Cygwin Initial Comment: This patch enables os.startfile() on Cygwin, converting Cygwin POSIX paths to Windows paths unless they look like URLs, and calling ShellExecute() on the result. It also enables the webbrowser.WindowsDefault class, which uses os.startfile(). It has to make WindowsError and the PyErr*Windows* functions available as well because win32_startfile() might call them. ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2006-01-17 15:17 Message: Logged In: YES user_id=987664 Raymond, did you ever have a chance to look at this patch? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-09-15 13:04 Message: Logged In: YES user_id=1188172 Raymond, can you look at this one? It seems to be okay, but I can't test it. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-09-15 12:44 Message: Logged In: YES user_id=987664 Let's try this again... ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-09-15 12:39 Message: Logged In: YES user_id=1188172 I still see no patch... are you sure you check the right box? ;-) ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-09-15 10:49 Message: Logged In: YES user_id=987664 Argh, sorry about that. Thanks Reinhold; here's the patch. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-09-15 07:20 Message: Logged In: YES user_id=1188172 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 From noreply at sourceforge.net Tue Jan 17 23:37:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 14:37:46 -0800 Subject: [Patches] [ python-Patches-988761 ] re.split emptyok flag (fix for #852532) Message-ID: Patches item #988761, was opened at 2004-07-10 22:25 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Fredrik Lundh (effbot) Summary: re.split emptyok flag (fix for #852532) Initial Comment: This patch addresses bug #852532. The underlying problem is that re.split ignores any match it makes that has length zero, which blocks a number of useful possibilities. The attached patch implements a flag 'emptyok', which if set to True, causes re.split to allow zero length matches. My preference would be to just change the behavior of re.split, rather than adding this flag. The old behavior isn't documented (though a couple of cases in test_re.py do depend on it). As a practical matter, though, I realize that there may be some code out there relying on this undocumented behavior. And I'm hoping that this useful feature can be added quickly. Perhaps this new behavior could be made the default in a future version of Python. (Linux 2.6.3 i686) ---------------------------------------------------------------------- >Comment By: Mike Coleman (mkc) Date: 2006-01-17 16:37 Message: Logged In: YES user_id=555 I think I still agree with my original answer on this (see http://mail.python.org/pipermail/python-dev/2004-August/047321.html). I'm completely worn down on this, though, so I'd happily take any of these options as an improvement over the present situation. ---------------------------------------------------------------------- Comment By: Filip Salomonsson (filips) Date: 2006-01-16 15:56 Message: Logged In: YES user_id=308203 I agree completely that splitting on non-zero matches should be supported - and that the default behavior should change at some point - but I don't think this patch quite covers it. Taking an example from the dev-python thread back in August of 2004 (http://mail.python.org/pipermail/python-dev/2004-August/047272.html): >>> re.split('x*', 'abxxxcdefxxx', emptyok=True) ['', 'a', 'b', '', 'c', 'd', 'e', 'f', '', ''] To me, this means there's an empty string, beginning and ending in pos 0, followed by a zero-width divider also beginning and ending in the same position, followed by an 'a', etc. That seems awkward to me. I think a more intuitive result would be (I'm omitting the emptyok argument in the following examples): >>> re.split('x*', 'abxxxcdefxxx') ['a', 'b', 'c', 'd', 'e', 'f', ''] That is, empty matches cause a split when they are not adjacent to a non-empty match and not at the beginning or the end of the string. Grouping parentheses would, of course, reveal the empty-string boundaries: >>> re.split('(x*)', 'abxxxcdefxxx') ['', 'a', '', 'b', 'xxx', '', 'c', '', 'd', '', 'e', '', 'f', 'xxx', ''] Using the same approach, these results would also seem perfectly reasonable to me: >>> re.split('(?m)$', 'foo\nbar\nbaz') ['foo', '\nbar', '\nbaz'] >>> re.split('(?m)^', 'foo\nbar\nbaz') ['foo\n', 'bar\n', 'baz'] Splitting a one-character string should be possible only if the pattern matches that character: >>> re.split('\w*', 'a') ['', ''] >>> re.split('\d*', 'a') ['a'] ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2005-12-09 11:04 Message: Logged In: YES user_id=555 This patch seems to have been stalled now for over a year. Could it be applied? Or, alternatively, could someone provide some sort of reason why it shouldn't be? Thanks. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 17:53 Message: Logged In: YES user_id=80475 Fred, what do you think of the proposal. Are the backwards compatability issues worth it? ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-09-03 15:15 Message: Logged In: YES user_id=555 Apparently this patch is stalled, but I'd like to get it in, in some form, for 2.4. The only question, as far as I know, is whether empty matches following non-empty matches "count" or not (they do in the original patch). If I make a patch with the "doesn't count" behavior, could we apply that right away? I'd rather get either behavior in for 2.4 than wait for 2.5... ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-07-28 11:23 Message: Logged In: YES user_id=555 I picked through CVS, python-dev and google and came up with this. The current behavior was present way back in the earliest regsub.py in CVS (dated Sep 1992); subsequent implementation seem to be mirroring this behavior. The CVS comment back in 1992 described split as modeled on nawk. A check of nawk(1) confirms that nawk only splits on non-null matches. Perl (circa 5.6) on the other hand, appears to split the way this patch does (though I wasn't aware of that when I wrote the patch) so that might argue in the other direction. I would note, too, that re.findall and re.finditer tend in this direction ("Empty matches are included in the result unless they touch the beginning of another match."). The python-dev archive doesn't seem to go back far enough to be relevant and I'm not sure how to search it. General googling (python "re.split" empty match) found a few hits. Probably the most relevant is Tim Peters saying "Python won't change here (IMO)" and giving the example that he also gives in a comment to bug #852532 (which this patch addresses). He also wonders in his comment about the possibility of a "design constraint", but I think this patch addresses that concern. As far as I can tell, the current behavior was a design decision made over 10 years ago, between two alternatives that probably didn't matter much at the time. Skipping empty matches probably seemed harmless before lookahead/lookbehind assertions. Now, though, the current behavior seems like a significant hindrance. Furthermore, it ought to be pretty trivial to modify any existing patterns to get the old behavior, should that be desired (e.g., use 'x+' instead of 'x*'). (I didn't notice that re.findall doc when I originally wrote this patch. Perhaps the doc in the patch should be slightly modified to help emphasize the similarity between how re.findall and re.split handle empty matches.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-27 09:08 Message: Logged In: YES user_id=11375 Overall I like the patch and wouldn't mind seeing the change become the default behaviour. However, I'm nervous about possibly not understanding the reason the prohibition on zero-length matches was added in the first place. Can you please do some research in the CVS logs and python-dev archives to figure out why the limitation was implemented in the first place? ---------------------------------------------------------------------- Comment By: Chris King (colander_man) Date: 2004-07-21 07:46 Message: Logged In: YES user_id=573252 Practical example where the current behaviour produces undesirable results (splitting on character transitions): >>> import re >>> re.split(r'(?<=[A-Z])(?=[^a-z])','SOMEstring') ['SOMEstring'] # desired is ['SOME','string'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 From noreply at sourceforge.net Tue Jan 17 23:52:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 14:52:44 -0800 Subject: [Patches] [ python-Patches-1309579 ] A wait4() implementation Message-ID: Patches item #1309579, was opened at 2005-09-30 10:32 Message generated for change (Comment added) made by cjschr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: A wait4() implementation Initial Comment: Implementation of a BSD-style wait4() function, which is similar to waitpid, but it also returns resource usage information about the child process. wait4(pid, options) -> (pid, status, rusage) Chad ---------------------------------------------------------------------- >Comment By: chads (cjschr) Date: 2006-01-17 16:52 Message: Logged In: YES user_id=1093928 Took a different approach with implementation. Also includes wait3 implementation. LMK how it looks. Thanks. Chad ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 16:56 Message: Logged In: YES user_id=33168 Comments from author received in mail: It is a duplicate of my original post, but it was diff'ed against the latest CVS tree. The usage example is for those who haven't had experience with wait4 before, hence the name. It's an FYI, nothing more. I'll also update the documentation accordingly. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 22:16 Message: Logged In: YES user_id=33168 Chad, I'm starting to look at this now, but it seems to be a duplicate of your original patch # 1000267. Can this be closed as a duplicate? I don't know if the attachments are the same. It would be easier to have all the changes in a single file. Since you are adding a new file, you will need to use -N option to cvs diff. Something like this: cvs diff -Nu ... (you can list the specific files that changed if necessary). >From what I looked at so far, there were a couple of things I didn't like. Though it looks like you addressed many (perhaps all) of the previous comments. I don't like the code in resourcemodule.h. I would prefer a public API in resourcemodule that posixmodule can call. If you think that no other modules outside python should call this, you can prefix the name with _, ie _PyResourceModule_...(). There are some un-prefixed names in resourcemodule.h. I think these may all go away if you move the code into the .c file. I would prefer to not have resourcemodule_h_author & resourcemodule_h_rcsid. The comment with your name and email is fine. I didn't look at the test or usage example. What should be done with the usage example? In the doc, could you remove the ", ?" for availability. We can leave it as Unix for now. If we find out definitive info about other platforms (Windows, Mac), we can add that later. Please add a \versionadded{2.5} at the end of the new doc (before the end). That's all my comments. This looks close to being ready. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 From noreply at sourceforge.net Tue Jan 17 23:55:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 14:55:45 -0800 Subject: [Patches] [ python-Patches-1408584 ] Corrupt Berkeley DB using Modify bsddb.dbtables Message-ID: Patches item #1408584, was opened at 2006-01-17 14:55 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=1408584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: jross (j_ross) Assigned to: Nobody/Anonymous (nobody) Summary: Corrupt Berkeley DB using Modify bsddb.dbtables Initial Comment: OS: Windows 2000/Windows XP/Debian-based Linux w/2.6.10 Kernel When the Modify function from the dbtables.py module is called on Berkeley DB it corrupts the file showing an error caused by Line 445 of dbtables.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 From noreply at sourceforge.net Wed Jan 18 04:21:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 19:21:12 -0800 Subject: [Patches] [ python-Patches-1408710 ] use computed goto's in ceval loop Message-ID: Patches item #1408710, was opened at 2006-01-18 03:21 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=1408710&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Simon David Burton (simonb1) Assigned to: Nobody/Anonymous (nobody) Summary: use computed goto's in ceval loop Initial Comment: An experiment where the big switch in ceval.c is replaced with a computed goto construct. Uses #define's to make it optional. Inspired by Mono's MINT interpreter code, and Neil Norwitz's attempt to use a function pointer table: http://sourceforge.net/tracker/index.php?func=detail&aid=693638&group_id=5470&atid=305470 Result: about 1% slower on the pystone benchmark. Also it seems to have broken the interpreter; at least one test fails (test_StringIO). Not sure if the other switch speedup hacks (eg. PREDICT(op)) conflict at all with this patch (ie. make it slower than it could be). Mono actually uses a much larger opcode set, with 2-byte opcodes, that includes type info in each opcode. This means that the actual case statements are much faster. My initial thought about using computed goto's (January 2003) was that the python opcode cases were much fatter than mono's (often involving a function call) and that the overhead of branching on the opcode would be insignificant. It seems that this is true indeed. Patch is for python revision 42025. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408710&group_id=5470 From noreply at sourceforge.net Wed Jan 18 07:14:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 22:14:28 -0800 Subject: [Patches] [ python-Patches-1408584 ] Corrupt Berkeley DB using Modify bsddb.dbtables Message-ID: Patches item #1408584, was opened at 2006-01-17 14:55 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: jross (j_ross) Assigned to: Nobody/Anonymous (nobody) Summary: Corrupt Berkeley DB using Modify bsddb.dbtables Initial Comment: OS: Windows 2000/Windows XP/Debian-based Linux w/2.6.10 Kernel When the Modify function from the dbtables.py module is called on Berkeley DB it corrupts the file showing an error caused by Line 445 of dbtables.py. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 22:14 Message: Logged In: YES user_id=33168 Can you create a test case for this? What is the trigger? Just calling the function/method? Do you know if this affects Python 2.4 and HEAD? What version of Berkeley DB? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 From noreply at sourceforge.net Wed Jan 18 07:24:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 22:24:57 -0800 Subject: [Patches] [ python-Patches-1407135 ] anonymous mmap Message-ID: Patches item #1407135, was opened at 2006-01-16 00:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: anonymous mmap Initial Comment: make mmap.mmap(-1, size) map anonymous memory on both windows and unix-like systems. If this goes in, I'll also write some documentation. here's some more reasoning: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=1402308&group_id=5470 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 22:24 Message: Logged In: YES user_id=33168 To answer your question: > Aren't the tests being run before release on all major platforms? It's difficult to answer. I think generally the answer is yes, but it all depends on volunteers. We are currently running tests on every checkin: http://www.python.org/dev/buildbot/ for both HEAD and 2.4 branch. BuildBot is a relatively recent addition though. On OS X 10.3, we aren't having a problem with mmap(). Various developers I know use OS X, not sure which versions of OS X though. -- General comments about the patch: For any solution, we should strive to make it available if possible (with reason) on all platforms. We should attempt to have all versions of Python behave similarly. (I'm not trying to imply you aren't working in this direction, it seems like you are.) I only notice one patch attached. Have you been deleting the others or did you forget to check the litle box? ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 02:34 Message: Logged In: YES user_id=17929 This patch tries to mmap via /dev/zero if neither MAP_ANON nor MAP_ANONYMOUS is defined and handles the case where only MAP_ANONYMOUS is defined. I've added some tests, and found that test_mmap executed mmap(-1, ...), which probably would have crashed the tests running on OS X. Aren't the tests being run before release on all major platforms? ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 00:59 Message: Logged In: YES user_id=17929 Well, seems like one would also need some special handling for systems only defining one of MAP_ANON/MAP_ANONYOUS: http://www.winehq.org/hypermail/wine-devel/2004/12/0064.html ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 00:48 Message: Logged In: YES user_id=17929 quoting ubuntu's mmap man page: MAP_ANONYMOUS The mapping is not backed by any file; the fd and offset arguments are ignored. This flag in conjunction with MAP_SHARED is implemented since Linux 2.4. MAP_ANON Alias for MAP_ANONYMOUS. Deprecated. --- On a glibc 2.1 system (once installed with a 2.2 kernel, now running a 2.4 one) the manpage doesn't even mention MAP_ANON(YMOUS). The patch in it's current form will just fail on system's not defining MAP_ANON (i.e. mmap will fail and an exception will be raised). However, according to Stevens 'Advanced Programming in the Unix Environment', chapter 14.9, there are two ways to mmap anonymous memory. The first one works by using MAP_ANON (4.3+BSD), and the second one works by opening /dev/zero and passing that as a filedescriptor to mmap (SVR4). So, I guess all BSD's and newer Linux Systems would work with this version. Anyway I can send another patch handling that case if you like? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-16 21:22 Message: Logged In: YES user_id=33168 In addition to docs, tests will also be necessary before committing. What if fd == -1 and MAP_ANON is not defined? It seems the state could be inconsistent. Shouldn't an exception be raised in this case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 From noreply at sourceforge.net Wed Jan 18 10:16:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 01:16:41 -0800 Subject: [Patches] [ python-Patches-1407135 ] anonymous mmap Message-ID: Patches item #1407135, was opened at 2006-01-16 09:44 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: anonymous mmap Initial Comment: make mmap.mmap(-1, size) map anonymous memory on both windows and unix-like systems. If this goes in, I'll also write some documentation. here's some more reasoning: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=1402308&group_id=5470 ---------------------------------------------------------------------- >Comment By: Ralf Schmitt (titty) Date: 2006-01-18 10:16 Message: Logged In: YES user_id=17929 Thanks for the insight. And yes, I forgot to check that little box. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-18 07:24 Message: Logged In: YES user_id=33168 To answer your question: > Aren't the tests being run before release on all major platforms? It's difficult to answer. I think generally the answer is yes, but it all depends on volunteers. We are currently running tests on every checkin: http://www.python.org/dev/buildbot/ for both HEAD and 2.4 branch. BuildBot is a relatively recent addition though. On OS X 10.3, we aren't having a problem with mmap(). Various developers I know use OS X, not sure which versions of OS X though. -- General comments about the patch: For any solution, we should strive to make it available if possible (with reason) on all platforms. We should attempt to have all versions of Python behave similarly. (I'm not trying to imply you aren't working in this direction, it seems like you are.) I only notice one patch attached. Have you been deleting the others or did you forget to check the litle box? ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 11:34 Message: Logged In: YES user_id=17929 This patch tries to mmap via /dev/zero if neither MAP_ANON nor MAP_ANONYMOUS is defined and handles the case where only MAP_ANONYMOUS is defined. I've added some tests, and found that test_mmap executed mmap(-1, ...), which probably would have crashed the tests running on OS X. Aren't the tests being run before release on all major platforms? ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 09:59 Message: Logged In: YES user_id=17929 Well, seems like one would also need some special handling for systems only defining one of MAP_ANON/MAP_ANONYOUS: http://www.winehq.org/hypermail/wine-devel/2004/12/0064.html ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 09:48 Message: Logged In: YES user_id=17929 quoting ubuntu's mmap man page: MAP_ANONYMOUS The mapping is not backed by any file; the fd and offset arguments are ignored. This flag in conjunction with MAP_SHARED is implemented since Linux 2.4. MAP_ANON Alias for MAP_ANONYMOUS. Deprecated. --- On a glibc 2.1 system (once installed with a 2.2 kernel, now running a 2.4 one) the manpage doesn't even mention MAP_ANON(YMOUS). The patch in it's current form will just fail on system's not defining MAP_ANON (i.e. mmap will fail and an exception will be raised). However, according to Stevens 'Advanced Programming in the Unix Environment', chapter 14.9, there are two ways to mmap anonymous memory. The first one works by using MAP_ANON (4.3+BSD), and the second one works by opening /dev/zero and passing that as a filedescriptor to mmap (SVR4). So, I guess all BSD's and newer Linux Systems would work with this version. Anyway I can send another patch handling that case if you like? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 06:22 Message: Logged In: YES user_id=33168 In addition to docs, tests will also be necessary before committing. What if fd == -1 and MAP_ANON is not defined? It seems the state could be inconsistent. Shouldn't an exception be raised in this case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 From noreply at sourceforge.net Thu Jan 19 07:58:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 22:58:14 -0800 Subject: [Patches] [ python-Patches-1309579 ] A wait4() implementation Message-ID: Patches item #1309579, was opened at 2005-09-30 08:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: A wait4() implementation Initial Comment: Implementation of a BSD-style wait4() function, which is similar to waitpid, but it also returns resource usage information about the child process. wait4(pid, options) -> (pid, status, rusage) Chad ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-18 22:58 Message: Logged In: YES user_id=33168 I looked over the patch. It looks pretty good. Can your provide doc too? If you can't do latex, just text will do and I'll convert. Doc/lib/libos.tex ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2006-01-17 14:52 Message: Logged In: YES user_id=1093928 Took a different approach with implementation. Also includes wait3 implementation. LMK how it looks. Thanks. Chad ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 14:56 Message: Logged In: YES user_id=33168 Comments from author received in mail: It is a duplicate of my original post, but it was diff'ed against the latest CVS tree. The usage example is for those who haven't had experience with wait4 before, hence the name. It's an FYI, nothing more. I'll also update the documentation accordingly. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 20:16 Message: Logged In: YES user_id=33168 Chad, I'm starting to look at this now, but it seems to be a duplicate of your original patch # 1000267. Can this be closed as a duplicate? I don't know if the attachments are the same. It would be easier to have all the changes in a single file. Since you are adding a new file, you will need to use -N option to cvs diff. Something like this: cvs diff -Nu ... (you can list the specific files that changed if necessary). >From what I looked at so far, there were a couple of things I didn't like. Though it looks like you addressed many (perhaps all) of the previous comments. I don't like the code in resourcemodule.h. I would prefer a public API in resourcemodule that posixmodule can call. If you think that no other modules outside python should call this, you can prefix the name with _, ie _PyResourceModule_...(). There are some un-prefixed names in resourcemodule.h. I think these may all go away if you move the code into the .c file. I would prefer to not have resourcemodule_h_author & resourcemodule_h_rcsid. The comment with your name and email is fine. I didn't look at the test or usage example. What should be done with the usage example? In the doc, could you remove the ", ?" for availability. We can leave it as Unix for now. If we find out definitive info about other platforms (Windows, Mac), we can add that later. Please add a \versionadded{2.5} at the end of the new doc (before the end). That's all my comments. This looks close to being ready. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 From noreply at sourceforge.net Thu Jan 19 14:47:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Jan 2006 05:47:49 -0800 Subject: [Patches] [ python-Patches-1309579 ] A wait4() implementation Message-ID: Patches item #1309579, was opened at 2005-09-30 10:32 Message generated for change (Comment added) made by cjschr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: A wait4() implementation Initial Comment: Implementation of a BSD-style wait4() function, which is similar to waitpid, but it also returns resource usage information about the child process. wait4(pid, options) -> (pid, status, rusage) Chad ---------------------------------------------------------------------- >Comment By: chads (cjschr) Date: 2006-01-19 07:47 Message: Logged In: YES user_id=1093928 Neil Check the diff. Doc updates are already there. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-19 00:58 Message: Logged In: YES user_id=33168 I looked over the patch. It looks pretty good. Can your provide doc too? If you can't do latex, just text will do and I'll convert. Doc/lib/libos.tex ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2006-01-17 16:52 Message: Logged In: YES user_id=1093928 Took a different approach with implementation. Also includes wait3 implementation. LMK how it looks. Thanks. Chad ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 16:56 Message: Logged In: YES user_id=33168 Comments from author received in mail: It is a duplicate of my original post, but it was diff'ed against the latest CVS tree. The usage example is for those who haven't had experience with wait4 before, hence the name. It's an FYI, nothing more. I'll also update the documentation accordingly. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 22:16 Message: Logged In: YES user_id=33168 Chad, I'm starting to look at this now, but it seems to be a duplicate of your original patch # 1000267. Can this be closed as a duplicate? I don't know if the attachments are the same. It would be easier to have all the changes in a single file. Since you are adding a new file, you will need to use -N option to cvs diff. Something like this: cvs diff -Nu ... (you can list the specific files that changed if necessary). >From what I looked at so far, there were a couple of things I didn't like. Though it looks like you addressed many (perhaps all) of the previous comments. I don't like the code in resourcemodule.h. I would prefer a public API in resourcemodule that posixmodule can call. If you think that no other modules outside python should call this, you can prefix the name with _, ie _PyResourceModule_...(). There are some un-prefixed names in resourcemodule.h. I think these may all go away if you move the code into the .c file. I would prefer to not have resourcemodule_h_author & resourcemodule_h_rcsid. The comment with your name and email is fine. I didn't look at the test or usage example. What should be done with the usage example? In the doc, could you remove the ", ?" for availability. We can leave it as Unix for now. If we find out definitive info about other platforms (Windows, Mac), we can add that later. Please add a \versionadded{2.5} at the end of the new doc (before the end). That's all my comments. This looks close to being ready. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 From noreply at sourceforge.net Thu Jan 19 19:11:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Jan 2006 10:11:37 -0800 Subject: [Patches] [ python-Patches-1408584 ] Corrupt Berkeley DB using Modify bsddb.dbtables Message-ID: Patches item #1408584, was opened at 2006-01-17 14:55 Message generated for change (Comment added) made by j_ross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: jross (j_ross) Assigned to: Nobody/Anonymous (nobody) Summary: Corrupt Berkeley DB using Modify bsddb.dbtables Initial Comment: OS: Windows 2000/Windows XP/Debian-based Linux w/2.6.10 Kernel When the Modify function from the dbtables.py module is called on Berkeley DB it corrupts the file showing an error caused by Line 445 of dbtables.py. ---------------------------------------------------------------------- >Comment By: jross (j_ross) Date: 2006-01-19 10:11 Message: Logged In: YES user_id=1429720 I'm new to Python so this may be the problem, does the dbtables.Modify function require a function in the mappings. i.e. tdb.Modify('mytable', conditions= {'ID':dbtables.ExactCond('1')}, mappings={'ID':FUNCTION}) where the function returns the new value? (not mappings= {'ID':'newvalue'}) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 22:14 Message: Logged In: YES user_id=33168 Can you create a test case for this? What is the trigger? Just calling the function/method? Do you know if this affects Python 2.4 and HEAD? What version of Berkeley DB? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 From noreply at sourceforge.net Thu Jan 19 19:50:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Jan 2006 10:50:25 -0800 Subject: [Patches] [ python-Patches-1410119 ] Add foldr and foldl to functional module Message-ID: Patches item #1410119, was opened at 2006-01-19 13:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add foldr and foldl to functional module Initial Comment: This patch adds foldr and foldl functions to the functional module. In addition, it updates libfunctional.tex and test/test_functional to include documentation and tests, respectively, for the new code. The code has been checked for reference leaks using --with-pydebug. The patch is against svn revision 42097. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 From noreply at sourceforge.net Thu Jan 19 23:35:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Jan 2006 14:35:38 -0800 Subject: [Patches] [ python-Patches-1408584 ] Corrupt Berkeley DB using Modify bsddb.dbtables Message-ID: Patches item #1408584, was opened at 2006-01-17 17:55 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: jross (j_ross) Assigned to: Nobody/Anonymous (nobody) Summary: Corrupt Berkeley DB using Modify bsddb.dbtables Initial Comment: OS: Windows 2000/Windows XP/Debian-based Linux w/2.6.10 Kernel When the Modify function from the dbtables.py module is called on Berkeley DB it corrupts the file showing an error caused by Line 445 of dbtables.py. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-19 17:35 Message: Logged In: YES user_id=764593 Correct, the values in the dictionaries should be callables (usually a function) which take the old value and return the new. That said, the test case would still be useful, because (1) calling a string should raise a TypeError (2) making a mistake should not corrupt the database. Perhaps the first except clause (which triggers a rollback) needs to be a bare except? I'm guess the same is true of some of the other abort() lines... ---------------------------------------------------------------------- Comment By: jross (j_ross) Date: 2006-01-19 13:11 Message: Logged In: YES user_id=1429720 I'm new to Python so this may be the problem, does the dbtables.Modify function require a function in the mappings. i.e. tdb.Modify('mytable', conditions= {'ID':dbtables.ExactCond('1')}, mappings={'ID':FUNCTION}) where the function returns the new value? (not mappings= {'ID':'newvalue'}) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-18 01:14 Message: Logged In: YES user_id=33168 Can you create a test case for this? What is the trigger? Just calling the function/method? Do you know if this affects Python 2.4 and HEAD? What version of Berkeley DB? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 From noreply at sourceforge.net Fri Jan 20 00:07:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Jan 2006 15:07:08 -0800 Subject: [Patches] [ python-Patches-1408584 ] Corrupt Berkeley DB using Modify bsddb.dbtables Message-ID: Patches item #1408584, was opened at 2006-01-17 14:55 Message generated for change (Comment added) made by j_ross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: jross (j_ross) Assigned to: Nobody/Anonymous (nobody) Summary: Corrupt Berkeley DB using Modify bsddb.dbtables Initial Comment: OS: Windows 2000/Windows XP/Debian-based Linux w/2.6.10 Kernel When the Modify function from the dbtables.py module is called on Berkeley DB it corrupts the file showing an error caused by Line 445 of dbtables.py. ---------------------------------------------------------------------- >Comment By: jross (j_ross) Date: 2006-01-19 15:07 Message: Logged In: YES user_id=1429720 Very nice .. yes using a bare exception causes the expected TypeError exception. I tried this in Python 2.4 and without any changes it correctly raises TypeError. I checked the differences between the 2.3 dbtables and 2.4 and there are no significant changes (i.e. the Modify catches the same exceptions) so it's got to be somewhere else. I've uploaded a simple test case that creates a database, does an Insert and then attempts the Modify with a string which corrupts the DB in Python 2.3. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-19 14:35 Message: Logged In: YES user_id=764593 Correct, the values in the dictionaries should be callables (usually a function) which take the old value and return the new. That said, the test case would still be useful, because (1) calling a string should raise a TypeError (2) making a mistake should not corrupt the database. Perhaps the first except clause (which triggers a rollback) needs to be a bare except? I'm guess the same is true of some of the other abort() lines... ---------------------------------------------------------------------- Comment By: jross (j_ross) Date: 2006-01-19 10:11 Message: Logged In: YES user_id=1429720 I'm new to Python so this may be the problem, does the dbtables.Modify function require a function in the mappings. i.e. tdb.Modify('mytable', conditions= {'ID':dbtables.ExactCond('1')}, mappings={'ID':FUNCTION}) where the function returns the new value? (not mappings= {'ID':'newvalue'}) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 22:14 Message: Logged In: YES user_id=33168 Can you create a test case for this? What is the trigger? Just calling the function/method? Do you know if this affects Python 2.4 and HEAD? What version of Berkeley DB? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 From noreply at sourceforge.net Fri Jan 20 10:09:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 01:09:01 -0800 Subject: [Patches] [ python-Patches-1406159 ] Patch for #1371247 Message-ID: Patches item #1406159, was opened at 2006-01-14 23:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1406159&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1371247 Initial Comment: More complete list of windows_locale as suggested in #1371247 ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 10:09 Message: Logged In: YES user_id=1188172 I updated the locale table, but from MSDN information that seems to be more accurate. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-14 23:49 Message: Logged In: YES user_id=174455 Fix the hex for spanish ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1406159&group_id=5470 From noreply at sourceforge.net Fri Jan 20 10:16:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 01:16:24 -0800 Subject: [Patches] [ python-Patches-1407021 ] Doc patch for bug #1396471 Message-ID: Patches item #1407021, was opened at 2006-01-16 04:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407021&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Doc patch for bug #1396471 Initial Comment: Document a bug and work-around in the ftell c-library call on windows when opening files with unix-style line-endings. Also fixes a typo that texcheck.py warned about. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 10:16 Message: Logged In: YES user_id=1188172 Thanks for the patch, I added a note to the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407021&group_id=5470 From noreply at sourceforge.net Fri Jan 20 10:35:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 01:35:24 -0800 Subject: [Patches] [ python-Patches-1402224 ] Need warning that `dl` module can cause segfaults/crashes Message-ID: Patches item #1402224, was opened at 2006-01-11 00:20 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402224&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: Need warning that `dl` module can cause segfaults/crashes Initial Comment: The `dl` module can cause segfaults/crashes if used incorrectly. I recommend the following (or similar) wording be put at the top of the module documentation (preferable in red ;) The `dl` module bypasses the Python type system and error handling. If used incorrectly it may cause segmentation faults, crashes or other incorrect behaviour. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 10:35 Message: Logged In: YES user_id=1188172 Added a warning (with \warning{}) in revision 42104, 42105 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402224&group_id=5470 From noreply at sourceforge.net Fri Jan 20 12:12:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 03:12:47 -0800 Subject: [Patches] [ python-Patches-1410680 ] Add 'surgical editing' to ConfigParser Message-ID: Patches item #1410680, was opened at 2006-01-21 00:12 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=1410680&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'surgical editing' to ConfigParser Initial Comment: See also: [ 1399309 ] ConfigParser to save with order [ 1371075 ] ConfigParser to accept a custom dict to allow ordering The attached patch adds a new method, update_file, to RawConfigParser. This method is similar to the existing write method, but preserves blank lines, comments, and ordering, as requested many times on python-dev and python-list. These are the three requirements that Guido specified in January 2005. IMO the attached patch is better than 1399309 because it includes all the functionality (passing a pointer to an empty file results in a sorted write() output), but is completely backwards compatible as write() is unchanged. The addition of preserving comments is also essential for many applications. IMO the attached patch is better than 1371075 because the latter really requires a custom class (e.g. the third party one suggested) in order to be useful. It also doesn't address the issue of preserving comments. The attached patch is essentially a tidied up version of the one included with SpamBayes (in the OptionClass.py module), which is used extensively within SpamBayes (and has been for several years). Also attached are additional unittests for the new method, and a documentation patch. Please let me know if there are recommended changes. This patch does not address any of the additional ConfigParser improvements that have been suggested at various times. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470 From noreply at sourceforge.net Fri Jan 20 13:39:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 04:39:49 -0800 Subject: [Patches] [ python-Patches-1410739 ] Add notes to the manual about `is` and methods Message-ID: Patches item #1410739, was opened at 2006-01-20 07:39 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=1410739&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add notes to the manual about `is` and methods Initial Comment: This patch, made against svn revision 42105, adds caveats to Doc/ref/ref3.tex concerning the use of the `is` operator in conjunction with class- and instance-methods. As I was recently bitten by trying to do the equivalent of """ >>> MyClass.a_class_method is MyClass.a_class_method False >>> """ I thought the manual might benefit from coverage of this as-yet-undocumented area. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410739&group_id=5470 From noreply at sourceforge.net Fri Jan 20 14:07:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 05:07:08 -0800 Subject: [Patches] [ python-Patches-1397711 ] Fix dict and set docs, re: immutability Message-ID: Patches item #1397711, was opened at 2006-01-05 07:28 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dict and set docs, re: immutability Initial Comment: This patch resolves bug #1368768. As mentioned in the bug description, the documentation for sets and dicts incorrectly reports that set members and dict keys must be immutable. This patch corrects this, changing references to immutability to hashability and inserting footnotes describing what is meant by "hashable". The patch is a diff against Doc/lib/libstdtypes.tex from SVN revision 41926. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-01-20 08:07 Message: Logged In: YES user_id=1344176 I've updated the patch to include Jim's version of the footnote. The new version of the patch is against SVN revision 42105. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 17:09 Message: Logged In: YES user_id=764593 Definately an improvement, but it still may not be quite right in the footnote. You don't have to define a __hash__ method; you just need to avoid redefining it (or __eq__) to something that doesn't work. Here is another stab Hashable objects must define or inherit proper \method{__hash__} and \method{__eq__} methods. Most objects do, but some mutable types -- including lists -- redefine equality in such a way that the hash code would not be stable. Instead, their hash functions return -1 to indicate that the object should not be used as a dict key or set member. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397711&group_id=5470 From noreply at sourceforge.net Fri Jan 20 14:30:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 05:30:48 -0800 Subject: [Patches] [ python-Patches-1410783 ] Doc patch for classmethod and staticmethod Message-ID: Patches item #1410783, was opened at 2006-01-20 08: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=1410783&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Doc patch for classmethod and staticmethod Initial Comment: This patch adds links from the descriptions of classmethod() and staticmethod() in Doc/lib/libfuncs.tex to the Python reference manual where class and static methods are discussed in more detail. This patch was made against SVN revision 42105. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410783&group_id=5470 From noreply at sourceforge.net Fri Jan 20 16:11:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 07:11:19 -0800 Subject: [Patches] [ python-Patches-1410680 ] Add 'surgical editing' to ConfigParser Message-ID: Patches item #1410680, was opened at 2006-01-20 06:12 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'surgical editing' to ConfigParser Initial Comment: See also: [ 1399309 ] ConfigParser to save with order [ 1371075 ] ConfigParser to accept a custom dict to allow ordering The attached patch adds a new method, update_file, to RawConfigParser. This method is similar to the existing write method, but preserves blank lines, comments, and ordering, as requested many times on python-dev and python-list. These are the three requirements that Guido specified in January 2005. IMO the attached patch is better than 1399309 because it includes all the functionality (passing a pointer to an empty file results in a sorted write() output), but is completely backwards compatible as write() is unchanged. The addition of preserving comments is also essential for many applications. IMO the attached patch is better than 1371075 because the latter really requires a custom class (e.g. the third party one suggested) in order to be useful. It also doesn't address the issue of preserving comments. The attached patch is essentially a tidied up version of the one included with SpamBayes (in the OptionClass.py module), which is used extensively within SpamBayes (and has been for several years). Also attached are additional unittests for the new method, and a documentation patch. Please let me know if there are recommended changes. This patch does not address any of the additional ConfigParser improvements that have been suggested at various times. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 10:11 Message: Logged In: YES user_id=764593 Wanting to keep the whole thing (except defaultsection) in sorted order will probably be a common use case. It sounds like you can do this by "updating" to an empty file, but it isn't the obvious solution. Could you either add an option to sort the whole thing (so inserts may not be at the end) or an explicit mention in the docstring of how to get this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470 From noreply at sourceforge.net Fri Jan 20 16:32:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 07:32:43 -0800 Subject: [Patches] [ python-Patches-1410119 ] Add foldr and foldl to functional module Message-ID: Patches item #1410119, was opened at 2006-01-19 13:50 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add foldr and foldl to functional module Initial Comment: This patch adds foldr and foldl functions to the functional module. In addition, it updates libfunctional.tex and test/test_functional to include documentation and tests, respectively, for the new code. The code has been checked for reference leaks using --with-pydebug. The patch is against svn revision 42097. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 10:32 Message: Logged In: YES user_id=764593 What does this add over the (currently builtin) reduce? reduce(func, iter, initial) and reduce(func, reversed(iter), initial) Is it just that foldr and foldl are more modern names? If so, it might be better to submit a documentation patch. The functional module should mention reduce, and the reduce documenation (library reference/Built-in Objects/Built-in Functions) could be clarified. Maybe even show how to create foldr and foldl as an example, for reduce so that the terms can be picked up by indexers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 From noreply at sourceforge.net Fri Jan 20 16:44:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 07:44:19 -0800 Subject: [Patches] [ python-Patches-1410119 ] Add foldr and foldl to functional module Message-ID: Patches item #1410119, was opened at 2006-01-19 13:50 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add foldr and foldl to functional module Initial Comment: This patch adds foldr and foldl functions to the functional module. In addition, it updates libfunctional.tex and test/test_functional to include documentation and tests, respectively, for the new code. The code has been checked for reference leaks using --with-pydebug. The patch is against svn revision 42097. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-01-20 10:44 Message: Logged In: YES user_id=1344176 I was under the impression that reduce was going to be removed at some point in the future? In any case, while reduce() is indeed another name for foldl, "reduce(func, reversed(iter), initial)" is not the same thing as foldr(). """ >>> def sub(a, b): return a - b ... >>> foldr(sub, 0, [1, 2, 3]) 2 >>> reduce(sub, [3, 2, 1], 0) -6 """ I'd be happy to update the patch to include references to reduce() in relation to foldl. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 10:32 Message: Logged In: YES user_id=764593 What does this add over the (currently builtin) reduce? reduce(func, iter, initial) and reduce(func, reversed(iter), initial) Is it just that foldr and foldl are more modern names? If so, it might be better to submit a documentation patch. The functional module should mention reduce, and the reduce documenation (library reference/Built-in Objects/Built-in Functions) could be clarified. Maybe even show how to create foldr and foldl as an example, for reduce so that the terms can be picked up by indexers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 From noreply at sourceforge.net Fri Jan 20 17:12:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 08:12:02 -0800 Subject: [Patches] [ python-Patches-1410119 ] Add foldr and foldl to functional module Message-ID: Patches item #1410119, was opened at 2006-01-19 13:50 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add foldr and foldl to functional module Initial Comment: This patch adds foldr and foldl functions to the functional module. In addition, it updates libfunctional.tex and test/test_functional to include documentation and tests, respectively, for the new code. The code has been checked for reference leaks using --with-pydebug. The patch is against svn revision 42097. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 11:12 Message: Logged In: YES user_id=764593 Guido thinks that reduce is too hard to understand, because it is too broad. It still won't be removed before python 3. 0. Python three *might* appear as soon as five years from now, and even then, reduce would probably still be kept in the functional module. (1) Should the functional module also mention other builtins, such as sum, filter, and even min and max? (2) Could you show the step-by-step for foldr? I missed the difference when reading your patch, and it took me a while to figure out how it works even after *this* reminder. At this point, my best guess is that foldr(minus, 0, [1,2,3]) <==> (1 - (2 - (3 - 0))) while foldl(minus, 0, [1,2,3]) <==> (((0 - 1) - 2) - 3) so foldr(f, zero, [x1, x2, x3...xn]) <==> f(x1, f(x2, f(x3, ... f(xn, zero)))) while foldl(f, zero, [x1, x2, x3...xn]) <==> f(f(f(f(f(zero, x1), x2), x3) ... ), xn) but I'm still not *sure* I got it right. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-20 10:44 Message: Logged In: YES user_id=1344176 I was under the impression that reduce was going to be removed at some point in the future? In any case, while reduce() is indeed another name for foldl, "reduce(func, reversed(iter), initial)" is not the same thing as foldr(). """ >>> def sub(a, b): return a - b ... >>> foldr(sub, 0, [1, 2, 3]) 2 >>> reduce(sub, [3, 2, 1], 0) -6 """ I'd be happy to update the patch to include references to reduce() in relation to foldl. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 10:32 Message: Logged In: YES user_id=764593 What does this add over the (currently builtin) reduce? reduce(func, iter, initial) and reduce(func, reversed(iter), initial) Is it just that foldr and foldl are more modern names? If so, it might be better to submit a documentation patch. The functional module should mention reduce, and the reduce documenation (library reference/Built-in Objects/Built-in Functions) could be clarified. Maybe even show how to create foldr and foldl as an example, for reduce so that the terms can be picked up by indexers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 From noreply at sourceforge.net Fri Jan 20 18:31:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 09:31:15 -0800 Subject: [Patches] [ python-Patches-1410119 ] Add foldr and foldl to functional module Message-ID: Patches item #1410119, was opened at 2006-01-19 13:50 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add foldr and foldl to functional module Initial Comment: This patch adds foldr and foldl functions to the functional module. In addition, it updates libfunctional.tex and test/test_functional to include documentation and tests, respectively, for the new code. The code has been checked for reference leaks using --with-pydebug. The patch is against svn revision 42097. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-01-20 12:31 Message: Logged In: YES user_id=1344176 Ah, I had thought reduce was going away sooner than Python 3.0. I've updated the patch to include an expansion of both foldl and foldr (in the __doc__'s and the latex docs). Also included are mentions of max, min, sum and filter, plus a suggestion to go consult any one of the "Functional Programming with Python" tutorials that a quick Google search turns up. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 11:12 Message: Logged In: YES user_id=764593 Guido thinks that reduce is too hard to understand, because it is too broad. It still won't be removed before python 3. 0. Python three *might* appear as soon as five years from now, and even then, reduce would probably still be kept in the functional module. (1) Should the functional module also mention other builtins, such as sum, filter, and even min and max? (2) Could you show the step-by-step for foldr? I missed the difference when reading your patch, and it took me a while to figure out how it works even after *this* reminder. At this point, my best guess is that foldr(minus, 0, [1,2,3]) <==> (1 - (2 - (3 - 0))) while foldl(minus, 0, [1,2,3]) <==> (((0 - 1) - 2) - 3) so foldr(f, zero, [x1, x2, x3...xn]) <==> f(x1, f(x2, f(x3, ... f(xn, zero)))) while foldl(f, zero, [x1, x2, x3...xn]) <==> f(f(f(f(f(zero, x1), x2), x3) ... ), xn) but I'm still not *sure* I got it right. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-20 10:44 Message: Logged In: YES user_id=1344176 I was under the impression that reduce was going to be removed at some point in the future? In any case, while reduce() is indeed another name for foldl, "reduce(func, reversed(iter), initial)" is not the same thing as foldr(). """ >>> def sub(a, b): return a - b ... >>> foldr(sub, 0, [1, 2, 3]) 2 >>> reduce(sub, [3, 2, 1], 0) -6 """ I'd be happy to update the patch to include references to reduce() in relation to foldl. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 10:32 Message: Logged In: YES user_id=764593 What does this add over the (currently builtin) reduce? reduce(func, iter, initial) and reduce(func, reversed(iter), initial) Is it just that foldr and foldl are more modern names? If so, it might be better to submit a documentation patch. The functional module should mention reduce, and the reduce documenation (library reference/Built-in Objects/Built-in Functions) could be clarified. Maybe even show how to create foldr and foldl as an example, for reduce so that the terms can be picked up by indexers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 From noreply at sourceforge.net Fri Jan 20 18:32:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 09:32:31 -0800 Subject: [Patches] [ python-Patches-1379332 ] StreamReader.readline with size reading multiple lines Message-ID: Patches item #1379332, was opened at 2005-12-13 09:54 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379332&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Walter D?rwald (doerwalter) Summary: StreamReader.readline with size reading multiple lines Initial Comment: In Python 2.4.2 and trunk, when StreamReader.readline is used with a size argument, it will eventually truncate some lines, even if every line is less than the size. It works correctly in Python 2.3.5, I haven't tried other versions. >>> f=codecs.getreader('ascii')(StringIO.StringIO("hello\nworld\n")) >>> f.readline(8) u'hello\n' >>> f.readline(8) u'wo' >>> f.readline(8) u'rld\n' I've attached a patch which fixes this and modifies test_codecs.py to test this. I don't know if this is the best way to fix it, but I didn't want to make deeper changes to the caching mechanism, being unfamiliar with this code. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:32 Message: Logged In: YES user_id=1188172 Confirmed here (2.5 HEAD, Linux box). Patch works. Walter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379332&group_id=5470 From noreply at sourceforge.net Fri Jan 20 18:43:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 09:43:31 -0800 Subject: [Patches] [ python-Patches-1410119 ] Add foldr and foldl to functional module Message-ID: Patches item #1410119, was opened at 2006-01-19 19:50 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add foldr and foldl to functional module Initial Comment: This patch adds foldr and foldl functions to the functional module. In addition, it updates libfunctional.tex and test/test_functional to include documentation and tests, respectively, for the new code. The code has been checked for reference leaks using --with-pydebug. The patch is against svn revision 42097. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:43 Message: Logged In: YES user_id=1188172 In any case, having those functions in functional, under their "common" name, is a good thing IMHO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-20 18:31 Message: Logged In: YES user_id=1344176 Ah, I had thought reduce was going away sooner than Python 3.0. I've updated the patch to include an expansion of both foldl and foldr (in the __doc__'s and the latex docs). Also included are mentions of max, min, sum and filter, plus a suggestion to go consult any one of the "Functional Programming with Python" tutorials that a quick Google search turns up. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 17:12 Message: Logged In: YES user_id=764593 Guido thinks that reduce is too hard to understand, because it is too broad. It still won't be removed before python 3. 0. Python three *might* appear as soon as five years from now, and even then, reduce would probably still be kept in the functional module. (1) Should the functional module also mention other builtins, such as sum, filter, and even min and max? (2) Could you show the step-by-step for foldr? I missed the difference when reading your patch, and it took me a while to figure out how it works even after *this* reminder. At this point, my best guess is that foldr(minus, 0, [1,2,3]) <==> (1 - (2 - (3 - 0))) while foldl(minus, 0, [1,2,3]) <==> (((0 - 1) - 2) - 3) so foldr(f, zero, [x1, x2, x3...xn]) <==> f(x1, f(x2, f(x3, ... f(xn, zero)))) while foldl(f, zero, [x1, x2, x3...xn]) <==> f(f(f(f(f(zero, x1), x2), x3) ... ), xn) but I'm still not *sure* I got it right. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-20 16:44 Message: Logged In: YES user_id=1344176 I was under the impression that reduce was going to be removed at some point in the future? In any case, while reduce() is indeed another name for foldl, "reduce(func, reversed(iter), initial)" is not the same thing as foldr(). """ >>> def sub(a, b): return a - b ... >>> foldr(sub, 0, [1, 2, 3]) 2 >>> reduce(sub, [3, 2, 1], 0) -6 """ I'd be happy to update the patch to include references to reduce() in relation to foldl. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 16:32 Message: Logged In: YES user_id=764593 What does this add over the (currently builtin) reduce? reduce(func, iter, initial) and reduce(func, reversed(iter), initial) Is it just that foldr and foldl are more modern names? If so, it might be better to submit a documentation patch. The functional module should mention reduce, and the reduce documenation (library reference/Built-in Objects/Built-in Functions) could be clarified. Maybe even show how to create foldr and foldl as an example, for reduce so that the terms can be picked up by indexers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 From noreply at sourceforge.net Fri Jan 20 18:46:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 09:46:50 -0800 Subject: [Patches] [ python-Patches-1410119 ] Add foldr and foldl to functional module Message-ID: Patches item #1410119, was opened at 2006-01-19 13:50 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add foldr and foldl to functional module Initial Comment: This patch adds foldr and foldl functions to the functional module. In addition, it updates libfunctional.tex and test/test_functional to include documentation and tests, respectively, for the new code. The code has been checked for reference leaks using --with-pydebug. The patch is against svn revision 42097. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 12:46 Message: Logged In: YES user_id=764593 Review: I recommend to apply this patch. It includes test cases and documentation. Cannot break backwards compatibility, as the entire module is new in 2.5. The added functions are reasonably standard for modern functional programming, and they are in the functional module, which would otherwise be fairly sparse. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 12:43 Message: Logged In: YES user_id=1188172 In any case, having those functions in functional, under their "common" name, is a good thing IMHO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-20 12:31 Message: Logged In: YES user_id=1344176 Ah, I had thought reduce was going away sooner than Python 3.0. I've updated the patch to include an expansion of both foldl and foldr (in the __doc__'s and the latex docs). Also included are mentions of max, min, sum and filter, plus a suggestion to go consult any one of the "Functional Programming with Python" tutorials that a quick Google search turns up. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 11:12 Message: Logged In: YES user_id=764593 Guido thinks that reduce is too hard to understand, because it is too broad. It still won't be removed before python 3. 0. Python three *might* appear as soon as five years from now, and even then, reduce would probably still be kept in the functional module. (1) Should the functional module also mention other builtins, such as sum, filter, and even min and max? (2) Could you show the step-by-step for foldr? I missed the difference when reading your patch, and it took me a while to figure out how it works even after *this* reminder. At this point, my best guess is that foldr(minus, 0, [1,2,3]) <==> (1 - (2 - (3 - 0))) while foldl(minus, 0, [1,2,3]) <==> (((0 - 1) - 2) - 3) so foldr(f, zero, [x1, x2, x3...xn]) <==> f(x1, f(x2, f(x3, ... f(xn, zero)))) while foldl(f, zero, [x1, x2, x3...xn]) <==> f(f(f(f(f(zero, x1), x2), x3) ... ), xn) but I'm still not *sure* I got it right. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-20 10:44 Message: Logged In: YES user_id=1344176 I was under the impression that reduce was going to be removed at some point in the future? In any case, while reduce() is indeed another name for foldl, "reduce(func, reversed(iter), initial)" is not the same thing as foldr(). """ >>> def sub(a, b): return a - b ... >>> foldr(sub, 0, [1, 2, 3]) 2 >>> reduce(sub, [3, 2, 1], 0) -6 """ I'd be happy to update the patch to include references to reduce() in relation to foldl. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 10:32 Message: Logged In: YES user_id=764593 What does this add over the (currently builtin) reduce? reduce(func, iter, initial) and reduce(func, reversed(iter), initial) Is it just that foldr and foldl are more modern names? If so, it might be better to submit a documentation patch. The functional module should mention reduce, and the reduce documenation (library reference/Built-in Objects/Built-in Functions) could be clarified. Maybe even show how to create foldr and foldl as an example, for reduce so that the terms can be picked up by indexers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 From noreply at sourceforge.net Fri Jan 20 18:55:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 09:55:16 -0800 Subject: [Patches] [ python-Patches-1388073 ] Make unittest.TestCase easier to subclass Message-ID: Patches item #1388073, was opened at 2005-12-22 15:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388073&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Make unittest.TestCase easier to subclass Initial Comment: While working on a subclass of unittest.TestCase to support TODO-tests, I found a large number of __-prefixed attributes in TestCase. The presence of these attributes (and methods) meant that I had to copy them over to my new subclass to make python happy. The attached patch converts these __-prefixed attributes to _-prefixed attributes, making it much simpler to subclass TestCase. The patch is against unittest.py from SVN revision 41775. Also attached are "before" and "after" versions of my subclass showing the impact of the patch. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:55 Message: Logged In: YES user_id=1188172 Patch looks good and does no harm. Committed revisions 42115, 42116 (2.4). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-12-31 01:50 Message: Logged In: YES user_id=6380 While I haven't reviewed the code, I am +1 on the intent of the patch. Subclassing TestCase (and other unittest classes!) is often a pain due to too much abstraction. (In retrospect, unittest.py is really way too close a translation of the Java junit package. Too bad.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388073&group_id=5470 From noreply at sourceforge.net Fri Jan 20 19:00:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 10:00:24 -0800 Subject: [Patches] [ python-Patches-1410998 ] Remove mention of DOS from os.py's docstring Message-ID: Patches item #1410998, was opened at 2006-01-20 18: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=1410998&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hamish Lawson (hamishlawson) Assigned to: Nobody/Anonymous (nobody) Summary: Remove mention of DOS from os.py's docstring Initial Comment: The os.dospath module is no longer provided, but the docstring for the os module still says that it provides "OS routines for Mac, DOS, NT, or Posix". The attached patch removes mention of DOS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410998&group_id=5470 From noreply at sourceforge.net Fri Jan 20 22:03:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 13:03:48 -0800 Subject: [Patches] [ python-Patches-1372125 ] fix UnixBrowswer failure when no browser running Message-ID: Patches item #1372125, was opened at 2005-12-03 03:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372125&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: fix UnixBrowswer failure when no browser running Initial Comment: See discussions in bug #1352621 and bug #1338995 for even more details. Background: The webbrowser.py was modified, post-Python 2.4.2, to tell whether or not the browser invocation succeeded or not. Unfortunately, the modifications caused Python applications to hang when no browser was already present. And the reputed fix for bug #1338995, revision 41419, only made things worse for UnixBrowsers. Fix: The changes to webbrowser.py were well intentioned, but failed because it was difficult to tell if invocation succeeded due to an extra level of indirection in invoking the browser by using os.system(). The attached patch, for revision 41511, uses subprocess.Popen() instead for UnixBrowser. The other uses of os.system() would also benefit, but are less critical to me. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 22:03 Message: Logged In: YES user_id=1188172 Thanks for the patch, most of the changed have been adapted and incorporated into the newest revision of webbrowser.py (42121). ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-09 00:47 Message: Logged In: YES user_id=131838 Replace original patch with one that has the tabs expanded out into spaces. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372125&group_id=5470 From noreply at sourceforge.net Fri Jan 20 22:34:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 13:34:16 -0800 Subject: [Patches] [ python-Patches-1410783 ] Doc patch for classmethod and staticmethod Message-ID: Patches item #1410783, was opened at 2006-01-20 14:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410783&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Doc patch for classmethod and staticmethod Initial Comment: This patch adds links from the descriptions of classmethod() and staticmethod() in Doc/lib/libfuncs.tex to the Python reference manual where class and static methods are discussed in more detail. This patch was made against SVN revision 42105. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 22:34 Message: Logged In: YES user_id=1188172 Thanks! Committed revisions 42127, 42128 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410783&group_id=5470 From noreply at sourceforge.net Fri Jan 20 22:34:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 13:34:48 -0800 Subject: [Patches] [ python-Patches-1410739 ] Add notes to the manual about `is` and methods Message-ID: Patches item #1410739, was opened at 2006-01-20 13:39 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410739&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add notes to the manual about `is` and methods Initial Comment: This patch, made against svn revision 42105, adds caveats to Doc/ref/ref3.tex concerning the use of the `is` operator in conjunction with class- and instance-methods. As I was recently bitten by trying to do the equivalent of """ >>> MyClass.a_class_method is MyClass.a_class_method False >>> """ I thought the manual might benefit from coverage of this as-yet-undocumented area. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410739&group_id=5470 From noreply at sourceforge.net Fri Jan 20 22:36:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 13:36:17 -0800 Subject: [Patches] [ python-Patches-1410998 ] Remove mention of DOS from os.py's docstring Message-ID: Patches item #1410998, was opened at 2006-01-20 19:00 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410998&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Hamish Lawson (hamishlawson) Assigned to: Nobody/Anonymous (nobody) Summary: Remove mention of DOS from os.py's docstring Initial Comment: The os.dospath module is no longer provided, but the docstring for the os module still says that it provides "OS routines for Mac, DOS, NT, or Posix". The attached patch removes mention of DOS. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 22:36 Message: Logged In: YES user_id=1188172 Nitpick ;), but thanks! Committed in rev. 42129. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410998&group_id=5470 From noreply at sourceforge.net Fri Jan 20 22:44:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 13:44:17 -0800 Subject: [Patches] [ python-Patches-1393667 ] Add restart debugger command to pdb.py Message-ID: Patches item #1393667, was opened at 2005-12-30 16:14 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rocky Bernstein (rockyb) Assigned to: Nobody/Anonymous (nobody) Summary: Add restart debugger command to pdb.py Initial Comment: The enclosed patch adds a restart command to pdb. (The short command name is "R" as it is in perldb). With an optional argument, the program arguments are reassigned. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 22:44 Message: Logged In: YES user_id=1188172 Patch looks good from my POV. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 From noreply at sourceforge.net Fri Jan 20 22:46:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 13:46:38 -0800 Subject: [Patches] [ python-Patches-1393157 ] Optional second argument for startfile Message-ID: Patches item #1393157, was opened at 2005-12-29 22:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393157&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Optional second argument for startfile Initial Comment: An optional second argument for os.startfile could be used to invoke 'verbs' other than the default on a file. For example, os.startfile("myfile.pdb", "print") ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 22:46 Message: Logged In: YES user_id=1188172 Seems logical and unproblematic to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-12-29 22:22 Message: Logged In: YES user_id=11105 I meant os.startfile("myfile.pdf", "print"). Sorry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393157&group_id=5470 From noreply at sourceforge.net Sat Jan 21 11:46:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jan 2006 02:46:32 -0800 Subject: [Patches] [ python-Patches-1410739 ] Add notes to the manual about `is` and methods Message-ID: Patches item #1410739, was opened at 2006-01-20 12:39 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410739&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add notes to the manual about `is` and methods Initial Comment: This patch, made against svn revision 42105, adds caveats to Doc/ref/ref3.tex concerning the use of the `is` operator in conjunction with class- and instance-methods. As I was recently bitten by trying to do the equivalent of """ >>> MyClass.a_class_method is MyClass.a_class_method False >>> """ I thought the manual might benefit from coverage of this as-yet-undocumented area. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-01-21 10:46 Message: Logged In: YES user_id=6656 I'm not really sure this patch is a good idea. It seems over-specific to one particular pitfall. Maybe instead warning stickers should be attached to the description of the 'is' operator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410739&group_id=5470 From noreply at sourceforge.net Sat Jan 21 16:33:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jan 2006 07:33:54 -0800 Subject: [Patches] [ python-Patches-1410739 ] Add notes to the manual about `is` and methods Message-ID: Patches item #1410739, was opened at 2006-01-20 07:39 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410739&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add notes to the manual about `is` and methods Initial Comment: This patch, made against svn revision 42105, adds caveats to Doc/ref/ref3.tex concerning the use of the `is` operator in conjunction with class- and instance-methods. As I was recently bitten by trying to do the equivalent of """ >>> MyClass.a_class_method is MyClass.a_class_method False >>> """ I thought the manual might benefit from coverage of this as-yet-undocumented area. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-01-21 10:33 Message: Logged In: YES user_id=1344176 I'm not sure a full-blown caveat on `is` is a good idea, unless this particular issue impacts areas beyond {class,instance}methods (the only two places I've see it). However, tacking a note to `is`, something like "you may notice unusal behaviour in certain combinations of `is` and class- and instancemethods; see their docs for more info", would probably be a good idea. I tried to make the original doc patch as specific as possible because it's a tricky problem. There's a good explanation for the following behaviour, but until someone expalins it to you, you're probably going to think it's a bug. """ >>> id(MyClass.class_method) == id(MyClass.class_method) True >>> MyClass.class_method is MyClass.class_method False """ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-01-21 05:46 Message: Logged In: YES user_id=6656 I'm not really sure this patch is a good idea. It seems over-specific to one particular pitfall. Maybe instead warning stickers should be attached to the description of the 'is' operator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410739&group_id=5470 From noreply at sourceforge.net Sat Jan 21 17:40:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jan 2006 08:40:05 -0800 Subject: [Patches] [ python-Patches-1411588 ] Add DarwinPorts directories to setup.py Message-ID: Patches item #1411588, was opened at 2006-01-21 11:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411588&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Add DarwinPorts directories to setup.py Initial Comment: In this thread: http://mail.python.org/pipermail/python-dev/2006-January/059838.html It was brought up that Python doesn't build readline properly on MacOS X. This patch adds DarwinPorts include and lib directories on the appropriate paths in the setup.py script, which just happens to have the side-effect of getting a usable readline module built. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411588&group_id=5470 From noreply at sourceforge.net Sun Jan 22 06:11:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jan 2006 21:11:42 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 Message generated for change (Comment added) made by crutcher_gmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: crutcher (crutcher_gmail) Date: 2006-01-21 21:11 Message: Logged In: YES user_id=1424288 I'm going to fix the missed exception test this weekend, and try to get an updated patch to you. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-01-14 01:54 Message: Logged In: YES user_id=4771 Provided this can be done with no measurable performance hit, I guess that I'm fine with the idea. The patch needs a bit more work, though: I don't see why it should accept dict subclasses as globals but not arbitrary mappings (as it now does for the locals). This is mainly an issue of removing a few checks in various places, like EXEC_STMT and the eval() and execfile() built-ins. There is a missing exception check/clear in the part about LOAD_NAME, after the PyObject_GetItem(f->f_globals, w). A side note: in the current trunk already, LOAD_GLOBAL contains a couple of checks, namely PyString_CheckExact() and hash != -1. We might be able to prove in advance that these two conditions are always true. We could then remove the checks. Not sure the difference measurable, though. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 23:50 Message: Logged In: YES user_id=1424288 Well, why fix it for eval but not for exec? I don't think the time hit is noticeable, I ran 'time make test' twice each on the trunk with and without the patch. Here are the results: Trunk: real 9m17.117s user 3m30.930s sys 0m35.417s real 9m9.471s user 3m31.484s sys 0m34.978s Patch: real 9m32.469s user 3m40.134s sys 0m36.140s real 9m6.779s user 3m27.529s sys 0m34.716s ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 22:11 Message: Logged In: YES user_id=21627 I think the history is this: it originates from python.org/sf/215126, which requested that you can pass dict subtypes to eval. Armin noted that eval will always produce LOAD/STORE_NAME, so just modifying these opcodes is sufficient to fulfil the feature request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 17:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 15:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 10:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 18:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 18:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Sun Jan 22 10:19:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 01:19:08 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 Message generated for change (Comment added) made by crutcher_gmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: crutcher (crutcher_gmail) Date: 2006-01-22 01:19 Message: Logged In: YES user_id=1424288 I've fixed up the exception case, and extended the test case to check for it. Is there anything else I can do to get this in? ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-21 21:11 Message: Logged In: YES user_id=1424288 I'm going to fix the missed exception test this weekend, and try to get an updated patch to you. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-01-14 01:54 Message: Logged In: YES user_id=4771 Provided this can be done with no measurable performance hit, I guess that I'm fine with the idea. The patch needs a bit more work, though: I don't see why it should accept dict subclasses as globals but not arbitrary mappings (as it now does for the locals). This is mainly an issue of removing a few checks in various places, like EXEC_STMT and the eval() and execfile() built-ins. There is a missing exception check/clear in the part about LOAD_NAME, after the PyObject_GetItem(f->f_globals, w). A side note: in the current trunk already, LOAD_GLOBAL contains a couple of checks, namely PyString_CheckExact() and hash != -1. We might be able to prove in advance that these two conditions are always true. We could then remove the checks. Not sure the difference measurable, though. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 23:50 Message: Logged In: YES user_id=1424288 Well, why fix it for eval but not for exec? I don't think the time hit is noticeable, I ran 'time make test' twice each on the trunk with and without the patch. Here are the results: Trunk: real 9m17.117s user 3m30.930s sys 0m35.417s real 9m9.471s user 3m31.484s sys 0m34.978s Patch: real 9m32.469s user 3m40.134s sys 0m36.140s real 9m6.779s user 3m27.529s sys 0m34.716s ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 22:11 Message: Logged In: YES user_id=21627 I think the history is this: it originates from python.org/sf/215126, which requested that you can pass dict subtypes to eval. Armin noted that eval will always produce LOAD/STORE_NAME, so just modifying these opcodes is sufficient to fulfil the feature request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 17:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 15:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 10:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 18:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 18:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Sun Jan 22 14:47:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 05:47:54 -0800 Subject: [Patches] [ python-Patches-1412054 ] More easily extensible logging module Message-ID: Patches item #1412054, was opened at 2006-01-22 13:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412054&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Nobody/Anonymous (nobody) Summary: More easily extensible logging module Initial Comment: The Python logging.Logger class is supposed being extensible by overriding the makeRecord() method. This is not completely true because the public logging method (log(), debug(), info()...) call the less public _log(), which in turn call makeRecord(). While the public methods have a signature such: def info(self, msg, *args, **kwargs): ... apply(self._log, (INFO, msg, args), kwargs) thus leaving room for expansion, the _log() method is not so much flexible: def _log(self, level, msg, args, exc_info=None): # ...interesting stuff here... record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info) self.handle(record) The makeRecord signature is: def makeRecord(self, name, level, fn, lno, msg, args, exc_info): So if anybody wants to add a keyword to makeRecord, he also needs to re-implement the "interesting stuff" in the supposed private _log (finding the source row, reading the stack trace...). The attached patch should leave the _log behavior unchanged but all unknown keyword arguments are passed to makeRecord. If a wrong parameter is passed to any public method, the logger as before raises an exception, which is raised on the makeRecord() call instead of _log()'s. With the patch on, use case for an user that want to log extra keywords is: import logging # Logger customization class MyLogRecord(logging.LogRecord): """Add a foo to a log record.""" def __init__(self, name, level, pathname, lineno, msg, args, exc_info, foo): logging.LogRecord.__init__(self, name, level, pathname, lineno, msg, args, exc_info) self.foo = foo class MyLogger(logging.Logger): """Can log foos too.""" def makeRecord(self, name, level, fn, lno, msg, args, exc_info, foo): return MyLogRecord(name, level, fn, lno, msg, args, exc_info, foo) class MyHandler(logging.Handler): """Can handle foo records.""" def emit(self, record): if isinstance(record, MyLogRecord): print self.format(record), record.foo # Logger configuration logging.setLoggerClass(MyLogger) logger = logging.getLogger('test') logger.setLevel(logging.INFO) hndl = MyHandler(level=logging.INFO) hndl.setFormatter( logging.Formatter("%(message)s at line #%(lineno)d")) logger.addHandler(hndl) # Logger usage logger.info("Message", foo='pippo') # prints something like "Message at line #40 pippo" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412054&group_id=5470 From noreply at sourceforge.net Sun Jan 22 14:50:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 05:50:27 -0800 Subject: [Patches] [ python-Patches-1412054 ] More easily extensible logging module Message-ID: Patches item #1412054, was opened at 2006-01-22 13:47 Message generated for change (Settings changed) made by dvarrazzo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412054&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) >Assigned to: Vinay Sajip (vsajip) Summary: More easily extensible logging module Initial Comment: The Python logging.Logger class is supposed being extensible by overriding the makeRecord() method. This is not completely true because the public logging method (log(), debug(), info()...) call the less public _log(), which in turn call makeRecord(). While the public methods have a signature such: def info(self, msg, *args, **kwargs): ... apply(self._log, (INFO, msg, args), kwargs) thus leaving room for expansion, the _log() method is not so much flexible: def _log(self, level, msg, args, exc_info=None): # ...interesting stuff here... record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info) self.handle(record) The makeRecord signature is: def makeRecord(self, name, level, fn, lno, msg, args, exc_info): So if anybody wants to add a keyword to makeRecord, he also needs to re-implement the "interesting stuff" in the supposed private _log (finding the source row, reading the stack trace...). The attached patch should leave the _log behavior unchanged but all unknown keyword arguments are passed to makeRecord. If a wrong parameter is passed to any public method, the logger as before raises an exception, which is raised on the makeRecord() call instead of _log()'s. With the patch on, use case for an user that want to log extra keywords is: import logging # Logger customization class MyLogRecord(logging.LogRecord): """Add a foo to a log record.""" def __init__(self, name, level, pathname, lineno, msg, args, exc_info, foo): logging.LogRecord.__init__(self, name, level, pathname, lineno, msg, args, exc_info) self.foo = foo class MyLogger(logging.Logger): """Can log foos too.""" def makeRecord(self, name, level, fn, lno, msg, args, exc_info, foo): return MyLogRecord(name, level, fn, lno, msg, args, exc_info, foo) class MyHandler(logging.Handler): """Can handle foo records.""" def emit(self, record): if isinstance(record, MyLogRecord): print self.format(record), record.foo # Logger configuration logging.setLoggerClass(MyLogger) logger = logging.getLogger('test') logger.setLevel(logging.INFO) hndl = MyHandler(level=logging.INFO) hndl.setFormatter( logging.Formatter("%(message)s at line #%(lineno)d")) logger.addHandler(hndl) # Logger usage logger.info("Message", foo='pippo') # prints something like "Message at line #40 pippo" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412054&group_id=5470 From noreply at sourceforge.net Mon Jan 23 03:10:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 18:10:41 -0800 Subject: [Patches] [ python-Patches-1412448 ] Compile under mingw properly Message-ID: Patches item #1412448, was opened at 2006-01-23 02: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=1412448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Gir?o Bezerra de Mene (alexgirao) Assigned to: Nobody/Anonymous (nobody) Summary: Compile under mingw properly Initial Comment: Hi, I made only simple changes to let gcc happy with win related code and to compile without warnings. Alexadre Girao, http://nextt.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412448&group_id=5470 From noreply at sourceforge.net Mon Jan 23 03:21:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 18:21:20 -0800 Subject: [Patches] [ python-Patches-1412451 ] Fill out the functional module Message-ID: Patches item #1412451, was opened at 2006-01-22 21:21 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=1412451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fill out the functional module Initial Comment: This patch is an expansion of my earlier patch, #1410119, and should be considered to supersede it. This patch fixes a reference leak in the earlier implementation of foldr. The reference leak was tricky to trigger, but existed. In addition, this patch breaks the functional module into two parts: Modules/_functionalmodule.c and Lib/functional.py. The latter is for list-producing functions which are better implemented as generators (to make them lazier), while the former is reserved for non-list-producing functions, written in C for speed. Lib/functional.py imports the `_functional` module generated from Modules/_functionalmodule.c. The total contents of the functional module: + compose + concat + concatMap + cycle + drop + dropWhile + flip + foldl + foldl1 + foldr + foldr1 + id + iterate + partial + repeat + scanl + scanl1 + scanr + scanr1 + take + takeWhile In addition to a full test-suite and latex-formatted documentation for all functions, this patch also adds a functional/ directory to Demo/ and populates it with examples. After applying this patch, the existing Modules/functionalmodule.c should be removed and replaced with the attached _functionalmodule.c (sorry, I couldn't figure out how to make this show up in an svn diff reliably). The patch is against svn revision 42148. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 From noreply at sourceforge.net Mon Jan 23 03:23:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 18:23:50 -0800 Subject: [Patches] [ python-Patches-1410119 ] Add foldr and foldl to functional module Message-ID: Patches item #1410119, was opened at 2006-01-19 13:50 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add foldr and foldl to functional module Initial Comment: This patch adds foldr and foldl functions to the functional module. In addition, it updates libfunctional.tex and test/test_functional to include documentation and tests, respectively, for the new code. The code has been checked for reference leaks using --with-pydebug. The patch is against svn revision 42097. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-01-22 21:23 Message: Logged In: YES user_id=1344176 I found a reference leak in my implementation of foldr. While fixing it, I did a lot more work on the functional module, which I've rolled into patch #1412451. Accordingly, I'm closing this current patch. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 12:46 Message: Logged In: YES user_id=764593 Review: I recommend to apply this patch. It includes test cases and documentation. Cannot break backwards compatibility, as the entire module is new in 2.5. The added functions are reasonably standard for modern functional programming, and they are in the functional module, which would otherwise be fairly sparse. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 12:43 Message: Logged In: YES user_id=1188172 In any case, having those functions in functional, under their "common" name, is a good thing IMHO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-20 12:31 Message: Logged In: YES user_id=1344176 Ah, I had thought reduce was going away sooner than Python 3.0. I've updated the patch to include an expansion of both foldl and foldr (in the __doc__'s and the latex docs). Also included are mentions of max, min, sum and filter, plus a suggestion to go consult any one of the "Functional Programming with Python" tutorials that a quick Google search turns up. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 11:12 Message: Logged In: YES user_id=764593 Guido thinks that reduce is too hard to understand, because it is too broad. It still won't be removed before python 3. 0. Python three *might* appear as soon as five years from now, and even then, reduce would probably still be kept in the functional module. (1) Should the functional module also mention other builtins, such as sum, filter, and even min and max? (2) Could you show the step-by-step for foldr? I missed the difference when reading your patch, and it took me a while to figure out how it works even after *this* reminder. At this point, my best guess is that foldr(minus, 0, [1,2,3]) <==> (1 - (2 - (3 - 0))) while foldl(minus, 0, [1,2,3]) <==> (((0 - 1) - 2) - 3) so foldr(f, zero, [x1, x2, x3...xn]) <==> f(x1, f(x2, f(x3, ... f(xn, zero)))) while foldl(f, zero, [x1, x2, x3...xn]) <==> f(f(f(f(f(zero, x1), x2), x3) ... ), xn) but I'm still not *sure* I got it right. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-20 10:44 Message: Logged In: YES user_id=1344176 I was under the impression that reduce was going to be removed at some point in the future? In any case, while reduce() is indeed another name for foldl, "reduce(func, reversed(iter), initial)" is not the same thing as foldr(). """ >>> def sub(a, b): return a - b ... >>> foldr(sub, 0, [1, 2, 3]) 2 >>> reduce(sub, [3, 2, 1], 0) -6 """ I'd be happy to update the patch to include references to reduce() in relation to foldl. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 10:32 Message: Logged In: YES user_id=764593 What does this add over the (currently builtin) reduce? reduce(func, iter, initial) and reduce(func, reversed(iter), initial) Is it just that foldr and foldl are more modern names? If so, it might be better to submit a documentation patch. The functional module should mention reduce, and the reduce documenation (library reference/Built-in Objects/Built-in Functions) could be clarified. Maybe even show how to create foldr and foldl as an example, for reduce so that the terms can be picked up by indexers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 From noreply at sourceforge.net Mon Jan 23 03:24:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 18:24:36 -0800 Subject: [Patches] [ python-Patches-1410119 ] Add foldr and foldl to functional module Message-ID: Patches item #1410119, was opened at 2006-01-19 13:50 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add foldr and foldl to functional module Initial Comment: This patch adds foldr and foldl functions to the functional module. In addition, it updates libfunctional.tex and test/test_functional to include documentation and tests, respectively, for the new code. The code has been checked for reference leaks using --with-pydebug. The patch is against svn revision 42097. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-22 21:23 Message: Logged In: YES user_id=1344176 I found a reference leak in my implementation of foldr. While fixing it, I did a lot more work on the functional module, which I've rolled into patch #1412451. Accordingly, I'm closing this current patch. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 12:46 Message: Logged In: YES user_id=764593 Review: I recommend to apply this patch. It includes test cases and documentation. Cannot break backwards compatibility, as the entire module is new in 2.5. The added functions are reasonably standard for modern functional programming, and they are in the functional module, which would otherwise be fairly sparse. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 12:43 Message: Logged In: YES user_id=1188172 In any case, having those functions in functional, under their "common" name, is a good thing IMHO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-20 12:31 Message: Logged In: YES user_id=1344176 Ah, I had thought reduce was going away sooner than Python 3.0. I've updated the patch to include an expansion of both foldl and foldr (in the __doc__'s and the latex docs). Also included are mentions of max, min, sum and filter, plus a suggestion to go consult any one of the "Functional Programming with Python" tutorials that a quick Google search turns up. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 11:12 Message: Logged In: YES user_id=764593 Guido thinks that reduce is too hard to understand, because it is too broad. It still won't be removed before python 3. 0. Python three *might* appear as soon as five years from now, and even then, reduce would probably still be kept in the functional module. (1) Should the functional module also mention other builtins, such as sum, filter, and even min and max? (2) Could you show the step-by-step for foldr? I missed the difference when reading your patch, and it took me a while to figure out how it works even after *this* reminder. At this point, my best guess is that foldr(minus, 0, [1,2,3]) <==> (1 - (2 - (3 - 0))) while foldl(minus, 0, [1,2,3]) <==> (((0 - 1) - 2) - 3) so foldr(f, zero, [x1, x2, x3...xn]) <==> f(x1, f(x2, f(x3, ... f(xn, zero)))) while foldl(f, zero, [x1, x2, x3...xn]) <==> f(f(f(f(f(zero, x1), x2), x3) ... ), xn) but I'm still not *sure* I got it right. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-20 10:44 Message: Logged In: YES user_id=1344176 I was under the impression that reduce was going to be removed at some point in the future? In any case, while reduce() is indeed another name for foldl, "reduce(func, reversed(iter), initial)" is not the same thing as foldr(). """ >>> def sub(a, b): return a - b ... >>> foldr(sub, 0, [1, 2, 3]) 2 >>> reduce(sub, [3, 2, 1], 0) -6 """ I'd be happy to update the patch to include references to reduce() in relation to foldl. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 10:32 Message: Logged In: YES user_id=764593 What does this add over the (currently builtin) reduce? reduce(func, iter, initial) and reduce(func, reversed(iter), initial) Is it just that foldr and foldl are more modern names? If so, it might be better to submit a documentation patch. The functional module should mention reduce, and the reduce documenation (library reference/Built-in Objects/Built-in Functions) could be clarified. Maybe even show how to create foldr and foldl as an example, for reduce so that the terms can be picked up by indexers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410119&group_id=5470 From noreply at sourceforge.net Mon Jan 23 10:16:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 01:16:29 -0800 Subject: [Patches] [ python-Patches-1412632 ] Proper locking with asynchronous callbacks. Message-ID: Patches item #1412632, was opened at 2006-01-23 10:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412632&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: uiltje (tuijldert) Assigned to: Nobody/Anonymous (nobody) Summary: Proper locking with asynchronous callbacks. Initial Comment: Handling of Py_AddPendingCall()/Py_MakePendingCalls() in ceval.c cannot handle registry calls that are made while processing pending calls. Current solution doesn't work, the "busy" variable should be shared between the two functions for it to work. This patch should work but is still not atomic, that'd need proper locking. Hence the alternative code in the patch when threading/semaphores are present. Please review and apply the attached patch. Thanks in advance, Tom. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412632&group_id=5470 From noreply at sourceforge.net Mon Jan 23 13:55:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 04:55:19 -0800 Subject: [Patches] [ python-Patches-1412451 ] Fill out the functional module Message-ID: Patches item #1412451, was opened at 2006-01-22 21:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fill out the functional module Initial Comment: This patch is an expansion of my earlier patch, #1410119, and should be considered to supersede it. This patch fixes a reference leak in the earlier implementation of foldr. The reference leak was tricky to trigger, but existed. In addition, this patch breaks the functional module into two parts: Modules/_functionalmodule.c and Lib/functional.py. The latter is for list-producing functions which are better implemented as generators (to make them lazier), while the former is reserved for non-list-producing functions, written in C for speed. Lib/functional.py imports the `_functional` module generated from Modules/_functionalmodule.c. The total contents of the functional module: + compose + concat + concatMap + cycle + drop + dropWhile + flip + foldl + foldl1 + foldr + foldr1 + id + iterate + partial + repeat + scanl + scanl1 + scanr + scanr1 + take + takeWhile In addition to a full test-suite and latex-formatted documentation for all functions, this patch also adds a functional/ directory to Demo/ and populates it with examples. After applying this patch, the existing Modules/functionalmodule.c should be removed and replaced with the attached _functionalmodule.c (sorry, I couldn't figure out how to make this show up in an svn diff reliably). The patch is against svn revision 42148. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-01-23 07:55 Message: Logged In: YES user_id=1344176 I've broken the main functional.patch into two subpatches. demo.patch creates and populates the Demo/functional/ directory, while functional.patch does all the rest. Both patches are updated to r42155. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 From noreply at sourceforge.net Mon Jan 23 15:43:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 06:43:35 -0800 Subject: [Patches] [ python-Patches-1411588 ] Add DarwinPorts directories to setup.py Message-ID: Patches item #1411588, was opened at 2006-01-21 17:40 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411588&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Add DarwinPorts directories to setup.py Initial Comment: In this thread: http://mail.python.org/pipermail/python-dev/2006-January/059838.html It was brought up that Python doesn't build readline properly on MacOS X. This patch adds DarwinPorts include and lib directories on the appropriate paths in the setup.py script, which just happens to have the side-effect of getting a usable readline module built. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-01-23 15:43 Message: Logged In: YES user_id=580910 I don't really like this, although this would give DP the same treatment as Fink. IMHO it would be better to search in the directories provided in LDFLAGS and/or OPT, that way users can choose if they want to use software from DP (or Fink). Most of the required functionality seems to be there already. The only thing that's missing is enhancing variables like search_for_ssl_incs_in based on the include directories in OPT, but that's not necessary to pick up readline support. E.g. '.../configure ... OPT=-I/opt/local/include LDFLAGS=-L/opt/local/include' should do the trick without patching python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411588&group_id=5470 From noreply at sourceforge.net Mon Jan 23 15:48:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 06:48:00 -0800 Subject: [Patches] [ python-Patches-1412872 ] zipfile: use correct system type on unixy systems Message-ID: Patches item #1412872, was opened at 2006-01-23 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=1412872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: use correct system type on unixy systems Initial Comment: This patch updates the contructor of zipfile.ZipInfo to initialize the create_system attribute to 3 instead of 0 on systems that are not Windows. Without this patch the unzip command won't honour the file mode that is stored in the zip file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 From noreply at sourceforge.net Mon Jan 23 17:39:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 08:39:29 -0800 Subject: [Patches] [ python-Patches-1411588 ] Add DarwinPorts directories to setup.py Message-ID: Patches item #1411588, was opened at 2006-01-21 16:40 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411588&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Add DarwinPorts directories to setup.py Initial Comment: In this thread: http://mail.python.org/pipermail/python-dev/2006-January/059838.html It was brought up that Python doesn't build readline properly on MacOS X. This patch adds DarwinPorts include and lib directories on the appropriate paths in the setup.py script, which just happens to have the side-effect of getting a usable readline module built. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2006-01-23 16:39 Message: Logged In: YES user_id=34892 Barry, Brett specifically *removed* the Fink and DarwinPorts dirs from setup.py for the more generic mechanism (that Ronald described) in this change: http://svn.python.org/view?rev=37988&view=rev My personal preference is for the current state (don't automatically pick up Fink and DarwinPorts stuff) but I can see the case for wanting this stuff to "just work" for naive usage of "./configure; make". ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-01-23 14:43 Message: Logged In: YES user_id=580910 I don't really like this, although this would give DP the same treatment as Fink. IMHO it would be better to search in the directories provided in LDFLAGS and/or OPT, that way users can choose if they want to use software from DP (or Fink). Most of the required functionality seems to be there already. The only thing that's missing is enhancing variables like search_for_ssl_incs_in based on the include directories in OPT, but that's not necessary to pick up readline support. E.g. '.../configure ... OPT=-I/opt/local/include LDFLAGS=-L/opt/local/include' should do the trick without patching python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411588&group_id=5470 From noreply at sourceforge.net Mon Jan 23 17:47:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 08:47:14 -0800 Subject: [Patches] [ python-Patches-1411588 ] Add DarwinPorts directories to setup.py Message-ID: Patches item #1411588, was opened at 2006-01-21 11:40 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411588&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Add DarwinPorts directories to setup.py Initial Comment: In this thread: http://mail.python.org/pipermail/python-dev/2006-January/059838.html It was brought up that Python doesn't build readline properly on MacOS X. This patch adds DarwinPorts include and lib directories on the appropriate paths in the setup.py script, which just happens to have the side-effect of getting a usable readline module built. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-23 11:47 Message: Logged In: YES user_id=12800 I wasn't developing on the Mac at the time, so I'm sure I paid no attention to this change. ;) I can see the wisdom of Brett's change, but OTOH I do think it makes sense to allow configure; make to Just Work. I suppose the right answer is to leave Brett's changes in and not add this patch. Ultimately there should be only one way to do it. Rejecting & closing. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-01-23 11:39 Message: Logged In: YES user_id=34892 Barry, Brett specifically *removed* the Fink and DarwinPorts dirs from setup.py for the more generic mechanism (that Ronald described) in this change: http://svn.python.org/view?rev=37988&view=rev My personal preference is for the current state (don't automatically pick up Fink and DarwinPorts stuff) but I can see the case for wanting this stuff to "just work" for naive usage of "./configure; make". ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-01-23 09:43 Message: Logged In: YES user_id=580910 I don't really like this, although this would give DP the same treatment as Fink. IMHO it would be better to search in the directories provided in LDFLAGS and/or OPT, that way users can choose if they want to use software from DP (or Fink). Most of the required functionality seems to be there already. The only thing that's missing is enhancing variables like search_for_ssl_incs_in based on the include directories in OPT, but that's not necessary to pick up readline support. E.g. '.../configure ... OPT=-I/opt/local/include LDFLAGS=-L/opt/local/include' should do the trick without patching python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411588&group_id=5470 From noreply at sourceforge.net Mon Jan 23 21:09:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 12:09:45 -0800 Subject: [Patches] [ python-Patches-1413181 ] PyThreadState_Delete doesnt' clean autoTLSkey Message-ID: Patches item #1413181, was opened at 2006-01-23 17:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1413181&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Becedillas (gbeced) Assigned to: Nobody/Anonymous (nobody) Summary: PyThreadState_Delete doesnt' clean autoTLSkey Initial Comment: Check this thread for a detailed description: http://mail.python.org/pipermail/python-dev/2006-January/059716.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1413181&group_id=5470 From noreply at sourceforge.net Tue Jan 24 14:50:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 05:50:11 -0800 Subject: [Patches] [ python-Patches-1413711 ] difflib exceeding recursion limit Message-ID: Patches item #1413711, was opened at 2006-01-24 13:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1413711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: difflib exceeding recursion limit Initial Comment: difflib is exceeding the default recursion limit in certain patterns of lines. The attached patch will change the problematic method into a non-recursive version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1413711&group_id=5470 From noreply at sourceforge.net Tue Jan 24 14:53:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 05:53:35 -0800 Subject: [Patches] [ python-Patches-1413711 ] difflib exceeding recursion limit Message-ID: Patches item #1413711, was opened at 2006-01-24 13:50 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1413711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: difflib exceeding recursion limit Initial Comment: difflib is exceeding the default recursion limit in certain patterns of lines. The attached patch will change the problematic method into a non-recursive version. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-01-24 13:53 Message: Logged In: YES user_id=7887 Attaching a test case showing the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1413711&group_id=5470 From noreply at sourceforge.net Tue Jan 24 16:08:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 07:08:05 -0800 Subject: [Patches] [ python-Patches-1407992 ] fix bsddb test associate problems w/bsddb 4.1 Message-ID: Patches item #1407992, was opened at 2006-01-17 08:51 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407992&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix bsddb test associate problems w/bsddb 4.1 Initial Comment: I think that's what this patch fixes. Just wanted to get up here and find a BSD DB knowledgable person to comment. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2006-01-24 16:08 Message: Logged In: YES user_id=112690 I would recommend to upgrade to 4.2 or newer instead. See: http://subversion.tigris.org/faq.html#bdb41-tabletype-bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407992&group_id=5470 From noreply at sourceforge.net Tue Jan 24 16:22:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 07:22:43 -0800 Subject: [Patches] [ python-Patches-1407992 ] fix bsddb test associate problems w/bsddb 4.1 Message-ID: Patches item #1407992, was opened at 2006-01-17 08:51 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407992&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix bsddb test associate problems w/bsddb 4.1 Initial Comment: I think that's what this patch fixes. Just wanted to get up here and find a BSD DB knowledgable person to comment. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2006-01-24 16:22 Message: Logged In: YES user_id=112690 Sorry, "instead" is not the right word here. I meant that I wouldn't give too much support to bsddb 4.1. Users of it ought to know the problem that it carries. I haven't seen at the original problem though. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2006-01-24 16:08 Message: Logged In: YES user_id=112690 I would recommend to upgrade to 4.2 or newer instead. See: http://subversion.tigris.org/faq.html#bdb41-tabletype-bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407992&group_id=5470 From noreply at sourceforge.net Tue Jan 24 16:52:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 07:52:19 -0800 Subject: [Patches] [ python-Patches-1349118 ] Patch f. bug 495682 cannot handle http_proxy with user:pass@ Message-ID: Patches item #1349118, was opened at 2005-11-05 18:05 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Johannes Nicolai (jonico) Assigned to: Nobody/Anonymous (nobody) Summary: Patch f. bug 495682 cannot handle http_proxy with user:pass@ Initial Comment: solves problems for http and https proxies described in this bug solves tracebacks if proxy is specified for a protocol where no proxy is currently supported added dynamic proxy authentification for http and https solved bug that if a host accessed by the https protocol requires authentification, the https proxy won't be used after questioning the password ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-24 16:52 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed (with wording changes) as r42171. ---------------------------------------------------------------------- Comment By: Johannes Nicolai (jonico) Date: 2005-12-13 18:30 Message: Logged In: YES user_id=863272 Sorry, I have only uploaded an old version of the patch. There, the traceback problem was not solved at all 8-) I have now added the complete patch, that already relates to the newest version in the subversion repository. I will try to get another tester for my code, but it might be difficult. Unfortunately, only few people have an SSL capable proxy. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-12-13 17:47 Message: Logged In: YES user_id=6380 The patch looks good as a fix for bug 495682. I don't see which lines in the patch warrant the claim "solves tracebacks if proxy is specified for a protocol where no proxy is currently supported" -- can you explain this? I'd like you to request validation (testing) from someone else on python-dev who can actually run this code -- I have no way to verify that it works as advertised. ---------------------------------------------------------------------- Comment By: Johannes Nicolai (jonico) Date: 2005-11-07 11:27 Message: Logged In: YES user_id=863272 Perhaps some words about the accuracy of the patch: I have successfully tested it with squid 2.5 and squid 3.0 as http and https proxy with and without password. I used the integrated test routines in urllib.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349118&group_id=5470 From lyndesden at wcsonline.net Tue Jan 24 16:49:43 2006 From: lyndesden at wcsonline.net (Roger) Date: Tue, 24 Jan 2006 09:49:43 -0600 Subject: [Patches] China World Trade Corp making major breakthroughs Message-ID: <000701c620fd$cf415d60$9ea4a448@lynde3> How can I get the China World Trade Corp to QUIT sending stock announcements. I am not interested in losing my money so I DON'T DO STOCKS. The messages are beginning to be a pain in the "you know where" I am NOT interested in your stock nor your employees sending their "unwanted" e-mails. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20060124/ace12a85/attachment.htm From noreply at sourceforge.net Tue Jan 24 20:09:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 11:09:30 -0800 Subject: [Patches] [ python-Patches-1349274 ] [PATCH] 100x optimization for ngettext Message-ID: Patches item #1349274, was opened at 2005-11-06 01:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) >Assigned to: Martin v. L??wis (loewis) Summary: [PATCH] 100x optimization for ngettext Initial Comment: Currently gettext.ngettext scans the filesystem whenever you call it. This makes it ridiculously slow. But if one uses gettext.install to initialize gettext, gettext.ngettext is the cleanest way to do plural translation. This patch makes gettext.install install both "_" and "ngettext" into the builtin namespace, which means using "ngettext" won't have to do the filesystem lookup. My benchmarks show this is about 100 times faster. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-24 20:09 Message: Logged In: YES user_id=1188172 Are there opinions about my suggestion? ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-07 22:41 Message: Logged In: YES user_id=796 Well, I did write my own install function; that's the patch you see below. I figured I'd submit it in the interest of other users (that's the point of a standard library, right?) but if the Pythonic thing to do is choose between ugly or slow, I guess I'll just keep using my own. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-07 21:30 Message: Logged In: YES user_id=1188172 I didn't mean to overload the calling of "_", but I can think of "_.gettext()", "_.ngettext()" etc. Of course with "_()" staying the same. Other than that, if you need ngettext in builtins, why don't you write your own install function? ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-06 21:59 Message: Logged In: YES user_id=796 It seems to me that the time to complain about namespace clutter was when gettext.install was written. Besides, it's only "clutter" if you're not using it, and if you're not using it, just don't call install. Making _ dispatch on the number of arguments would break all the existing string extraction tools. It's also unintuitive for anyone coming from gettext in other languages. It's also messy semantic overloading. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-06 20:21 Message: Logged In: YES user_id=1188172 The problem you diagnosed is valid, but I don't think the patch is a proper way to salvage it (by cluttering the builtin namespace). I'd rather have the installed name "_" point to a wrapper object that gives one access to the other translation functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 From noreply at sourceforge.net Tue Jan 24 20:57:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 11:57:19 -0800 Subject: [Patches] [ python-Patches-1407992 ] fix bsddb test associate problems w/bsddb 4.1 Message-ID: Patches item #1407992, was opened at 2006-01-16 23:51 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407992&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Gregory P. Smith (greg) Summary: fix bsddb test associate problems w/bsddb 4.1 Initial Comment: I think that's what this patch fixes. Just wanted to get up here and find a BSD DB knowledgable person to comment. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-01-24 11:57 Message: Logged In: YES user_id=413 thanks! this appears to work. I tested it with BerkeleyDB 3.2 thru 4.4. 4.2-4.4 already worked fine; this patch fixes associate in 3.3 thru 4.1. (3.2 does not support associate) commit id 42173. Supporting older BerkeleyDB versions can be annoying but when its easy lets do it. I agree with hfoffani that serious bsddb users should consider >= 4.2. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2006-01-24 07:22 Message: Logged In: YES user_id=112690 Sorry, "instead" is not the right word here. I meant that I wouldn't give too much support to bsddb 4.1. Users of it ought to know the problem that it carries. I haven't seen at the original problem though. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2006-01-24 07:08 Message: Logged In: YES user_id=112690 I would recommend to upgrade to 4.2 or newer instead. See: http://subversion.tigris.org/faq.html#bdb41-tabletype-bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407992&group_id=5470 From noreply at sourceforge.net Tue Jan 24 21:01:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 12:01:06 -0800 Subject: [Patches] [ python-Patches-1146231 ] bsddb3 build problems on FreeBSD (2.4 + 2.5) Message-ID: Patches item #1146231, was opened at 2005-02-22 05:10 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1146231&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb3 build problems on FreeBSD (2.4 + 2.5) Initial Comment: FreeBSD's ports system has another variation on naming the Sleepcat DB library. The attached patch adds support for this naming variation. The patch is actually for CVS head, but applies to the 2.4 maintenance branch (with an offset). In my particular case, my FreeBSD box has both DB 4.1 and DB 4.0 installed; the build was finding the 4.1 headers and compiling against them, but then linking to the 4.0 library. In consequence, all the tests which depend on the _bsddb module (test_anydbm, test_bsddb, test_bsddb185, test_shelve, test_whichdb) were failing or dumping core. This patch (or something with similar effect) should be applied in time for 2.4.1 in my opinion (I could do that, but would like the release manager's approval). ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-01-24 12:01 Message: Logged In: YES user_id=413 closing, looks like this was already applied. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-03-14 07:33 Message: Logged In: YES user_id=1188172 Should this be closed, then? ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2005-03-09 14:34 Message: Logged In: YES user_id=250749 applied as version 1.204.2.3 (2.4) / 1.216 (head) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1146231&group_id=5470 From noreply at sourceforge.net Wed Jan 25 00:19:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 15:19:32 -0800 Subject: [Patches] [ python-Patches-1412448 ] Compile under mingw properly Message-ID: Patches item #1412448, was opened at 2006-01-22 21:10 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Gir?o Bezerra de Mene (alexgirao) Assigned to: Nobody/Anonymous (nobody) Summary: Compile under mingw properly Initial Comment: Hi, I made only simple changes to let gcc happy with win related code and to compile without warnings. Alexadre Girao, http://nextt.org ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-24 18:19 Message: Logged In: YES user_id=764593 Are you sure these were just compiler-related? Changing things like frequency from {0,0} to {{0,}} or adding parentheses strike me as at least possible bugfixes that should not be in #ifdefs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412448&group_id=5470 From noreply at sourceforge.net Wed Jan 25 00:34:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 15:34:22 -0800 Subject: [Patches] [ python-Patches-1412448 ] Compile under mingw properly Message-ID: Patches item #1412448, was opened at 2006-01-23 02:10 Message generated for change (Comment added) made by alexgirao You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Gir?o Bezerra de Mene (alexgirao) Assigned to: Nobody/Anonymous (nobody) Summary: Compile under mingw properly Initial Comment: Hi, I made only simple changes to let gcc happy with win related code and to compile without warnings. Alexadre Girao, http://nextt.org ---------------------------------------------------------------------- >Comment By: Alexandre Gir?o Bezerra de Mene (alexgirao) Date: 2006-01-24 23:34 Message: Logged In: YES user_id=700047 Most of the changes were related to correct usage of braces and incompatibilities with mingw (note that i compiled with msvc too). The parenthesis changes apply to msvc too. I thank you so much for paying attention on this. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-24 23:19 Message: Logged In: YES user_id=764593 Are you sure these were just compiler-related? Changing things like frequency from {0,0} to {{0,}} or adding parentheses strike me as at least possible bugfixes that should not be in #ifdefs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412448&group_id=5470 From noreply at sourceforge.net Wed Jan 25 04:38:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 19:38:17 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 Message generated for change (Comment added) made by crutcher_gmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: crutcher (crutcher_gmail) Date: 2006-01-24 19:38 Message: Logged In: YES user_id=1424288 currently chasing through the PyFrame code and the EXEC_STMT code to make globals generic mappings, will update this patch yet again. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-22 01:19 Message: Logged In: YES user_id=1424288 I've fixed up the exception case, and extended the test case to check for it. Is there anything else I can do to get this in? ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-21 21:11 Message: Logged In: YES user_id=1424288 I'm going to fix the missed exception test this weekend, and try to get an updated patch to you. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-01-14 01:54 Message: Logged In: YES user_id=4771 Provided this can be done with no measurable performance hit, I guess that I'm fine with the idea. The patch needs a bit more work, though: I don't see why it should accept dict subclasses as globals but not arbitrary mappings (as it now does for the locals). This is mainly an issue of removing a few checks in various places, like EXEC_STMT and the eval() and execfile() built-ins. There is a missing exception check/clear in the part about LOAD_NAME, after the PyObject_GetItem(f->f_globals, w). A side note: in the current trunk already, LOAD_GLOBAL contains a couple of checks, namely PyString_CheckExact() and hash != -1. We might be able to prove in advance that these two conditions are always true. We could then remove the checks. Not sure the difference measurable, though. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 23:50 Message: Logged In: YES user_id=1424288 Well, why fix it for eval but not for exec? I don't think the time hit is noticeable, I ran 'time make test' twice each on the trunk with and without the patch. Here are the results: Trunk: real 9m17.117s user 3m30.930s sys 0m35.417s real 9m9.471s user 3m31.484s sys 0m34.978s Patch: real 9m32.469s user 3m40.134s sys 0m36.140s real 9m6.779s user 3m27.529s sys 0m34.716s ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 22:11 Message: Logged In: YES user_id=21627 I think the history is this: it originates from python.org/sf/215126, which requested that you can pass dict subtypes to eval. Armin noted that eval will always produce LOAD/STORE_NAME, so just modifying these opcodes is sufficient to fulfil the feature request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 17:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 15:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 10:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 18:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 18:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From mala4000 at bol.com.br Wed Jan 25 06:43:00 2006 From: mala4000 at bol.com.br (Lidiana Alves) Date: Wed, 25 Jan 2006 02:43:00 -0300 Subject: [Patches] Modelos prontos de cartas e e-mails comerciais Message-ID: <20060125054417.4A2FC77D5@sankara2.bol.com.br> Modelos prontos de cartas e e-mails comerciais. Visite o site: http://www.gueb.de/cartascomerciais E veja alguns dos modelos abaixo: Procura??o Carta de Recomenda??o Convite para Exposi??o ou Feira AGRADECIMENTOS E CONDOL?NCIAS ? Agradecimento de convite e felicita??es; ? Agradecimento e convite para solenidade; ? Agradecimento de mensagem de p?sames; ? Agradecimento de pedido; ? Agradecimento e boas vindas a cliente novo; ? Agradecimento por mensagem de felicita??o; ? Confraterniza??o; ? Congratula??es; ? Cumprimentos por resultados comerciais; ? Felicita??es pessoais; ? P?sames; http://www.gueb.de/cartascomerciais ? Votos de boas festas Voltar ao topo http://www.gueb.de/cartascomerciais CARTAS DE RECLAMA??O ? Reclama??o de compra de produto; ? Reclama??o por atraso; ? Reclama??o por aumento de pre?o; ? Reclama??o por defici?ncia t?cnica; ? Reclama??o por demora na entrega; ? Reclama??o por diverg?ncia; ? Respostas a reclama??es; Voltar ao topo COMUNICADOS E AVISOS ? Advert?ncia a funcion?rio; ? Aviso de aumento de pre?os; ? Aviso de incorpora??o da empresa; ? Aviso de lan?amento de produto e servi?o; ? Aviso de mudan?a de endere?o; ? Aviso de ocorr?ncia de acidente; ? Aviso de t?rmino de contrato; ? Aviso gen?rico; ? Comunica??o de atraso no envio de mercadorias; ? Comunica??o de devolu??o de duplicata; ? Comunica??o de devolu??o de mercadoria; ? Comunica??o de envio de mercadorias; ? Comunica??o de envio de parte do pedido; ? Comunica??o de extravio de mercadorias; ? Comunica??o de f?rias coletivas; ? Comunica??o de liquida??o de d?bito; ? Comunica??o de novo servi?o de televendas; ? Comunica??o de reuni?o; ? Confirma??o de pedido; ? Resposta ao comunicado de reuni?o; Voltar ao topo http://www.gueb.de/cartascomerciais EMPREGO ? Aviso pr?vio de dispensa de empregado: 1, 2, e 3; ? Carta de recomenda??o; ? Pedido de demiss?o: 1 e 2; ? Solicita??o de emprego: 1, 2 e 3; ? Solicita??o de est?gio; Voltar ao topo ATESTADOS E DECLARA??ES ? Atestado de bons antecedentes; ? Atestado m?dico; ? Declara??o negativa de v?nculo empregat?cio; ? Declara??o para cancelamento de protesto; ? Declara??o para fins escolares; Voltar ao topo * Agradecimentos e condol?ncias * Atestados e Declara??es * Cartas de Cobran?as * Cartas de Reclama??o * Cartas em Ingl?s * Comunicados e Avisos * Convites * Documentos * Emprego * Propostas * Solicita??es e pedidos * Viagem CARTAS DE COBRAN?A ? Cartas de cobran?a: 1, 2, 3, 4, 5, 6, 7 e 8; ? Encaminhamento de cobran?a a protesto; ? Oferecimento de servi?o de cobran?a; ? Recebimento de d?bito pendente; Voltar ao topo CARTAS EM INGL?S ? Cancelamento de pedido; ? Carta de demiss?o; ? Carta de refer?ncia; ? Curriculum vitae; ? Pedido de produto: 1 e 2; ? Reclama??o de assinatura de publica??o; ? Remessa de valores; ? Resposta a pedido de produto; ? Resposta a solicita??o de emprego; ? Resposta a solicita??o de informa??es; ? Resposta a solicita??o de pre?os; ? Solicita??o de emprego; ? Solicita??o de informa??es comerciais; ? Solicita??o de licen?a; ? Solicita??o de pre?os; Voltar ao topo CONVITES http://www.gueb.de/cartascomerciais ? Convite para batizado; ? Convite para evento social; ? Convite para exposi??o ou feira; ? Convite para lan?amento de produto; ? Resposta negativa a convite; ? Resposta positiva a convite; Voltar ao topo DOCUMENTOS ? Ata; ? Contrato de loca??o de im?vel; ? Contrato firmado acordo; ? Contrato social; ? Edital de convoca??o; ? Procura??o; ? Recibo de venda de autom?vel; Voltar ao topo PROPOSTAS ? Proposta de abertura de conta corrente; ? Proposta de presta??o de servi?os: 1 e 2; ? Proposta de representa??o comercial: 1 e 2; ? Proposta para ocupa??o de cargo; ? Proposta para recupera??o de clientes; ? Resposta negativa ? proposta de representa??o: 1 e 2; ? Resposta positiva ? proposta de representa??o: 1 e 2; Voltar ao topo http://www.gueb.de/cartascomerciais SOLICITA??E E PEDIDOS ? Pedido de desculpas; ? Pedido de mercadorias; ? Resposta a pedido de carta de apresenta??o; ? Resposta a solicita??o de c?pias de documentos; ? Resposta a solicita??o de or?amento; ? Resposta negativa a solicita??o de informa??es comerciais; ? Resposta positiva a solicita??o de informa??es comerciais; ? Solicita??o de atestado de Idoneidade Financeira; ? Solicita??o de cat?logos de pre?os; ? Solicita??o de cr?dito; ? Solicita??o de informa??es comerciais; ? Solicita??o de informa??es sobre curso; ? Solicita??o de listas de pre?os; ? Solicita??es de refer?ncias pessoais; ? Suspens?o de pedido de mercadoria; Voltar ao topo VIAGEM ? Informa??es sobre requisitos de viagem; ? Pedido de reserva em hotel; ? Recupera??o de bagagem extraviada; ? Reclama??o de maus tratos ? bagagem; ? Recupera??o de objeto esquecido em hotel; ? Reserva de passagens; ? Roteiro tur?stico. http://www.gueb.de/cartascomerciais From noreply at sourceforge.net Wed Jan 25 07:22:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 22:22:59 -0800 Subject: [Patches] [ python-Patches-1071911 ] Add support for db 4.3 Message-ID: Patches item #1071911, was opened at 2004-11-23 09:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071911&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Michal Čihař (nijel) >Assigned to: Neal Norwitz (nnorwitz) 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. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 22:22 Message: Logged In: YES user_id=33168 Greg added support for 4.3, so this is now out of date. Thanks. It would be great if you can check svn. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-06 03:09 Message: Logged In: YES user_id=192186 Yes, you're right I missed that (or better to say: I looked just at compile time errors). Updated patch with included your hunk. ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2004-12-04 02:14 Message: Logged In: YES user_id=495142 Your patch works well, except for "has_key()". It results False always. This is because an API of DB has changed slightly: DB->get() returns DB_BUFFER_SMALL instead of ENOMEM now. For Modules/_bsddb.c, we need: @@ -2536,7 +2552,11 @@ err = self->db->get(self->db, txn, &key, &data, 0); MYDB_END_ALLOW_THREADS; FREE_DBT(key); +#if (DBVER >= 43) + return PyInt_FromLong((err == DB_BUFFER_SMALL) || (err == 0)); +#else return PyInt_FromLong((err == ENOMEM) || (err == 0)); +#endif } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071911&group_id=5470 From noreply at sourceforge.net Wed Jan 25 16:12:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 07:12:29 -0800 Subject: [Patches] [ python-Patches-1349274 ] [PATCH] 100x optimization for ngettext Message-ID: Patches item #1349274, was opened at 2005-11-05 18:18 Message generated for change (Comment added) made by michaelurman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: Martin v. L??wis (loewis) Summary: [PATCH] 100x optimization for ngettext Initial Comment: Currently gettext.ngettext scans the filesystem whenever you call it. This makes it ridiculously slow. But if one uses gettext.install to initialize gettext, gettext.ngettext is the cleanest way to do plural translation. This patch makes gettext.install install both "_" and "ngettext" into the builtin namespace, which means using "ngettext" won't have to do the filesystem lookup. My benchmarks show this is about 100 times faster. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2006-01-25 09:12 Message: Logged In: YES user_id=1404983 To be overly blunt I think it's ludicrous. I doubt the extraction tools would scan for _.ngettext() like they do for ngettext() (I haven't tested). Also while the builtin namespace is somewhat precious, those using gettext.install need the performance and visual compatibility much more than to avoid setting a builtin that's a fast version of the global/local they would otherwise use. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-24 13:09 Message: Logged In: YES user_id=1188172 Are there opinions about my suggestion? ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-07 15:41 Message: Logged In: YES user_id=796 Well, I did write my own install function; that's the patch you see below. I figured I'd submit it in the interest of other users (that's the point of a standard library, right?) but if the Pythonic thing to do is choose between ugly or slow, I guess I'll just keep using my own. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-07 14:30 Message: Logged In: YES user_id=1188172 I didn't mean to overload the calling of "_", but I can think of "_.gettext()", "_.ngettext()" etc. Of course with "_()" staying the same. Other than that, if you need ngettext in builtins, why don't you write your own install function? ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-06 14:59 Message: Logged In: YES user_id=796 It seems to me that the time to complain about namespace clutter was when gettext.install was written. Besides, it's only "clutter" if you're not using it, and if you're not using it, just don't call install. Making _ dispatch on the number of arguments would break all the existing string extraction tools. It's also unintuitive for anyone coming from gettext in other languages. It's also messy semantic overloading. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-06 13:21 Message: Logged In: YES user_id=1188172 The problem you diagnosed is valid, but I don't think the patch is a proper way to salvage it (by cluttering the builtin namespace). I'd rather have the installed name "_" point to a wrapper object that gives one access to the other translation functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 From noreply at sourceforge.net Wed Jan 25 19:20:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 10:20:25 -0800 Subject: [Patches] [ python-Patches-1402289 ] Fix dictionary subclass semantics when used as global dicts. Message-ID: Patches item #1402289, was opened at 2006-01-11 00:24 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dictionary subclass semantics when used as global dicts. Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-01-25 18:20 Message: Logged In: YES user_id=4771 I will review and check-in your patch, I think it's a good idea despite the added code complexity. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-25 03:38 Message: Logged In: YES user_id=1424288 currently chasing through the PyFrame code and the EXEC_STMT code to make globals generic mappings, will update this patch yet again. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-22 09:19 Message: Logged In: YES user_id=1424288 I've fixed up the exception case, and extended the test case to check for it. Is there anything else I can do to get this in? ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-22 05:11 Message: Logged In: YES user_id=1424288 I'm going to fix the missed exception test this weekend, and try to get an updated patch to you. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-01-14 09:54 Message: Logged In: YES user_id=4771 Provided this can be done with no measurable performance hit, I guess that I'm fine with the idea. The patch needs a bit more work, though: I don't see why it should accept dict subclasses as globals but not arbitrary mappings (as it now does for the locals). This is mainly an issue of removing a few checks in various places, like EXEC_STMT and the eval() and execfile() built-ins. There is a missing exception check/clear in the part about LOAD_NAME, after the PyObject_GetItem(f->f_globals, w). A side note: in the current trunk already, LOAD_GLOBAL contains a couple of checks, namely PyString_CheckExact() and hash != -1. We might be able to prove in advance that these two conditions are always true. We could then remove the checks. Not sure the difference measurable, though. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-12 07:50 Message: Logged In: YES user_id=1424288 Well, why fix it for eval but not for exec? I don't think the time hit is noticeable, I ran 'time make test' twice each on the trunk with and without the patch. Here are the results: Trunk: real 9m17.117s user 3m30.930s sys 0m35.417s real 9m9.471s user 3m31.484s sys 0m34.978s Patch: real 9m32.469s user 3m40.134s sys 0m36.140s real 9m6.779s user 3m27.529s sys 0m34.716s ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-12 06:11 Message: Logged In: YES user_id=21627 I think the history is this: it originates from python.org/sf/215126, which requested that you can pass dict subtypes to eval. Armin noted that eval will always produce LOAD/STORE_NAME, so just modifying these opcodes is sufficient to fulfil the feature request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-12 01:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 23:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 18:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 02:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 02:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Wed Jan 25 21:52:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 12:52:53 -0800 Subject: [Patches] [ python-Patches-1414934 ] Patch for bug #1380970 Message-ID: Patches item #1414934, was opened at 2006-01-25 15:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1414934&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug #1380970 Initial Comment: The split and rsplit methods for both string and unicode types currently do not live up to their documentation. The docs say (quoting from docs.python.org/dev): """ If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends. """ As of svn revision 42185, these methods only strip whitespace from one end. The attached patch makes all four methods (str.split, str.rsplit, unicode.split, unicode.rsplit) remove whitespace from both ends of the string. The patch also modifies Lib/test/string_tests.py to add checks for this to the regression suite. The patch passes the full regression suite. PS: if I could get a review of patch #1412451, that would be smashing. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1414934&group_id=5470 From noreply at sourceforge.net Thu Jan 26 11:34:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Jan 2006 02:34:40 -0800 Subject: [Patches] [ python-Patches-1412872 ] zipfile: use correct system type on unixy systems Message-ID: Patches item #1412872, was opened at 2006-01-23 15:48 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: use correct system type on unixy systems Initial Comment: This patch updates the contructor of zipfile.ZipInfo to initialize the create_system attribute to 3 instead of 0 on systems that are not Windows. Without this patch the unzip command won't honour the file mode that is stored in the zip file. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-01-26 11:34 Message: Logged In: YES user_id=580910 I've updated the patch based on a simular patch by Pete Forman (UID: pete_forman). This version contains a lookup-table of create_systems based on the os.name and also supports some other non-windows systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 From noreply at sourceforge.net Thu Jan 26 16:59:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Jan 2006 07:59:45 -0800 Subject: [Patches] [ python-Patches-1415507 ] Clairify docs on reference stealing Message-ID: Patches item #1415507, was opened at 2006-01-26 10:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1415507&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Clairify docs on reference stealing Initial Comment: The current C API docs (as of r42187) use the term "to steal a reference" but never really pin down what it means. This patch to Doc/api/intro.tex attempts to clairify what is meant by "stealing a reference". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1415507&group_id=5470 From noreply at sourceforge.net Thu Jan 26 17:00:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Jan 2006 08:00:44 -0800 Subject: [Patches] [ python-Patches-1415508 ] optparse enable_interspersed_args disable_interspersed_args Message-ID: Patches item #1415508, was opened at 2006-01-26 11: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=1415508&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rocky Bernstein (rockyb) Assigned to: Nobody/Anonymous (nobody) Summary: optparse enable_interspersed_args disable_interspersed_args Initial Comment: This patch documents that behavior of optparse's enable_interspersed_args and disable_interspersed_args methods by adding docstrings to the methods and by adding information in the Python Library Reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1415508&group_id=5470 From noreply at sourceforge.net Thu Jan 26 17:49:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Jan 2006 08:49:41 -0800 Subject: [Patches] [ python-Patches-1412872 ] zipfile: use correct system type on unixy systems Message-ID: Patches item #1412872, was opened at 2006-01-23 14:48 Message generated for change (Comment added) made by pete_forman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: use correct system type on unixy systems Initial Comment: This patch updates the contructor of zipfile.ZipInfo to initialize the create_system attribute to 3 instead of 0 on systems that are not Windows. Without this patch the unzip command won't honour the file mode that is stored in the zip file. ---------------------------------------------------------------------- Comment By: Pete Forman (pete_forman) Date: 2006-01-26 16:49 Message: Logged In: YES user_id=315964 The merged patch looks good. One extra comment that I'd made was that if os.name is 'java' then a further query of java.lang.System.getProperty("os.name") might be in order. The string returned from that is 'Linux', 'Windows XP' and 'SunOS' on the platforms I can test. A quick search turned up this page: http://lopica.sourceforge.net/os.html On that basis I'd propose a rule that if the Java os.name starts with 'Windows' or 'OS/2' then use 0; if it starts with 'Mac OS' then 7; else 3. Perhaps someone with 'Mac OS X' could pronounce whether it ought to be 3 (UNIX) or 7 (Macintosh). Comments from Jython experts welcome as well. The spec for the ZIP file format is at PKWARE. http://www.pkware.com/business_and_developers/developer/ popups/appnote.txt ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-01-26 10:34 Message: Logged In: YES user_id=580910 I've updated the patch based on a simular patch by Pete Forman (UID: pete_forman). This version contains a lookup-table of create_systems based on the os.name and also supports some other non-windows systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 From noreply at sourceforge.net Fri Jan 27 16:50:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Jan 2006 07:50:08 -0800 Subject: [Patches] [ python-Patches-1416559 ] Configure patch for Mac OS X 10.3 Message-ID: Patches item #1416559, was opened at 2006-01-27 16:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1416559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Configure patch for Mac OS X 10.3 Initial Comment: This patch makes sure that _POSIX_SOURCE and friends won't get defined when you build on Panther. Defining those have no effect on Panther, but will make it impossible to build extensions on a Tiger system when Python itself was build on Panther. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1416559&group_id=5470 From noreply at sourceforge.net Sat Jan 28 02:25:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Jan 2006 17:25:50 -0800 Subject: [Patches] [ python-Patches-1231053 ] audioop - alaw encoding/decoding added, code updated Message-ID: Patches item #1231053, was opened at 2005-07-01 18:04 Message generated for change (Comment added) made by fastflo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231053&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lars Immisch (larsimmisch) Assigned to: Anthony Baxter (anthonybaxter) Summary: audioop - alaw encoding/decoding added, code updated Initial Comment: This patch adds a-LAW encoding to audioop and replaces[1] the old u-LAW encoding/decoding code with the current code from sox. If audioop has an ulaw codec, it should also have an alaw codec. Besides, shtoom wants/needs it. Tests and documentation are updated with this patch too. The patch is a unified diff against CVS that can be applied in one piece frrom the root of the python tree. Beyond the cursory tests in the unittests, I have done successful tests with real-life data. Possible issues: the code from sox uses int16_t. [1] Rationale for the replacement of existing code: the alaw code would have been different in style from the ulaw code and attribution of the code would have been less clear. ---------------------------------------------------------------------- Comment By: Florian Schmidt (fastflo) Date: 2006-01-28 02:25 Message: Logged In: YES user_id=182876 me and the company i'm working for are very interested in this patch. as a german telecomunication service provider we have to deal with alaw all the time... (headerless data) the patch works for us, would be great if it would come into one of the next release's... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-08-12 23:52 Message: Logged In: YES user_id=29957 I'll look at this shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231053&group_id=5470 From noreply at sourceforge.net Sat Jan 28 13:32:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Jan 2006 04:32:41 -0800 Subject: [Patches] [ python-Patches-1411695 ] XML.sax.saxutils.escape -- always escapes <, >, &, Message-ID: Patches item #1411695, was opened at 2006-01-21 21:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: XML >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sandler (msandler) Assigned to: Nobody/Anonymous (nobody) Summary: XML.sax.saxutils.escape -- always escapes <, >, &, Initial Comment: sax.saxutils.escape -- always escapes <, >, &, even if entities are provided. E.g. escape("", {'a':'\a'}) would produce "<\abcd%rt;" instead of "<\abcd>" While it might be expected behaviour, the documentation states "You can escape other strings of data by passing a dictionary as the optional entities parameter. The keys and values must all be strings; each key will be replaced with its corresponding value. " and it is not at all obvious that entities specify _additional_ (to <, >, &) escape strings. It is also impossible to do custom escapes of <,>,& using saxutils.escape. (while custom escapes of < and > might be never necessary for XML, the escape function is general enough to be of interest in other circumstances). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-28 13:32 Message: Logged In: YES user_id=21627 The behaviour is indeed intentional; reclassifying this as a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411695&group_id=5470 From noreply at sourceforge.net Sat Jan 28 20:24:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Jan 2006 11:24:45 -0800 Subject: [Patches] [ python-Patches-1417555 ] have SimpleHTTPServer return last-modified headers Message-ID: Patches item #1417555, was opened at 2006-01-28 13:24 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=1417555&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: have SimpleHTTPServer return last-modified headers Initial Comment: This patch modifies the SimpleHTTPServer to serve Last-Modified headers with its responses, which allows browsers to cache the result, preventing annoying reloads of image files every time you view a page, and so on. Fixes 1417554. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1417555&group_id=5470 From snabelarnold at hotmail.com Mon Jan 30 04:39:01 2006 From: snabelarnold at hotmail.com (arnold ahlstrom) Date: Mon, 30 Jan 2006 04:39:01 +0100 Subject: [Patches] (no subject) Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20060130/8a70f2c8/attachment.html From noreply at sourceforge.net Mon Jan 30 18:08:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 Jan 2006 09:08:39 -0800 Subject: [Patches] [ python-Patches-1402289 ] Allow mappings as globals (was: Fix dictionary subclass ...) Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 Message generated for change (Comment added) made by crutcher_gmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Raymond Hettinger (rhettinger) >Summary: Allow mappings as globals (was: Fix dictionary subclass ...) Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: crutcher (crutcher_gmail) Date: 2006-01-30 09:08 Message: Logged In: YES user_id=1424288 I have reworked and extended this patch so that arbitrary mappings are permitted for globals, not just dictionary subtypes. This touched a good deal more code. Please use the updated version. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-01-25 10:20 Message: Logged In: YES user_id=4771 I will review and check-in your patch, I think it's a good idea despite the added code complexity. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-24 19:38 Message: Logged In: YES user_id=1424288 currently chasing through the PyFrame code and the EXEC_STMT code to make globals generic mappings, will update this patch yet again. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-22 01:19 Message: Logged In: YES user_id=1424288 I've fixed up the exception case, and extended the test case to check for it. Is there anything else I can do to get this in? ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-21 21:11 Message: Logged In: YES user_id=1424288 I'm going to fix the missed exception test this weekend, and try to get an updated patch to you. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-01-14 01:54 Message: Logged In: YES user_id=4771 Provided this can be done with no measurable performance hit, I guess that I'm fine with the idea. The patch needs a bit more work, though: I don't see why it should accept dict subclasses as globals but not arbitrary mappings (as it now does for the locals). This is mainly an issue of removing a few checks in various places, like EXEC_STMT and the eval() and execfile() built-ins. There is a missing exception check/clear in the part about LOAD_NAME, after the PyObject_GetItem(f->f_globals, w). A side note: in the current trunk already, LOAD_GLOBAL contains a couple of checks, namely PyString_CheckExact() and hash != -1. We might be able to prove in advance that these two conditions are always true. We could then remove the checks. Not sure the difference measurable, though. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 23:50 Message: Logged In: YES user_id=1424288 Well, why fix it for eval but not for exec? I don't think the time hit is noticeable, I ran 'time make test' twice each on the trunk with and without the patch. Here are the results: Trunk: real 9m17.117s user 3m30.930s sys 0m35.417s real 9m9.471s user 3m31.484s sys 0m34.978s Patch: real 9m32.469s user 3m40.134s sys 0m36.140s real 9m6.779s user 3m27.529s sys 0m34.716s ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 22:11 Message: Logged In: YES user_id=21627 I think the history is this: it originates from python.org/sf/215126, which requested that you can pass dict subtypes to eval. Armin noted that eval will always produce LOAD/STORE_NAME, so just modifying these opcodes is sufficient to fulfil the feature request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 17:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 15:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 10:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 18:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 18:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Mon Jan 30 20:10:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 Jan 2006 11:10:07 -0800 Subject: [Patches] [ python-Patches-1402289 ] Allow mappings as globals (was: Fix dictionary subclass ...) Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 Message generated for change (Comment added) made by crutcher_gmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: crutcher (crutcher_gmail) Assigned to: Raymond Hettinger (rhettinger) Summary: Allow mappings as globals (was: Fix dictionary subclass ...) Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: crutcher (crutcher_gmail) Date: 2006-01-30 11:10 Message: Logged In: YES user_id=1424288 doh, forgot to check the 'upload' box ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-30 09:08 Message: Logged In: YES user_id=1424288 I have reworked and extended this patch so that arbitrary mappings are permitted for globals, not just dictionary subtypes. This touched a good deal more code. Please use the updated version. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-01-25 10:20 Message: Logged In: YES user_id=4771 I will review and check-in your patch, I think it's a good idea despite the added code complexity. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-24 19:38 Message: Logged In: YES user_id=1424288 currently chasing through the PyFrame code and the EXEC_STMT code to make globals generic mappings, will update this patch yet again. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-22 01:19 Message: Logged In: YES user_id=1424288 I've fixed up the exception case, and extended the test case to check for it. Is there anything else I can do to get this in? ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-21 21:11 Message: Logged In: YES user_id=1424288 I'm going to fix the missed exception test this weekend, and try to get an updated patch to you. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-01-14 01:54 Message: Logged In: YES user_id=4771 Provided this can be done with no measurable performance hit, I guess that I'm fine with the idea. The patch needs a bit more work, though: I don't see why it should accept dict subclasses as globals but not arbitrary mappings (as it now does for the locals). This is mainly an issue of removing a few checks in various places, like EXEC_STMT and the eval() and execfile() built-ins. There is a missing exception check/clear in the part about LOAD_NAME, after the PyObject_GetItem(f->f_globals, w). A side note: in the current trunk already, LOAD_GLOBAL contains a couple of checks, namely PyString_CheckExact() and hash != -1. We might be able to prove in advance that these two conditions are always true. We could then remove the checks. Not sure the difference measurable, though. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 23:50 Message: Logged In: YES user_id=1424288 Well, why fix it for eval but not for exec? I don't think the time hit is noticeable, I ran 'time make test' twice each on the trunk with and without the patch. Here are the results: Trunk: real 9m17.117s user 3m30.930s sys 0m35.417s real 9m9.471s user 3m31.484s sys 0m34.978s Patch: real 9m32.469s user 3m40.134s sys 0m36.140s real 9m6.779s user 3m27.529s sys 0m34.716s ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 22:11 Message: Logged In: YES user_id=21627 I think the history is this: it originates from python.org/sf/215126, which requested that you can pass dict subtypes to eval. Armin noted that eval will always produce LOAD/STORE_NAME, so just modifying these opcodes is sufficient to fulfil the feature request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 17:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 15:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 10:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 18:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 18:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Mon Jan 30 22:54:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 Jan 2006 13:54:43 -0800 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 20:23 Message generated for change (Comment added) made by rbarran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barran (rbarran) Assigned to: Nobody/Anonymous (nobody) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Richard Barran (rbarran) Date: 2006-01-30 22:54 Message: Logged In: YES user_id=1207189 Here is a second version of the 'relpath' function. I've modified it as per Neal Norwitz's comments, with two exceptions: - I've left in a check for a path supplied on input, as otherwise an unclear exception is raised. - I haven't written any test cases for exceptions in ntpath.py, as the "tester" function doesn't seem to handle them. This function (if accepted) will also require the following addition to the documentation: relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from an optional 'start' point. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-21 15:05 Message: Logged In: YES user_id=1207189 Hi all, Going on vacation for a few days, will try to finish this patch for the new year. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 19:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 12:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-17 18:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 13:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 08:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Tue Jan 31 19:35:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jan 2006 10:35:40 -0800 Subject: [Patches] [ python-Patches-1413711 ] difflib exceeding recursion limit Message-ID: Patches item #1413711, was opened at 2006-01-24 13:50 Message generated for change (Settings changed) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1413711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Gustavo Niemeyer (niemeyer) Summary: difflib exceeding recursion limit Initial Comment: difflib is exceeding the default recursion limit in certain patterns of lines. The attached patch will change the problematic method into a non-recursive version. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-01-31 18:35 Message: Logged In: YES user_id=7887 Patch applied as revision 42212. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-01-24 13:53 Message: Logged In: YES user_id=7887 Attaching a test case showing the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1413711&group_id=5470 From noreply at sourceforge.net Tue Jan 31 21:36:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jan 2006 12:36:11 -0800 Subject: [Patches] [ python-Patches-1412872 ] zipfile: use correct system type on unixy systems Message-ID: Patches item #1412872, was opened at 2006-01-23 15:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: use correct system type on unixy systems Initial Comment: This patch updates the contructor of zipfile.ZipInfo to initialize the create_system attribute to 3 instead of 0 on systems that are not Windows. Without this patch the unzip command won't honour the file mode that is stored in the zip file. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-31 21:36 Message: Logged In: YES user_id=21627 I think it is more complicated than that. In version 6.2.2, a value of 19 is assigned to OS/X. There might also be cases when 10 (Windows NTFS) is the right answer; it appears they look at the file system rather than the operating system. HOWEVER, it also says that the value should be 0 if the external file attributes are compatible with DOS and pkzip 2.04g. Perhaps it is a bug in unzip that it doesn't honor the file mode? ---------------------------------------------------------------------- Comment By: Pete Forman (pete_forman) Date: 2006-01-26 17:49 Message: Logged In: YES user_id=315964 The merged patch looks good. One extra comment that I'd made was that if os.name is 'java' then a further query of java.lang.System.getProperty("os.name") might be in order. The string returned from that is 'Linux', 'Windows XP' and 'SunOS' on the platforms I can test. A quick search turned up this page: http://lopica.sourceforge.net/os.html On that basis I'd propose a rule that if the Java os.name starts with 'Windows' or 'OS/2' then use 0; if it starts with 'Mac OS' then 7; else 3. Perhaps someone with 'Mac OS X' could pronounce whether it ought to be 3 (UNIX) or 7 (Macintosh). Comments from Jython experts welcome as well. The spec for the ZIP file format is at PKWARE. http://www.pkware.com/business_and_developers/developer/ popups/appnote.txt ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-01-26 11:34 Message: Logged In: YES user_id=580910 I've updated the patch based on a simular patch by Pete Forman (UID: pete_forman). This version contains a lookup-table of create_systems based on the os.name and also supports some other non-windows systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470