From noreply at sourceforge.net Tue Mar 1 03:20:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Mar 1 03:20:47 2005 Subject: [Patches] [ python-Patches-1151323 ] New fpconst module Message-ID: Patches item #1151323, was opened at 2005-02-24 15:06 Message generated for change (Comment added) made by warnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Warnes (warnes) Assigned to: Nobody/Anonymous (nobody) Summary: New fpconst module Initial Comment: This patch adds the 'fpconst' module, described in PEP754 to the standard python library. It includes both the source code and the documentation. ---------------------------------------------------------------------- >Comment By: Gregory Warnes (warnes) Date: 2005-02-28 21:20 Message: Logged In: YES user_id=9316 Response to etrepum: Actually, I tried using '!' and '>' without success before resorting to the big_endian_ check... -Greg ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-02-24 19:25 Message: Logged In: YES user_id=139309 Is there a reason why you don't use the struct.pack endian markers? You could get rid of all the code that deals with _big_endian if you just prefixed the formats with ! or > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470 From noreply at sourceforge.net Tue Mar 1 03:24:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Mar 1 03:24:56 2005 Subject: [Patches] [ python-Patches-1151323 ] New fpconst module Message-ID: Patches item #1151323, was opened at 2005-02-24 15:06 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Warnes (warnes) Assigned to: Nobody/Anonymous (nobody) Summary: New fpconst module Initial Comment: This patch adds the 'fpconst' module, described in PEP754 to the standard python library. It includes both the source code and the documentation. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-02-28 21:24 Message: Logged In: YES user_id=139309 Maybe you did something wrong, because I tried it and it worked fine. ---------------------------------------------------------------------- Comment By: Gregory Warnes (warnes) Date: 2005-02-28 21:20 Message: Logged In: YES user_id=9316 Response to etrepum: Actually, I tried using '!' and '>' without success before resorting to the big_endian_ check... -Greg ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-02-24 19:25 Message: Logged In: YES user_id=139309 Is there a reason why you don't use the struct.pack endian markers? You could get rid of all the code that deals with _big_endian if you just prefixed the formats with ! or > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470 From noreply at sourceforge.net Tue Mar 1 08:59:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Mar 1 08:59:45 2005 Subject: [Patches] [ python-Patches-1121142 ] ZipFile.open - read-only file-like obj for files in archive Message-ID: Patches item #1121142, was opened at 2005-02-12 01:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alan McIntyre (ESRG) (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: ZipFile.open - read-only file-like obj for files in archive Initial Comment: I originally started working on updating patch 992750, but decided after a short while to just start from scratch, so I'm posting it as a new patch. Sorry if this isn't appropriate. This patch provides a new open() method on ZipFile; this method returns a file-like object for the requested item in the archive. This file-like object only provides a read() method. ZipFile.read was modified to use the new open method (this was suggested by loewis in reference to patch 992750). The patched zipfile.py passed the existing tests in the test_zipfile.py from CVS. New tests were added to verify the operation of the object returned by open(). These tests were modeled after existing tests for ZipFile.read(); two read fixed-size chunks from the file-like object, and two others read random-sized chunks. I have only run the tests on Windows XP, using Python2.4 from the official Windows installer. I will test the patch out on Linux over the weekend. If the patch is accepted I'll also generate and submit patches for the appropriate documentation as well. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-01 08:59 Message: Logged In: YES user_id=21627 The patch is reversed: usually, diff is invoked as "-c old new". I think it is almost right, but I have a few remarks: - by tradition, open() should have a mode argument, defaulting to 'r'; it would be ok to raise exceptions if it is anything else. However, do consider implementing universal newlines; allowing 'b' as a no-op might also be reasonable. - I wonder what happens if the compression rate is < 1. It would appear that the code might use too few rawbytes. I suggest to recursively invoke read in this case. - I wonder whether it could ever happen that there is still data to uncompress in the zlib object, ie. whether it might be necessary to invoke .flush() after exhausting the rawbytes (and discard the zlib object afterwards) - it appears that atleast the builtin file object implements .read(0) as returning an empty string; the manual says that the entire file is meant only if size is omitted or negative. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 07:28 Message: Logged In: YES user_id=1115903 zipfile_patch2.tgz: I updated the file-like object to support readline, readlines, __iter__ and next(). Added tests for those new methods. Also added a patch for the documentation. Passes regression tests on 2.5a0 built from CVS HEAD with MSVC .NET on Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 From noreply at sourceforge.net Tue Mar 1 09:12:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Mar 1 09:12:33 2005 Subject: [Patches] [ python-Patches-1121234 ] Reference count bug fix Message-ID: Patches item #1121234, was opened at 2005-02-12 07:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Martin v. L?wis (loewis) Summary: Reference count bug fix Initial Comment: In the _loadtk method of the class Tk, there are two calls self.tk.createcommand, one for 'tkerror' and one for 'exit'. In the createcommand function in _tkinter.c, there is a Py_XINCREF for the Tk widget and one for the Python function (_tkerror or _exit). The corresponding Py_XDECREFs are called (via Tkapp_DeleteCommand) in PythonCmdDelete. The Tkapp_DeleteCommand is called by the deletecommand in the destroy method of class Misc in Tkinter.py. However, the deletecommand is called only for commands listed in self._tclCommands. Now, if a command is created via the _register method in class Misc, the command is appended to self._tclCommands. However, the 'tkerror' and 'exit' commands, created in the _loadtk method of the class Tk, are not appended to self._tclCommands. Hence, the '_tkerror' and '_exit' functions as well as the Tk widget itself have an incorrect reference count. The Tkapp_Dealloc routine in _tkinter.c is not called and the Tk widget is not destroyed. The attached patch simply adds a self._tclCommands.append for 'tkerror' and 'exit'. With this patch, a Tk widget is destroyed and Tkapp_Dealloc is called correctly. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-01 09:12 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as Tkinter.py 1.182 and 1.181.2.1 NEWS 1.1248 and 1.1193.2.23 I added the test for _tclCommands is None, please verify the code. BTW, how would I make the exit command work? It seems that it does not properly cause a Python exit, but instead causes a TclError. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-28 04:19 Message: Logged In: YES user_id=488897 If we use _register without modification, we'll end up with a different command name: >>> from Tkinter import Label >>> l = Label(text="some text") + Tkinter created command -1214096332_tkerror + Tkinter created command -1208510068_exit + Tkinter created command -1208511348destroy >>> whereas the command names should be "_tkerror", "_exit". We can modify the _register functon so that it takes an optional "name" keyword argument. However, it will mean that we create the command through the CallWrapper instead of the command directly. For "_exit", if I understand the code correctly, it would mean that the raise in _exit is obscured by the raise in CallWrapper, which doesn't seem the right thing. So I would suggest to add a "if self._tclCommands==None:" to the patch instead of going through _register. I'll update the patch if you agree. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 20:27 Message: Logged In: YES user_id=21627 Wouldn't it be better to use _register for _tkerror and _exit as well? This patch overwrites self._tclCommands, but the object may already have a _tclCommands attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 From noreply at sourceforge.net Tue Mar 1 09:12:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Mar 1 09:12:57 2005 Subject: [Patches] [ python-Patches-1121234 ] Reference count bug fix Message-ID: Patches item #1121234, was opened at 2005-02-12 07:02 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Martin v. L?wis (loewis) Summary: Reference count bug fix Initial Comment: In the _loadtk method of the class Tk, there are two calls self.tk.createcommand, one for 'tkerror' and one for 'exit'. In the createcommand function in _tkinter.c, there is a Py_XINCREF for the Tk widget and one for the Python function (_tkerror or _exit). The corresponding Py_XDECREFs are called (via Tkapp_DeleteCommand) in PythonCmdDelete. The Tkapp_DeleteCommand is called by the deletecommand in the destroy method of class Misc in Tkinter.py. However, the deletecommand is called only for commands listed in self._tclCommands. Now, if a command is created via the _register method in class Misc, the command is appended to self._tclCommands. However, the 'tkerror' and 'exit' commands, created in the _loadtk method of the class Tk, are not appended to self._tclCommands. Hence, the '_tkerror' and '_exit' functions as well as the Tk widget itself have an incorrect reference count. The Tkapp_Dealloc routine in _tkinter.c is not called and the Tk widget is not destroyed. The attached patch simply adds a self._tclCommands.append for 'tkerror' and 'exit'. With this patch, a Tk widget is destroyed and Tkapp_Dealloc is called correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-01 09:12 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as Tkinter.py 1.182 and 1.181.2.1 NEWS 1.1248 and 1.1193.2.23 I added the test for _tclCommands is None, please verify the code. BTW, how would I make the exit command work? It seems that it does not properly cause a Python exit, but instead causes a TclError. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-28 04:19 Message: Logged In: YES user_id=488897 If we use _register without modification, we'll end up with a different command name: >>> from Tkinter import Label >>> l = Label(text="some text") + Tkinter created command -1214096332_tkerror + Tkinter created command -1208510068_exit + Tkinter created command -1208511348destroy >>> whereas the command names should be "_tkerror", "_exit". We can modify the _register functon so that it takes an optional "name" keyword argument. However, it will mean that we create the command through the CallWrapper instead of the command directly. For "_exit", if I understand the code correctly, it would mean that the raise in _exit is obscured by the raise in CallWrapper, which doesn't seem the right thing. So I would suggest to add a "if self._tclCommands==None:" to the patch instead of going through _register. I'll update the patch if you agree. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 20:27 Message: Logged In: YES user_id=21627 Wouldn't it be better to use _register for _tkerror and _exit as well? This patch overwrites self._tclCommands, but the object may already have a _tclCommands attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 From noreply at sourceforge.net Tue Mar 1 10:13:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Mar 1 10:13:05 2005 Subject: [Patches] [ python-Patches-931005 ] PEP 309 reference implementation Message-ID: Patches item #931005, was opened at 2004-04-07 12:17 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931005&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Harris (scav) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 309 reference implementation Initial Comment: functional.py Implements partial() as a function, Partial() as a class. Documentation and unit tests to follow ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-03-01 09:13 Message: Logged In: YES user_id=113328 The C implementation of this module (patch 941881) has now been committed. This patch can be closed as no longer required. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931005&group_id=5470 From noreply at sourceforge.net Tue Mar 1 10:14:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Mar 1 10:15:04 2005 Subject: [Patches] [ python-Patches-1121611 ] sha and md5 modules should use OpenSSL when possible Message-ID: Patches item #1121611, was opened at 2005-02-12 17:33 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Gregory P. Smith (greg) Summary: sha and md5 modules should use OpenSSL when possible Initial Comment: The md5 and sha (sha1) modules should use OpenSSL for the algorithms when it is available as its implementations are much faster than pythons own. Attached is an initial patch to use OpenSSL for the sha module. Its not ready for committing as is yet, but it is setup to be a generic base for all OpenSSL hashes with a little bit of work in the future. Tossing this out there for people to see how trivial it is and enjoy the speedups. diff is against HEAD but it should apply to 2.4 just fine. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2005-03-01 01:14 Message: Logged In: YES user_id=413 hashlib-005.patch now passes its test suite and no problems appear in valgrind. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-28 10:11 Message: Logged In: YES user_id=413 a much updated patch (hashlib-patch-004.patch). it incorporates some suggestions as well as including sf patch 935454's sha256/224 and sha512/384 implementations. still not complete but shows the direction its going in (i see a segfault part way thru the test suite after running the sha512 tests). as for the private modules being under another package, i see no reason to do that since there aren't very many (how does that work for binary modules anyways?). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-18 11:21 Message: Logged In: YES user_id=764593 Should the private modules (such as _sha) be placed in a crypto package, instead of directly in the parent/everything library? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-16 22:46 Message: Logged In: YES user_id=413 hashes-openssl-002.patch replaces the sha and md5 modules with a general hashes module that wraps all hashes that OpenSSL supports. note that OpenSSLs implementations are much faster than the previous python versions as it choses versions optimized for your particular hardware. Incase python is compiled without openssl the hashes wrapper falls back on the old python sha and md5 module implementations. side note: This may be sufficient for the Debian folks to work around their random odd licensing issue. just have debian python depend on openssl; use this and remove the old md5 module/code that wouldn't get used anyways. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 From noreply at sourceforge.net Tue Mar 1 14:12:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Mar 1 14:12:50 2005 Subject: [Patches] [ python-Patches-931005 ] PEP 309 reference implementation Message-ID: Patches item #931005, was opened at 2004-04-07 06:17 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931005&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Peter Harris (scav) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 309 reference implementation Initial Comment: functional.py Implements partial() as a function, Partial() as a class. Documentation and unit tests to follow ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-03-01 04:13 Message: Logged In: YES user_id=113328 The C implementation of this module (patch 941881) has now been committed. This patch can be closed as no longer required. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931005&group_id=5470 From noreply at sourceforge.net Tue Mar 1 14:56:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Mar 1 14:56:47 2005 Subject: [Patches] [ python-Patches-1154227 ] Fix for win32 proxy bypass support (no_proxy) in urllib(2) Message-ID: Patches item #1154227, was opened at 2005-03-01 14:56 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=1154227&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mullendr (mullendr) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for win32 proxy bypass support (no_proxy) in urllib(2) Initial Comment: urllib and urllib2 did not support the win32 no_proxy environment variable, nor did they support the proxyOverride windows registry setting. The files that are attached add support for these. ps. this is my first fix, so I hope I am doing this right ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1154227&group_id=5470 From noreply at sourceforge.net Tue Mar 1 19:53:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Mar 1 19:53:30 2005 Subject: [Patches] [ python-Patches-1151323 ] New fpconst module Message-ID: Patches item #1151323, was opened at 2005-02-24 20:06 Message generated for change (Comment added) made by leogah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Warnes (warnes) Assigned to: Nobody/Anonymous (nobody) Summary: New fpconst module Initial Comment: This patch adds the 'fpconst' module, described in PEP754 to the standard python library. It includes both the source code and the documentation. ---------------------------------------------------------------------- Comment By: Richard Brodie (leogah) Date: 2005-03-01 18:53 Message: Logged In: YES user_id=356893 There are some typos in the docstrings: in[i]finity and exponent[ent]. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-03-01 02:24 Message: Logged In: YES user_id=139309 Maybe you did something wrong, because I tried it and it worked fine. ---------------------------------------------------------------------- Comment By: Gregory Warnes (warnes) Date: 2005-03-01 02:20 Message: Logged In: YES user_id=9316 Response to etrepum: Actually, I tried using '!' and '>' without success before resorting to the big_endian_ check... -Greg ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-02-25 00:25 Message: Logged In: YES user_id=139309 Is there a reason why you don't use the struct.pack endian markers? You could get rid of all the code that deals with _big_endian if you just prefixed the formats with ! or > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470 From noreply at sourceforge.net Wed Mar 2 12:59:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 2 12:59:18 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-26 03:05 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Modules Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Raymond Hettinger (rhettinger) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-03-02 20:59 Message: Logged In: YES user_id=671362 "New in version 2.5." statement is missing from the document. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-01 03:02 Message: Logged In: YES user_id=21627 The patch looks good, so please apply. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 23:21 Message: Logged In: YES user_id=80475 Martin, if there are no objections, I'll go ahead an apply this one so we can move on. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-28 21:41 Message: Logged In: YES user_id=1038590 I agree with Raymond - put the basic left-binding partial in place, and we can look at options like partialmethod, rightpartial and so forth that give more control over the positional arguments later. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 14:25 Message: Logged In: YES user_id=80475 * Significantly beefed-up the test suite. * Brought in docs from another patch and heavily editted. * Brought in setup/build code from another patch and enhanced for MSC6.0. * Made attributes read-only and improved their names * Did NOT change dict copy/update logic. * Improved docstring wording * Applied the Py_VISIT macro * Added a NEWS announcement * Added lib.tex Suggest that if Nick wants to add __get__, that it occur separately after this patch is applied. It would be a nice improvement. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 08:05 Message: Logged In: YES user_id=21627 It turns out that the documentation is incorrect, wrt. this patch, as it mentions a non-existing class functional.Partial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 05:43 Message: Logged In: YES user_id=80475 Exposing the structure members for dynamic alteration exceeds the PEP specification. While making the tool more flexible, it slows it down (requiring type checks for every call) and it encourages strange uses. The notion of giving partial objects a changable state is at odds with the basis for functional programming (i.e. statelessness). The traverse function should use the new Py_VISIT macro. The PyCallable_Check() is unnecessary as it duplicates the check already existing in PyObject_Call(). I am not certain whether the PyDict_Copy() is necessary. Calls to f(**d) already pass a copy of d. Likewise, calling f(a=1) will create a new dictionary. If so, that dictionary can be updated in- place with pto->kw rather than creating a new dictionary. None of these issues are critical. Feel free to go forward with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-28 05:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 14:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 12:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 12:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 12:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 12:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 12:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-26 05:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-20 05:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 09:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-04 05:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 13:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 17:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 11:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 04:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Wed Mar 2 15:10:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 2 15:10:37 2005 Subject: [Patches] [ python-Patches-1155083 ] Fix for win32 proxy bypass support (no_proxy) in urllib(2) Message-ID: Patches item #1155083, was opened at 2005-03-02 15: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=1155083&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mullendr (mullendr) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for win32 proxy bypass support (no_proxy) in urllib(2) Initial Comment: urllib and urllib2 did not support the win32 no_proxy environment variable, nor did they support the proxyOverride windows registry setting. The files that are attached add support for these. ps. this is my first fix, so I hope I am doing this right ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1155083&group_id=5470 From noreply at sourceforge.net Thu Mar 3 06:29:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 06:30:08 2005 Subject: [Patches] [ python-Patches-1121234 ] Reference count bug fix Message-ID: Patches item #1121234, was opened at 2005-02-12 15:02 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 Category: Tkinter Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Martin v. L?wis (loewis) Summary: Reference count bug fix Initial Comment: In the _loadtk method of the class Tk, there are two calls self.tk.createcommand, one for 'tkerror' and one for 'exit'. In the createcommand function in _tkinter.c, there is a Py_XINCREF for the Tk widget and one for the Python function (_tkerror or _exit). The corresponding Py_XDECREFs are called (via Tkapp_DeleteCommand) in PythonCmdDelete. The Tkapp_DeleteCommand is called by the deletecommand in the destroy method of class Misc in Tkinter.py. However, the deletecommand is called only for commands listed in self._tclCommands. Now, if a command is created via the _register method in class Misc, the command is appended to self._tclCommands. However, the 'tkerror' and 'exit' commands, created in the _loadtk method of the class Tk, are not appended to self._tclCommands. Hence, the '_tkerror' and '_exit' functions as well as the Tk widget itself have an incorrect reference count. The Tkapp_Dealloc routine in _tkinter.c is not called and the Tk widget is not destroyed. The attached patch simply adds a self._tclCommands.append for 'tkerror' and 'exit'. With this patch, a Tk widget is destroyed and Tkapp_Dealloc is called correctly. ---------------------------------------------------------------------- >Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-03 14:29 Message: Logged In: YES user_id=488897 I tried the CVS version on a few platforms (Cygwin, Mac OS X, Linux) and I found no problems with it. Also the Python test suite didn't reveal any problems. Thanks for looking at this patch. I really appreciate your 5-to-1 patch review offer. To answer your question about the exit command, it may be an attempt to replace Tcl's exit command, so that the Tcl interpreter doesn't exit. But I don't know, really, I don't use Tkinter much. My real interest is the PyOS_InputHook event hook function, which I need to work correctly for a scientific plotting package for Python. While working on a separate patch involving PyOS_InputHook, I noticed that Tkinter doesn't call the DisableEventHook problem. This led me to the reference count problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-01 17:12 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as Tkinter.py 1.182 and 1.181.2.1 NEWS 1.1248 and 1.1193.2.23 I added the test for _tclCommands is None, please verify the code. BTW, how would I make the exit command work? It seems that it does not properly cause a Python exit, but instead causes a TclError. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-28 12:19 Message: Logged In: YES user_id=488897 If we use _register without modification, we'll end up with a different command name: >>> from Tkinter import Label >>> l = Label(text="some text") + Tkinter created command -1214096332_tkerror + Tkinter created command -1208510068_exit + Tkinter created command -1208511348destroy >>> whereas the command names should be "_tkerror", "_exit". We can modify the _register functon so that it takes an optional "name" keyword argument. However, it will mean that we create the command through the CallWrapper instead of the command directly. For "_exit", if I understand the code correctly, it would mean that the raise in _exit is obscured by the raise in CallWrapper, which doesn't seem the right thing. So I would suggest to add a "if self._tclCommands==None:" to the patch instead of going through _register. I'll update the patch if you agree. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 04:27 Message: Logged In: YES user_id=21627 Wouldn't it be better to use _register for _tkerror and _exit as well? This patch overwrites self._tclCommands, but the object may already have a _tclCommands attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 From noreply at sourceforge.net Thu Mar 3 06:35:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 06:35:23 2005 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-13 05:16 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-03 14:35 Message: Logged In: YES user_id=488897 Patch #1121234 (see my previous comment) was accepted and is now included in CVS, clearing the way for this patch. ---------------------------------------------------------------------- Comment By: Dick Madden (dickmadden) Date: 2005-02-14 23:57 Message: Logged In: YES user_id=1219007 I've tried the updated patches with Tkinter and my rasmol extension using the new inputhooks scheme and everything seems to be coexisting just fine. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-12 15:27 Message: Logged In: YES user_id=488897 Richard Madden was kind enough to test the patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff. This led to the discovery of two bugs in my patch and one preexisting bug in Tkinter.py. For this second bug, I submitted a separate patch (#1121234). I uploaded a fixed patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff; together with patch #1121234 the input hooks appear to be working correctly. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-08 17:53 Message: Logged In: YES user_id=488897 I have written a patch that solves this problem more generally via PyOS_InputHook, as suggested by Noam. This patch also solves the related bugs #1053687, #798058, and supersedes patch #1049855. The patch is available at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff Currently, the EventHook function sits in a loop handling Tcl events until keyboard input is detected. The presence of Tcl events is checked every Tkinter_busywaitinterval milliseconds. If a Tcl event arrives during this interval, it won't be handled until the end of the interval. However, with the default value of Tkinter_busywaitinterval = 20 milliseconds, that delay is not noticable. Now consider the situation in which there can be more than one input hook, for example set by different extension modules. We cannot have EventHook sit in a loop until keyboard input is detected, because that would prevent other PyOS_InputHooks from being serviced. So in the EventHook in the patch, the function returns immediately after handling all Tcl events. If we use Python from the command line and open a Tkinter label: >>> from Tkinter import * >>> l = Label() then readline will call PyOS_InputHook ten times per second while Python is idle. Because PyOS_InputHook points to EventHook, we will return to the EventHook function almost immediately. Effectively, we are then in the same situation as before the patch. On Cygwin, however, previously mainloop needed to be run in order for the label to appear; this is no longer necessary with this patch. On Windows, currently PyOS_InputHook is partially broken, as it is called only once per command instead of ten times per second. This patch fixed that also (same as patch #1049855). If we have two or more input hooks, they are called successively by readline. Since each input hook returns after it has no more work to do, all of the input hooks are guaranteed to be serviced. To be able to have more than one input hook, we need to replace PyOS_InputHook by three functions: PyOS_AddInputHook, PyOS_RemoveInputHook, and PyOS_CallInputHooks. For the third function, the corresponding Python function call_input_hooks was created in the readline module. By adding a call to readline.call_input_hooks in run.py, as suggested by Noam, all input hook functions are serviced when IDLE is idle. So we can use Tkinter without calling mainloop, and we can use other extension packages that use input hooks. We can even do both: >>> import Tkinter >>> import gist # my extension module also needs input hooks >>> Tkinter.Label() # label appears >>> gist.window() # Graphics window appears. works both with command-line python and IDLE. I'm interested to hear your comments and suggestions. If this patch seems like the way to go, I'd be happy to write the documentation for it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-04 22:08 Message: Logged In: YES user_id=488897 I agree, this is basically the same bug as #798058. The call to readline.call_input_hook sounds like a good solution. But the hook function should be different than the current EventHook in _tkinter.c. That hook function sits in a loop until a keyboard event is noticed. A problem occurs if there is more than one hook function. Currently, that is not possible in Python, since there is only one PyOS_InputHook. I am working on a patch in which PyOS_InputHook is replaced by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there can be more than one hook functions. Now suppose that there is one hook function to handle Tk events, and another one e.g. handling messages to windows in Microsoft Windows. (This is a real issue for one of my extension modules). If python sits in a loop in _tkinter.c's EventHook until a key is pressed, the MS windows won't get their messages. The following structure might work better: while(there is no keyboard input or other interesting event) { Call PyOS_InputHook #1 Call PyOS_InputHook #2 etc. } where each of the PyOS_InputHook functions should return if there is no more work for them. The tricky part is to find out which events to wait for; some of the events may be handled by one of the PyOS_InputHook functions. Obviously I need to do some more thinking about this. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-04 10:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 20:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-15 05:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Thu Mar 3 09:06:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 09:06:17 2005 Subject: [Patches] [ python-Patches-1075147 ] Flush stdout/stderr if closed (fix for bug 1074011) Message-ID: Patches item #1075147, was opened at 2004-11-29 11:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075147&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Nobody/Anonymous (nobody) Summary: Flush stdout/stderr if closed (fix for bug 1074011) Initial Comment: This sets the close function pointers for sys.stdout and sys.stderr to point to fflush rather than be NULL, so that if a program explicitly closes stdout or stderr it can detect a write error then. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 09:06 Message: Logged In: YES user_id=21627 Closing as out-of-date. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 18:01 Message: Logged In: YES user_id=1115903 This change already seems to have been made (in a slightly different form), and the referenced bug is closed out. Recommend closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075147&group_id=5470 From noreply at sourceforge.net Thu Mar 3 09:08:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 09:08:33 2005 Subject: [Patches] [ python-Patches-977553 ] Speed up EnumKey call Message-ID: Patches item #977553, was opened at 2004-06-22 17:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up EnumKey call Initial Comment: This patch removes the RegQueryInfoKey call and replaces it with a call to EnumKeyEx. This greatly speeds up this call. The script below times python 2.3 5531 89.7130000591 python 2.4 +patch 5531 0.0469999313354 start = time.time() i = 0 try: while 1: _winreg.EnumKey(_winreg.HKEY_CLASSES_ROOT, i) i += 1 except WindowsError: pass print i, time.time() - start ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 09:08 Message: Logged In: YES user_id=21627 garth42, can you please indicate whether you are willing to work on the patch, and if so in what time frame? ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 17:59 Message: Logged In: YES user_id=1115903 I think it's a good idea to get 16-bit Windows functions out of Python per Microsoft's recommendation, especially when doing so can also help performance. It looks like this patch still needs some cleanup and a test or two. If nobody else wants to do it I can probably finish it up. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:31 Message: Logged In: YES user_id=21627 Also, please follow the Python style guide for C code, PEP 7. In particular: - use tabs for indentation, with a tab being worth 8 spaces - omit spaces after opening and before closing parens - put the opening brace of a code block on the same line as the keyword ---------------------------------------------------------------------- Comment By: Garth Bushell (garth42) Date: 2004-07-14 18:12 Message: Logged In: YES user_id=45280 mmangino: Yes you're correct it should be 256 in both cases. Doh! I'll attach a new patch in a while. but It's easy to mmodify the patch and up the linit to 256 theller: The advantage of the latter is it returns the Length of the string returned so we can pass it straight back to the string creation funtion in python without a strlen. also the SDK says this.... Note This function is provided only for compatibility with 16-bit versions of Windows. Applications should use the RegEnumKeyEx function. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-14 17:54 Message: Logged In: YES user_id=11105 I'm curious: Why did you replace RegEnumKey with RegEnumKeyEx? Are there any advantages of the latter? ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-14 16:12 Message: Logged In: YES user_id=74879 This looks good to me, but I think the buffer size is off by one. I read the SDK to say tha they key can be 255 characters. That means you need to allocate 256 characters to allow for the null terminator. Could you create a test case for a max length registry key? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 From noreply at sourceforge.net Thu Mar 3 09:13:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 09:13:59 2005 Subject: [Patches] [ python-Patches-1104111 ] setup.py --help and --help-commands altered. Message-ID: Patches item #1104111, was opened at 2005-01-17 20:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104111&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py --help and --help-commands altered. Initial Comment: (discussed on the distutils-sig list) Altered --help output to give some example commands up front. Altered --help-commands to give a clearer description of 'clean'. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 09:13 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as dist.py 1.73 clean.py 1.17 NEWS 1.1249 NOT backported to 2.4, as this doesn't fix a bug. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 18:03 Message: Logged In: YES user_id=1115903 This doesn't break anything, adds some helpful content to the help text, and got one 1+ (and no negative comments) over on distutils-sig: http://mail.python.org/pipermail/distutils-sig/2005-January/004378.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104111&group_id=5470 From noreply at sourceforge.net Thu Mar 3 09:18:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 09:19:01 2005 Subject: [Patches] [ python-Patches-1107973 ] tarfile.ExFileObject iterators Message-ID: Patches item #1107973, was opened at 2005-01-23 22:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107973&group_id=5470 Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.ExFileObject iterators Initial Comment: Since Python 2.2 it has been possible to iterate over the lines of a file object (PEP 234). This patch provides line-by-line iterators for TarFile.extractfile. The attachment contains forward diffs for both Lib/tarfile.py and Lib/test/test_tarfile.py. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 09:18 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as tarfile.py 1.24 test_tarfile.py 1.17 NEWS 1.1250 ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 07:10 Message: Logged In: YES user_id=1115903 The patch seems to work as advertised; all regression tests pass when run against 2.5a0 (CVS HEAD, built with MSVC .NET) + this patch on Windows XP. Improving the file-likeness of ExFileObject seems like a good idea to me, so I'm all for seeing this get accepted. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107973&group_id=5470 From noreply at sourceforge.net Thu Mar 3 09:38:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 09:38:41 2005 Subject: [Patches] [ python-Patches-1110248 ] patch for gzip.GzipFile.flush() Message-ID: Patches item #1110248, was opened at 2005-01-26 22:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110248&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David Schnepper (dschnepper) Assigned to: Nobody/Anonymous (nobody) Summary: patch for gzip.GzipFile.flush() Initial Comment: Ensure the compress buffer is flushed prior to the file buffer being flushed when gzip.GzipFile.flush() is invoked. Patch for bug 1110242 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 09:38 Message: Logged In: YES user_id=21627 Thanks for the patch. I believe it does not fully fix the bug reported: not all input data are flushed with Z_SYNC_FLUSH, but only some (up to an output byte boundary or some such). I also believe that a "complete" fix for the bug is not possible, as flushing all input data would require Z_FINISH, and then no more additional data could be written into the stream. As this is still an improvement over the current status, I committed it as gzip.py 1.43 NEWS 1.1251 ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 05:36 Message: Logged In: YES user_id=1115903 This patch appears to fix the bug as described, and running the regression tests on Python 2.5a0 (CVS HEAD) turns up no problems. Since the documentation says that a GzipFile "simulates most of the methods of a file object," I would expect GzipFile.flush() to act in the way that David described in the first paragraph of the bug report, and his patch seems to provide that as far as I can tell. Note: I only ran tests on Python 2.5a0 built with MSVC .NET on Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110248&group_id=5470 From noreply at sourceforge.net Thu Mar 3 10:27:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 10:27:22 2005 Subject: [Patches] [ python-Patches-723201 ] PyArg_ParseTuple problem with 'L' format Message-ID: Patches item #723201, was opened at 2003-04-17 18:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723201&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTuple problem with 'L' format Initial Comment: PyArg_ParseTuple(tup, "B", &value) will raise 'Bad Argument to internal function' if the object is not a Python integer or long. I believe the patch fixes the problem, but it is untested. This problem probably exists since 2.2. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 10:27 Message: Logged In: YES user_id=21627 I agree that the proposed double-type check is redundant. OTOH, relying on the exception in the _As* function loses information which argument specifically cannot be converted. As a solution, I now clear the exception before invoking converterr. Fixed in test_capi.py 1.8.2.1 NEWS 1.1193.2.24 getargs.c 2.102.2.1 test_capi.py 1.9 NEWS 1.1252 getargs.c 2.103 ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-20 06:15 Message: Logged In: YES user_id=488897 The PyLong_AsLongLong function (in Objects/longobject.c) also contains a call to PyLong_Check and PyInt_Check, so I would think that there is no need for another call to a PyLong_Check and a PyInt_Check. Instead, I would suggest to replace the PyErr_BadInternalCall() (which raises the 'Bad Argument to internal function') in PyLong_AsLongLong by PyErr_SetString(PyExc_TypeError, "an integer is required"). This would also make it consistent with PyInt_AsLong in Objects/intobject.c. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-19 05:04 Message: Logged In: YES user_id=488897 I can replicate this bug with the "L" format but not with "B". Is the 'B' in PyArg_ParseTuple(tup, "B", &value) a typo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723201&group_id=5470 From noreply at sourceforge.net Thu Mar 3 10:28:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 10:28:42 2005 Subject: [Patches] [ python-Patches-1155083 ] Fix for win32 proxy bypass support (no_proxy) in urllib(2) Message-ID: Patches item #1155083, was opened at 2005-03-02 15:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1155083&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: mullendr (mullendr) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for win32 proxy bypass support (no_proxy) in urllib(2) Initial Comment: urllib and urllib2 did not support the win32 no_proxy environment variable, nor did they support the proxyOverride windows registry setting. The files that are attached add support for these. ps. this is my first fix, so I hope I am doing this right ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 10:28 Message: Logged In: YES user_id=21627 Actually, this is your second fix; the first one was #1154227 :-) Closing this as a duplicate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1155083&group_id=5470 From noreply at sourceforge.net Thu Mar 3 10:34:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 10:34:23 2005 Subject: [Patches] [ python-Patches-1154227 ] Fix for win32 proxy bypass support (no_proxy) in urllib(2) Message-ID: Patches item #1154227, was opened at 2005-03-01 14:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1154227&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mullendr (mullendr) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for win32 proxy bypass support (no_proxy) in urllib(2) Initial Comment: urllib and urllib2 did not support the win32 no_proxy environment variable, nor did they support the proxyOverride windows registry setting. The files that are attached add support for these. ps. this is my first fix, so I hope I am doing this right ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 10:34 Message: Logged In: YES user_id=21627 Please don't send the full files as a patch. Instead, use "diff" or (better) "cvs diff" to create a patch, see http://www.python.org/patches/ http://www.python.org/dev/devfaq.html#patches I notice that your patch contains no changes to Doc/lib/liburllib.tex; please add them as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1154227&group_id=5470 From noreply at sourceforge.net Thu Mar 3 10:36:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 10:36:39 2005 Subject: [Patches] [ python-Patches-981773 ] crach link c++ extension by mingw Message-ID: Patches item #981773, was opened at 2004-06-29 08:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981773&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: crach link c++ extension by mingw Initial Comment: if cource of exttension module writen in C++ setup break and say: cc -mno-cygwin -shared -s build\temp.win32-2.3 \Release\dybaseapi.o build\temp.win32-2.3\Release\..\src\btree.o build\temp.win32-2.3\Release\..\src\database.o build\temp.win32-2.3\Release\..\src\dybase.o build\temp.win32-2.3\Release\..\src\file.o build\temp.win32-2.3\Release\..\src\pagepool.o build\temp.win32-2.3\Release\dybaseapi.def -LC:\Lang\Python23\libs -LC:\Lang\Python23\PCBuild -lpython23 -o build\lib.win32-2.3\dybaseapi.pyd error: command 'cc' failed: No such file or directory I patch cygwinccompiler.py for resolve: *** C:\Lang\Python23\work\Python-2.3.4 \Lib\distutils\cygwinccompiler.py Mon Apr 14 19:51:26 2003 --- C:\Lang\Python23\work\cygwinccompiler2.py Tue Jun 29 13:00:23 2004 *************** *** 108,113 **** --- 108,114 ---- # XXX optimization, warnings etc. should be customizable. self.set_executables(compiler='gcc -mcygwin -O - Wall', compiler_so='gcc -mcygwin - mdll -O -Wall', + compiler_cxx='g++ -mcygwin -O - Wall', linker_exe='gcc -mcygwin', linker_so=('%s -mcygwin %s' % (self.linker_dll, shared_option))) *************** *** 295,300 **** --- 296,302 ---- self.set_executables(compiler='gcc -mno- cygwin -O -Wall', compiler_so='gcc -mno-cygwin - mdll -O -Wall', + compiler_cxx='g++ -mno-cygwin - O -Wall', linker_exe='gcc -mno-cygwin', linker_so='%s -mno-cygwin %s % s' % (self.linker_dll, shared_option, ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 10:36 Message: Logged In: YES user_id=21627 Apparently, shura_zam silently agrees that the problem was solved, rejecting the patch as outdated. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-30 10:59 Message: Logged In: YES user_id=488897 It seems that this bug has been fixed in Python 2.4. Using this Python version: '2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)]' a C++ extension compiled correctly with mingw32. Could you check if the compilation error still occurs with Python 2.4? Compilation still fails with Python 2.3.5c1, but I doubt that this bug can be fixed before the final 2.3.5 release. ---------------------------------------------------------------------- Comment By: Kef Li Eric MARCVS X (furrykef) Date: 2004-08-20 19:33 Message: Logged In: YES user_id=536129 I do hope this patch is integrated. As it is, I'm going to have to tell my users to patch distutils by hand... ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-08-07 16:29 Message: Logged In: YES user_id=2772 Please attach your diff, rather than pasting it into the text box. The diff is hopelessly mangled, and cannot be applied for testing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981773&group_id=5470 From noreply at sourceforge.net Thu Mar 3 10:47:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 10:47:15 2005 Subject: [Patches] [ python-Patches-1112812 ] Patch for Lib/bsddb/__init__.py to work with modulefinder Message-ID: Patches item #1112812, was opened at 2005-01-31 00:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1112812&group_id=5470 Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Patch for Lib/bsddb/__init__.py to work with modulefinder Initial Comment: The Python 2.4 Lib/bsddb/__init__.py contains this: """ # for backwards compatibility with python versions older than 2.3, the # iterator interface is dynamically defined and added using a mixin # class. old python can't tokenize it due to the yield keyword. if sys.version >= '2.3': exec """ import UserDict from weakref import ref class _iter_mixin(UserDict.DictMixin): ... """ Because the imports are inside an exec, modulefinder (e.g. when using bsddb with a py2exe built application) does not realise that the imports are required. (The requirement can be manually specified, of course, if you know that you need to do so). There are two options for easy fixes for this: 1. Move the imports outside the exec. This wouldn't effect the code at all, but would let modulefinder know that they were there. 2. If 2.1 compatibility isn't required for the bsddb module in Python 2.5, then the if and exec portion could be completely removed. Patches against today's anon CVS for each of these options are attached. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 10:47 Message: Logged In: YES user_id=21627 Thanks for the patch. As Barry has not bumped the backwards compatibility requirements for bsddb yet, I went with your option 1, and committed it as __init__.py 1.15.4.1 NEWS 1.1193.2.25 __init__.py 1.16 NEWS 1.1253 ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-01-31 00:25 Message: Logged In: YES user_id=552329 Martin v. L?wis (on python-dev) indicated that Barry or Greg Ward would be the appropriate person to decide which was the correct option, so changing assignment to Barry. Apologies if is this not correct! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1112812&group_id=5470 From noreply at sourceforge.net Thu Mar 3 11:42:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 11:42:22 2005 Subject: [Patches] [ python-Patches-1028908 ] Changes to cookielib.py & friends for 2.4b1 Message-ID: Patches item #1028908, was opened at 2004-09-16 02:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to cookielib.py & friends for 2.4b1 Initial Comment: The patch contains uncontroversial changes to cookielib and associated modules, documentation and tests. Would be unfortunate not to have these in 2.4.0. 1. Changes to keep cookielib in sync with ClientCookie 1.0 release. This will make life simpler for people migrating from ClientCookie (the package from whence cookielib, and some recent urllib2 changes, came). a. Moved country-code pseudo-top-level domain (eg. .co.uk) code into a separate method of DefaultCookiePolicy to make life easier for subclassers (.set_ok_countrycode_domain()). b. Added Cookie.nonstandard_attr_keys() method. 2. Added a new test. 3. Documentation corrections and clarifications (including adding a prominent warning about current lack of thread-safety, and a new example). 4. Small-scale refactoring in cookielib.py (including moving magic_re to its rightful place in _LWPCookieJar.py). 5. Tiny code clarification in urllib2.py. 6. Removed coding declaration from test_cookielib.py, in favour of escape sequences, since I discovered that I don't understand coding declarations :-/ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 11:42 Message: Logged In: YES user_id=21627 I'm closing the patch right away; please submit new ones. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-06 03:19 Message: Logged In: YES user_id=261020 The problem with the thread issue is that -- as I drew attention to when the module was considered for addition to stdlib -- there is thread synchronization in there, but it is untested, and I now strongly suspect is broken. I'm not thread-competent enough to be confident in my testing of any fix I might attempt. I now regret not simply stripping all the thread synchronization out from the start. Perhaps that should be done now, and a comment like that you suggest added? Advice here is most welcome! Re the rest: As per my last comment, will resubmit API changes (ie. method additions) as separate patch for 2.5. I'll split the rest up into separate patches, too. Therefore, I'm unassigning Jeremy and will close this patch when I've opened the new ones. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-05 15:42 Message: Logged In: YES user_id=80475 Applied the urllib2 portion as Lib/urllib2.py 1.80. Leaving the rest for Jeremy to see if he finds sufficient improvement to warrant API changes. FWIW, I think the thread-safety comment should be omitted or reworded positively (i.e. resource locks are needed when cookielib is used in a multi-threaded environment). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-05 13:54 Message: Logged In: YES user_id=261020 New method (actually, there are two, I see on re-checking -- (a) and (b) in my list above): understood. Will submit revised patch without them, and a separate patch for 2.5 with only the new methods. Docs: I have verified that none of these are unnecessary rewordings. Some are fixes for typos or bad English. Most of the rest are of minor clarifications or corrections, but are solid improvements. Please point out specific changes whose value you doubt, and I will explain (or remove if persuaded, of course)! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-05 02:43 Message: Logged In: YES user_id=80475 A new method is not okay for 2.4.1. The doc changes should be reviewed carefully. At first glance, some appear to be unnecessary rewordings that do not add new new information. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-12-23 13:35 Message: Logged In: YES user_id=261020 Yes, it's safe for 2.4.1. There's one new method, but I guess that's OK? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-12-22 15:41 Message: Logged In: YES user_id=31392 Is it safe to add these as bug fixes for 2.4.1? It looks okay to me, but I wanted to be sure that wasn't some API change that was signficant. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 08:35 Message: Logged In: YES user_id=23486 Applied patch & ran 'make test' under Linux with latest from CVS. Everything works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 From noreply at sourceforge.net Thu Mar 3 11:48:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 11:48:40 2005 Subject: [Patches] [ python-Patches-1117339 ] cookielib and cookies with special names Message-ID: Patches item #1117339, was opened at 2005-02-06 16:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117339&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib and cookies with special names Initial Comment: cookielib's Netscape cookies parser, parse_ns_headers(), treats Netscape cookies whose names happen to match one of the special cookie-attribute names as if they were a cookie-attribute rather than a cookie name=value pair. Eg. Set-Cookie: expires="foo" Here, expires is the cookie name, not a special expires cookie-attribute. The patch includes two new tests, a patch to cookielib.py and a fix to an existing test. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 11:48 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as cookielib.py 1.4.2.2 test_cookielib.py 1.1.4.1 NEWS 1.1193.2.26 cookielib.py 1.8 test_cookielib.py 1.2 NEWS 1.1254 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117339&group_id=5470 From noreply at sourceforge.net Thu Mar 3 11:58:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 11:58:21 2005 Subject: [Patches] [ python-Patches-1117454 ] cookielib.LWPCookieJar incorrectly loads value-less cookies Message-ID: Patches item #1117454, was opened at 2005-02-06 20:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117454&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib.LWPCookieJar incorrectly loads value-less cookies Initial Comment: cookielib.LWPCookieJar contains a couple of lines of code left over from an earlier incarnation of the module in which cookies like Set-Cookie: foo were treated as name-less instead of value-less. This causes corruption on loading such cookies from LWP format files. The patch fixes this bug and a similar relic that did not cause an actual bug. It also adds a comment, and a new test. Should be backported to 2.4 maintenance branch. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 11:58 Message: Logged In: YES user_id=21627 _LWPCookieJar.py 1.2.2.1 _MozillaCookieJar.py 1.3.2.1 cookielib.py 1.4.2.3 test_cookielib.py 1.1.4.2 NEWS 1.1193.2.27 _LWPCookieJar.py 1.3 _MozillaCookieJar.py 1.4 cookielib.py 1.9 test_cookielib.py 1.3 NEWS 1.1255 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117454&group_id=5470 From noreply at sourceforge.net Thu Mar 3 12:03:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 12:03:50 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 18:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) 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: Martin v. L?wis (loewis) Date: 2005-03-03 12: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 19: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 17: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 23: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 17: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 Thu Mar 3 12:09:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 12:09:24 2005 Subject: [Patches] [ python-Patches-1046831 ] Consistent retrieval of Python version. Message-ID: Patches item #1046831, was opened at 2004-10-14 08:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1046831&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: uiltje (tuijldert) Assigned to: Raymond Hettinger (rhettinger) Summary: Consistent retrieval of Python version. Initial Comment: sysconfig.py: Sometimes 'sys.version' is used, sometimes 'get_python_version()'. This patch makes it consistent. Python: V2.3.4 OS: OpenVMS V7.3-2 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 12:09 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as sysconfig.py 1.63 NEWS 1.1256 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1046831&group_id=5470 From noreply at sourceforge.net Thu Mar 3 12:24:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 12:24:29 2005 Subject: [Patches] [ python-Patches-1144555 ] allow UNIX mmap size to default to current file size (new) Message-ID: Patches item #1144555, was opened at 2005-02-19 23:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144555&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: allow UNIX mmap size to default to current file size (new) Initial Comment: see patch #749830: """ This patch makes the UNIX mmap behave like the Windows mmap in that if you pass 0 as the mmap size, the map size will default to the current length of the file being mmapped. This allows avoids a call to os.stat if you want to map the entire file. It also makes code using this feature of the Windows mmap to be portable to UNIX. """ This new patch applies cleanly on current CVS HEAD. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 12:24 Message: Logged In: YES user_id=21627 Thanks for the patches, committed as libmmap.tex 1.11 test_mmap.py 1.31 test_mmap 1.10 NEWS 1.1257 mmapmodule.c 2.49 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144555&group_id=5470 From noreply at sourceforge.net Thu Mar 3 12:24:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 12:24:36 2005 Subject: [Patches] [ python-Patches-749830 ] allow UNIX mmap size to default to current file size Message-ID: Patches item #749830, was opened at 2003-06-06 00:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749830&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: allow UNIX mmap size to default to current file size Initial Comment: This patch makes the UNIX mmap behave like the Windows mmap in that if you pass 0 as the mmap size, the map size will default to the current length of the file being mmapped. This allows avoids a call to os.stat if you want to map the entire file. It also makes code using this feature of the Windows mmap to be portable to UNIX. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 12:24 Message: Logged In: YES user_id=21627 Thanks for the patches, I have applied #1144555 as libmmap.tex 1.11 test_mmap.py 1.31 test_mmap 1.10 NEWS 1.1257 mmapmodule.c 2.49 I'm not backporting it to 2.4 as this is a new feature. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 19:31 Message: Logged In: YES user_id=1188172 see new patch #1144555 which applies cleanly on today's CVS HEAD. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-23 15:10 Message: Logged In: YES user_id=250749 Tested on FreeBSD 4.8 & 5.1 - updated test_mmap passes. I don't have any mmap reliant code to check more thoroughly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749830&group_id=5470 From noreply at sourceforge.net Thu Mar 3 12:40:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 12:40:45 2005 Subject: [Patches] [ python-Patches-645894 ] better timer resolution for profile.py Message-ID: Patches item #645894, was opened at 2002-11-30 01:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645894&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John-Mark Gurney (jmg) Assigned to: Nobody/Anonymous (nobody) Summary: better timer resolution for profile.py Initial Comment: On some platforms time.clock() does not return a high resolution counter. On FreeBSD, it's resolution is only 1/128th of a second. In order to get microsecond accuracy, the getrusage syscall from resource needs to be used. Attached is a patch that uses getrusage from the resource library in preference of os.clock. This was done on behalf of Vernier Networks, Inc. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 12:40 Message: Logged In: YES user_id=21627 I believe getrusage is always the better choice, as clock() wraps around after 36 minutes on a POSIX system. Committed as profile.py 1.62 NEWS 1.1258 ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 19:28 Message: Logged In: YES user_id=1188172 If this leads to better resolution on FreeBSD, it seems like a good idea. However, if you don't know about other OS, what about restricting the patch to FreeBSD? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 22:28 Message: Logged In: YES user_id=357491 Is there any possibility that using this could lead to worse timing under another OS? And I assume this is still an issue under FreeBSD 5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645894&group_id=5470 From noreply at sourceforge.net Thu Mar 3 12:46:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 12:46:34 2005 Subject: [Patches] [ python-Patches-802188 ] better parser error message for non-EOL following line cont. Message-ID: Patches item #802188, was opened at 2003-09-08 02:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=802188&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mathieu Fenniak (laotzu0) Assigned to: Nobody/Anonymous (nobody) Summary: better parser error message for non-EOL following line cont. Initial Comment: This small patch adds a specific error message for when a line continuation character (\) is followed by something other than a newline. If the character following the \ is whitespace, it can be difficult to see why it is an 'invalid token' as the error message used to say. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 12:46 Message: Logged In: YES user_id=21627 Thanks for the patch and the review. Committed as errcode.h 2.17 NEWS 1.1259 tokenizer.c 2.77 pythonrun.c 2.212 ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 19:30 Message: Logged In: YES user_id=1188172 While this may be helpful when the invalid token is whitespace, Python usually shows the exact location of the invalid token, so you can examine this line and find the error. On the other hand, the patch is no big deal, so if a specific error message is welcome, it may as well be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=802188&group_id=5470 From noreply at sourceforge.net Thu Mar 3 13:29:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 13:29:10 2005 Subject: [Patches] [ python-Patches-723201 ] PyArg_ParseTuple problem with 'L' format Message-ID: Patches item #723201, was opened at 2003-04-17 18:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723201&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTuple problem with 'L' format Initial Comment: PyArg_ParseTuple(tup, "B", &value) will raise 'Bad Argument to internal function' if the object is not a Python integer or long. I believe the patch fixes the problem, but it is untested. This problem probably exists since 2.2. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 13:29 Message: Logged In: YES user_id=21627 Turns out that this approach breaks cases where PyLong_AsLongLong returns OverflowErrors; it also turns out that test_getargs2 is the place where the getargs tests are implemented. So I reverted the previous patch, implemented nb_int conversion for longs, and committed this as test_capi.py 1.8.2.2 test_getargs2.py 1.5.12.1 longobject.c 1.165.2.1 getargs.c 2.102.2.2 test_capi.py 1.10 test_getargs2.py 1.6 longobject.c 1.166 getargs.c 2.104 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 10:27 Message: Logged In: YES user_id=21627 I agree that the proposed double-type check is redundant. OTOH, relying on the exception in the _As* function loses information which argument specifically cannot be converted. As a solution, I now clear the exception before invoking converterr. Fixed in test_capi.py 1.8.2.1 NEWS 1.1193.2.24 getargs.c 2.102.2.1 test_capi.py 1.9 NEWS 1.1252 getargs.c 2.103 ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-20 06:15 Message: Logged In: YES user_id=488897 The PyLong_AsLongLong function (in Objects/longobject.c) also contains a call to PyLong_Check and PyInt_Check, so I would think that there is no need for another call to a PyLong_Check and a PyInt_Check. Instead, I would suggest to replace the PyErr_BadInternalCall() (which raises the 'Bad Argument to internal function') in PyLong_AsLongLong by PyErr_SetString(PyExc_TypeError, "an integer is required"). This would also make it consistent with PyInt_AsLong in Objects/intobject.c. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-19 05:04 Message: Logged In: YES user_id=488897 I can replicate this bug with the "L" format but not with "B". Is the 'B' in PyArg_ParseTuple(tup, "B", &value) a typo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723201&group_id=5470 From noreply at sourceforge.net Thu Mar 3 15:26:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 15:26:51 2005 Subject: [Patches] [ python-Patches-1107221 ] Updated "Working on Cygwin" section Message-ID: Patches item #1107221, was opened at 2005-01-22 08:40 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107221&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alan Green (alanvgreen) Assigned to: Nobody/Anonymous (nobody) Summary: Updated "Working on Cygwin" section Initial Comment: Updated the "Working on Cygwin" section to correct package Cygwin names (they had changed over the years) and included some additional notes on building netpbm and LaTeX2HTML. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 15:26 Message: Logged In: YES user_id=1188172 Patch looks good (no typos etc.) and should be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107221&group_id=5470 From noreply at sourceforge.net Thu Mar 3 15:36:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 15:36:48 2005 Subject: [Patches] [ python-Patches-731328 ] AssertionError when building rpm under RedHat 9.1 Message-ID: Patches item #731328, was opened at 2003-05-02 14:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731328&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ricardo Niederberger Cabral (niederberger) Assigned to: Nobody/Anonymous (nobody) Summary: AssertionError when building rpm under RedHat 9.1 Initial Comment: When trying to build an rpm on RH 9: >From distutils __version__ = "1.0.3": File "distutils/command/bdist_rpm.py", line 316, in run assert len(rpms) == 1, AssertionError: unexpected number of RPM files found: ['build/bdist. linux-i686/rpm/RPMS/i386/imgSeek-0.7-1.i386.rpm', 'build/bdist. linux-i686/rpm/RPMS/i386/imgSeek-debuginfo-0.7-1.i386.rpm'] I had to remove the assert statement on bdist_rpm.py:316 in order to build my rpm since rpmbuild from RH always seems to generate this extra -debuginfo rpm. So attached is a patch (cvs rev 1.37) to simply copy all generated RPM's to the dist/ directory. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 15:36 Message: Logged In: YES user_id=1188172 Does anyone still care about this issue? Or, other way round, does anything speak against applying and so copying all RPMs? ---------------------------------------------------------------------- Comment By: Ricardo Niederberger Cabral (niederberger) Date: 2003-05-28 03:59 Message: Logged In: YES user_id=354686 Sorry for not replying faster and providing more info. SF tracker didn't email me about your comment, and I don't have the RH system at hand right now. Anyway, it generates: foo-version.i386.rpm foo-version.src.rpm foo-debuginfo-version.i386.rpm instead of only the binary and src rpm's I would get on Mandrake 9 for example, which is what bdist_rpm.py currently expects. I don't know exactly what goes inside this debug-info rpm, but i guess it's probably the binary one compiled with debug symbols on. I can provide more info if necessary in a few days. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-03 13:01 Message: Logged In: YES user_id=21627 Can you provide more information? What rpm gets generated, and what files does it contain? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731328&group_id=5470 From noreply at sourceforge.net Thu Mar 3 15:46:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 15:46:20 2005 Subject: [Patches] [ python-Patches-748843 ] Let Email.Utils.parsedate use last 3 timetuple items Message-ID: Patches item #748843, was opened at 2003-06-04 15:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748843&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let Email.Utils.parsedate use last 3 timetuple items Initial Comment: Hi, this patch changes the behaviour of Email.Utils.parsedate. Currently, the last 3 tuple items are unused. One place where this complicates things unnecessarily is when trying to find out the week number: currently, it is necessary to convert the tuple back and forth to a timestamp by hand, in order to retrieve the information in the last 3 items. This patch fixes this, and makes the default behaviour to use all timetuple fields. It also changes the corresponding documentation. I also sent this to patches@python.org when SF was down. Gerrit. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 15:46 Message: Logged In: YES user_id=1188172 The patch returns time.localtime(time.mktime(t[:9])) instead of t[:9] This does affect speed if you don't need the last 3 fields, and you always can call localtime(mktime(...)) in your code if you need them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748843&group_id=5470 From noreply at sourceforge.net Thu Mar 3 15:48:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 15:48:34 2005 Subject: [Patches] [ python-Patches-738094 ] for i in range(N) optimization Message-ID: Patches item #738094, was opened at 2003-05-15 09:14 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: Later Priority: 2 Submitted By: Sebastien Keim (s_keim) Assigned to: Guido van Rossum (gvanrossum) Summary: for i in range(N) optimization Initial Comment: This patch is intended to special case the built-in range function in the common "for i in range(...):" construct. The goal is to make range() return an iterator instead of creating a real list, and then being able to depreciate the xrange type. It has once been suggested to make the compiler aware of the "for i in range(N):" construct and to make it able to produce optimized bytecode. But this solution is really hard to achieve because you have to ensure that the range built-in is not overridden. The patch take an opposite approach: it let the range built-in function looks at its execution context, and return an iterator if the next frame opcode to be executed is the GET_ITER opcode. Speed increase for the piece of code "for i in range(N): pass" : N (speed gain) 10 (+ 64%) 100 (+ 29%) 1000 (+ 23%) 10000 (+ 68%) 100000 (+108%) Since the patch only affect a small construct of the language, performance improvements for real applications are less impressive but they are still interesting: pystone.py (+7%) test_userstring.py (+8%) test_datetime.py (+20%) Note that the performance loss for "A = range(10)" is not measurable (less than 1%). If the patch is accepted, the same recipe may be applicable in some few other places. So the Py_IsIterationContext function must probably live somewhere else (is there a standard location for byte-code dependent stuff?). Maybe other opcodes (for sample JUMP_IF_FALSE) could provide other useful specialization contexts. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 15:48 Message: Logged In: YES user_id=1188172 I don't know if I fully understand, but doesn't it suffice to just use xrange()? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-11 12:07 Message: Logged In: YES user_id=4771 Here is a safer patch. It adds a keyword argument 'iter' to range(), e.g.: >>> range(10, iter=True) and using an appropriate METH_XXX flag, the CALL_FUNCTION opcode now inserts a 'iter=True' keyword to the call when it is followed by GET_ITER. The patch doesn't live up to its performance promizes. I don't get any improvement at all on any real application. The only example it accelerates is a set of three nested loops :-( I still attach it for reference, and if someone else want to play with it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-09 18:22 Message: Logged In: YES user_id=6380 In the sake of stability for Python 2.3's accelerated release schedule, I'm postponing this until after 2.3. I'm also skeptical that it ca be absolutely correct. What if there is Python code of the form for i in some_function(): ... where some_function() is a C extension that at some point invokes range(), directly from C. Then when range() peeks in the opcode stream, it would believe that it was being called in the place of some_function(). So maybe I should just reject it as unsafe? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-18 23:18 Message: Logged In: YES user_id=6380 I'm interested, but have to ponder more, which will have to wait until I'm back from vacation. I expect that any hope to deprecate xrange() will prove naive -- people will want to pass ranges around between functions or reuse them (e.g. this happens a lot in timing tests). Maybe in Python 3.0 I can make range() act as an iterator generator. You'd have to say list(range(N)) to get an actual list then. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:25 Message: Logged In: YES user_id=80475 Assigning to Guido to see whether he is interested because it makes xrange less necessary or whether he thinks it is a horrendous hack --or maybe both ;-) ---------------------------------------------------------------------- Comment By: Sebastien Keim (s_keim) Date: 2003-05-15 17:14 Message: Logged In: YES user_id=498191 I have also thought about slicing, map and filter which could all be replaced by itertools equivalents , but I have failed to find a way to ensure that the argument lists aren't mutated during the for loop. Maybe it could be interesting to investigate into copy on write semantic for lists objects? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-15 16:33 Message: Logged In: YES user_id=80475 zip() would benefit greatly from your approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 From noreply at sourceforge.net Thu Mar 3 15:57:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 15:57:17 2005 Subject: [Patches] [ python-Patches-764221 ] add set/getattr interface to tkFont.Font objects Message-ID: Patches item #764221, was opened at 2003-07-01 23:21 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764221&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: add set/getattr interface to tkFont.Font objects Initial Comment: A simple patch to add the dictionary style get/set attribute interface to tkFont.Font objects. This makes it act like almost all other Tkinter classes. Perhaps best saved for Python 2.4, but it's such a simple change I thought it might squeak by. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 15:57 Message: Logged In: YES user_id=1188172 Patch looks good (a very minor change), so it will be OK to apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764221&group_id=5470 From noreply at sourceforge.net Thu Mar 3 16:05:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 16:05:10 2005 Subject: [Patches] [ python-Patches-1009389 ] Non-ascii in non-unicode __credits__ in Lib/pydoc.py Message-ID: Patches item #1009389, was opened at 2004-08-15 03:35 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Non-ascii in non-unicode __credits__ in Lib/pydoc.py Initial Comment: There are non-ASCII chars in pydoc.__credits__ (the "o/" in "Mynd you, mo/o/se bites Kan be pretty nasti..."). In 2.3, a locale declaration of Latin-1 was added to pydoc.py. So now Python does not complain -- but a string object (carrying no encoding info) with Latin-1 bytes is still created and anynoby running in a non-Latin-1 locale will not interpret the string correctly. The patch fixes it by making pydoc.__credits__ a Unicode string. *Note that this may break code* that prints pydoc.__credits__ (in locales that can't encode it) or otherwise assumes it's a string. Not that such code exists anywhere... Wait, ``import pydoc; help(pydoc)`` in "C" locale now crashes ! This is too ironic, IMHO, *don't commit* until pydoc learns to handle unicode robustly... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 16:05 Message: Logged In: YES user_id=1188172 The moose comment has been removed; the patch should be closed as "out of date". ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2004-11-17 12:44 Message: Logged In: YES user_id=45338 I'm so sorry this has caused so much trouble. The silly moose comment is my fault; it can just be removed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-14 11:21 Message: Logged In: YES user_id=21627 Ok, I have now backed-out the patch again. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-11-14 02:39 Message: Logged In: YES user_id=36166 I told you not to commit! Now ``pydoc.py pydoc`` crashes. Patch 1065986 fixes this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 18:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as pydoc.py 1.96. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 From noreply at sourceforge.net Thu Mar 3 16:18:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 16:18:17 2005 Subject: [Patches] [ python-Patches-784089 ] A program to scan python files and list those require coding Message-ID: Patches item #784089, was opened at 2003-08-06 12:47 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Raymond Hettinger (rhettinger) Summary: A program to scan python files and list those require coding Initial Comment: A program to scan python files (recursively) and list those that require coding directive (pseudocomment) because there non-ASCII characters in the file (including comments). The program treats files as python files if the extension is .py or there is "python" in the first line of the file. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 16:18 Message: Logged In: YES user_id=1188172 The script only checks for "-*- coding", while the docs state that the correct regex is "coding[=:]\s*([-\w.]+)". In the pysource.py, I don't know if it is useful to open the file and check the first line for "python". Normally, Python files should be given the extension .py, so there is a great probability of false positives. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-17 20:52 Message: Logged In: YES user_id=4799 Added pysource.py module and an alternative implementation using the module. The pysource.py module is, probably, of a general interest and can be added to the standard library. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 08:04 Message: Logged In: YES user_id=80475 Will make a few cleanups, replace the recursion and fileext guessing to a glob.glob format, and will add to Tools/scripts. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 09:49 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 23:50 Message: Logged In: YES user_id=11375 So, does something need to be done with this script, like adding it to the distribution? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-06 14:36 Message: Logged In: YES user_id=38388 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 From noreply at sourceforge.net Thu Mar 3 16:23:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 16:24:00 2005 Subject: [Patches] [ python-Patches-1069624 ] incomplete support for AF_PACKET in socketmodule.c Message-ID: Patches item #1069624, was opened at 2004-11-19 20:00 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1069624&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: incomplete support for AF_PACKET in socketmodule.c Initial Comment: A comment in the source documents the AF_PACKET address format: - an AF_PACKET socket address is a tuple containing a string specifying the ethernet interface and an integer specifying the Ethernet protocol number to be received. For example: ("eth0",0x1234). Optional 3rd,4th,5th elements in the tuple specify packet-type and ha-type/addr -- these are ignored by networking code, but accepted since they are returned by the getsockname() method. The part that says "these are ignored by networking code," is clearly innacurate when comparing with the packet(7) man page: "(...)Packets sent through a SOCK_DGRAM packet socket get a suitable physical layer header based on the information in the sockaddr_ll destination address before they are queued.(...)" Attached patch copies the passed in addr into the sockaddr structure. It is against Python 2.3.4. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 16:23 Message: Logged In: YES user_id=1188172 >From the patch: + addr->sll_halen = hatype; + addr->sll_halen = halen; This doesn't seem to make sense, so the upper line can be removed. Also, you are mixing tabs and spaces. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-11-19 20:19 Message: Logged In: YES user_id=908 And just now I actually tested this patch. It works! While before the ethernet frame was sent with broadcast destination address, now it goes with a correct destination address. This should go into python 2.3.x as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1069624&group_id=5470 From noreply at sourceforge.net Thu Mar 3 16:29:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 16:29:22 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-26 03:05 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Modules Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Raymond Hettinger (rhettinger) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-03-04 00:29 Message: Logged In: YES user_id=671362 > Noted that the module is new in version 2.5. Thanks, Raymond. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-03-02 20:59 Message: Logged In: YES user_id=671362 "New in version 2.5." statement is missing from the document. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-01 03:02 Message: Logged In: YES user_id=21627 The patch looks good, so please apply. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 23:21 Message: Logged In: YES user_id=80475 Martin, if there are no objections, I'll go ahead an apply this one so we can move on. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-28 21:41 Message: Logged In: YES user_id=1038590 I agree with Raymond - put the basic left-binding partial in place, and we can look at options like partialmethod, rightpartial and so forth that give more control over the positional arguments later. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 14:25 Message: Logged In: YES user_id=80475 * Significantly beefed-up the test suite. * Brought in docs from another patch and heavily editted. * Brought in setup/build code from another patch and enhanced for MSC6.0. * Made attributes read-only and improved their names * Did NOT change dict copy/update logic. * Improved docstring wording * Applied the Py_VISIT macro * Added a NEWS announcement * Added lib.tex Suggest that if Nick wants to add __get__, that it occur separately after this patch is applied. It would be a nice improvement. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 08:05 Message: Logged In: YES user_id=21627 It turns out that the documentation is incorrect, wrt. this patch, as it mentions a non-existing class functional.Partial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 05:43 Message: Logged In: YES user_id=80475 Exposing the structure members for dynamic alteration exceeds the PEP specification. While making the tool more flexible, it slows it down (requiring type checks for every call) and it encourages strange uses. The notion of giving partial objects a changable state is at odds with the basis for functional programming (i.e. statelessness). The traverse function should use the new Py_VISIT macro. The PyCallable_Check() is unnecessary as it duplicates the check already existing in PyObject_Call(). I am not certain whether the PyDict_Copy() is necessary. Calls to f(**d) already pass a copy of d. Likewise, calling f(a=1) will create a new dictionary. If so, that dictionary can be updated in- place with pto->kw rather than creating a new dictionary. None of these issues are critical. Feel free to go forward with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-28 05:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 14:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 12:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 12:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 12:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 12:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 12:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-26 05:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-20 05:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 09:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-04 05:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 13:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 17:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 11:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 04:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Thu Mar 3 16:31:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 16:31:08 2005 Subject: [Patches] [ python-Patches-1009389 ] Non-ascii in non-unicode __credits__ in Lib/pydoc.py Message-ID: Patches item #1009389, was opened at 2004-08-15 02:35 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Non-ascii in non-unicode __credits__ in Lib/pydoc.py Initial Comment: There are non-ASCII chars in pydoc.__credits__ (the "o/" in "Mynd you, mo/o/se bites Kan be pretty nasti..."). In 2.3, a locale declaration of Latin-1 was added to pydoc.py. So now Python does not complain -- but a string object (carrying no encoding info) with Latin-1 bytes is still created and anynoby running in a non-Latin-1 locale will not interpret the string correctly. The patch fixes it by making pydoc.__credits__ a Unicode string. *Note that this may break code* that prints pydoc.__credits__ (in locales that can't encode it) or otherwise assumes it's a string. Not that such code exists anywhere... Wait, ``import pydoc; help(pydoc)`` in "C" locale now crashes ! This is too ironic, IMHO, *don't commit* until pydoc learns to handle unicode robustly... ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-03-03 15:31 Message: Logged In: YES user_id=6656 Done! ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 15:05 Message: Logged In: YES user_id=1188172 The moose comment has been removed; the patch should be closed as "out of date". ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2004-11-17 11:44 Message: Logged In: YES user_id=45338 I'm so sorry this has caused so much trouble. The silly moose comment is my fault; it can just be removed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-14 10:21 Message: Logged In: YES user_id=21627 Ok, I have now backed-out the patch again. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-11-14 01:39 Message: Logged In: YES user_id=36166 I told you not to commit! Now ``pydoc.py pydoc`` crashes. Patch 1065986 fixes this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 17:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as pydoc.py 1.96. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470 From noreply at sourceforge.net Thu Mar 3 16:35:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 16:35:06 2005 Subject: [Patches] [ python-Patches-784089 ] A program to scan python files and list those require coding Message-ID: Patches item #784089, was opened at 2003-08-06 12:47 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Raymond Hettinger (rhettinger) Summary: A program to scan python files and list those require coding Initial Comment: A program to scan python files (recursively) and list those that require coding directive (pseudocomment) because there non-ASCII characters in the file (including comments). The program treats files as python files if the extension is .py or there is "python" in the first line of the file. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 16:35 Message: Logged In: YES user_id=1188172 Also, perhaps there could be another mode of operation in which the files in question are checked if they need an encoding declaration anyways. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 16:18 Message: Logged In: YES user_id=1188172 The script only checks for "-*- coding", while the docs state that the correct regex is "coding[=:]\s*([-\w.]+)". In the pysource.py, I don't know if it is useful to open the file and check the first line for "python". Normally, Python files should be given the extension .py, so there is a great probability of false positives. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-17 20:52 Message: Logged In: YES user_id=4799 Added pysource.py module and an alternative implementation using the module. The pysource.py module is, probably, of a general interest and can be added to the standard library. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 08:04 Message: Logged In: YES user_id=80475 Will make a few cleanups, replace the recursion and fileext guessing to a glob.glob format, and will add to Tools/scripts. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 09:49 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 23:50 Message: Logged In: YES user_id=11375 So, does something need to be done with this script, like adding it to the distribution? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-06 14:36 Message: Logged In: YES user_id=38388 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 From noreply at sourceforge.net Thu Mar 3 16:41:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 16:41:39 2005 Subject: [Patches] [ python-Patches-784089 ] A program to scan python files and list those require coding Message-ID: Patches item #784089, was opened at 2003-08-06 14:47 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Raymond Hettinger (rhettinger) Summary: A program to scan python files and list those require coding Initial Comment: A program to scan python files (recursively) and list those that require coding directive (pseudocomment) because there non-ASCII characters in the file (including comments). The program treats files as python files if the extension is .py or there is "python" in the first line of the file. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2005-03-03 18:41 Message: Logged In: YES user_id=4799 Thank you for pointing the regex. I fixed both programs. But you are wrong about .py extension. A python module really can only has .py extension, but a python program may has any, for example, .cgi, or no extension at all. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 18:35 Message: Logged In: YES user_id=1188172 Also, perhaps there could be another mode of operation in which the files in question are checked if they need an encoding declaration anyways. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 18:18 Message: Logged In: YES user_id=1188172 The script only checks for "-*- coding", while the docs state that the correct regex is "coding[=:]\s*([-\w.]+)". In the pysource.py, I don't know if it is useful to open the file and check the first line for "python". Normally, Python files should be given the extension .py, so there is a great probability of false positives. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-17 22:52 Message: Logged In: YES user_id=4799 Added pysource.py module and an alternative implementation using the module. The pysource.py module is, probably, of a general interest and can be added to the standard library. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 10:04 Message: Logged In: YES user_id=80475 Will make a few cleanups, replace the recursion and fileext guessing to a glob.glob format, and will add to Tools/scripts. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 11:49 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-08 01:50 Message: Logged In: YES user_id=11375 So, does something need to be done with this script, like adding it to the distribution? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-06 16:36 Message: Logged In: YES user_id=38388 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 From noreply at sourceforge.net Thu Mar 3 16:42:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 16:43:00 2005 Subject: [Patches] [ python-Patches-784089 ] A program to scan python files and list those require coding Message-ID: Patches item #784089, was opened at 2003-08-06 14:47 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Raymond Hettinger (rhettinger) Summary: A program to scan python files and list those require coding Initial Comment: A program to scan python files (recursively) and list those that require coding directive (pseudocomment) because there non-ASCII characters in the file (including comments). The program treats files as python files if the extension is .py or there is "python" in the first line of the file. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2005-03-03 18:42 Message: Logged In: YES user_id=4799 Sorry for my poor English. "Can have" and "may have"... ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-03 18:41 Message: Logged In: YES user_id=4799 Thank you for pointing the regex. I fixed both programs. But you are wrong about .py extension. A python module really can only has .py extension, but a python program may has any, for example, .cgi, or no extension at all. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 18:35 Message: Logged In: YES user_id=1188172 Also, perhaps there could be another mode of operation in which the files in question are checked if they need an encoding declaration anyways. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 18:18 Message: Logged In: YES user_id=1188172 The script only checks for "-*- coding", while the docs state that the correct regex is "coding[=:]\s*([-\w.]+)". In the pysource.py, I don't know if it is useful to open the file and check the first line for "python". Normally, Python files should be given the extension .py, so there is a great probability of false positives. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-17 22:52 Message: Logged In: YES user_id=4799 Added pysource.py module and an alternative implementation using the module. The pysource.py module is, probably, of a general interest and can be added to the standard library. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 10:04 Message: Logged In: YES user_id=80475 Will make a few cleanups, replace the recursion and fileext guessing to a glob.glob format, and will add to Tools/scripts. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 11:49 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-08 01:50 Message: Logged In: YES user_id=11375 So, does something need to be done with this script, like adding it to the distribution? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-06 16:36 Message: Logged In: YES user_id=38388 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 From noreply at sourceforge.net Thu Mar 3 18:29:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 18:29:36 2005 Subject: [Patches] [ python-Patches-1096231 ] Fix for wm_iconbitmap to allow .ico files under Windows. Message-ID: Patches item #1096231, was opened at 2005-01-05 05:09 Message generated for change (Comment added) made by janc13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096231&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Fouhy (johnfouhy) Assigned to: Martin v. L?wis (loewis) Summary: Fix for wm_iconbitmap to allow .ico files under Windows. Initial Comment: Tk 8.4 adds a -default option to wm iconbitmap to better support Microsoft Windows. Here is the link: http://www.tcl.tk/man/tcl8.4/TkCmd/wm.htm#M18 This is the relevant information: "On the Windows operating system, an additional flag is supported: wm iconbitmap window ?-default? ?image?. If the -default flag is given, the icon is applied to all toplevel windows (existing and future) to which no other specific icon has yet been applied. In addition to bitmap image types, a full path specification to any file which contains a valid Windows icon is also accepted (usually .ico or .icr files), or any file for which the shell has assigned an icon. Tcl will first test if the file contains an icon, then if it has an assigned icon, and finally, if that fails, test for a bitmap." This patch modifies Tkinter.py so that wm_iconbitmap supports a 'default' keyword parameter which, if used, will make the appropriate Tk call. This allows you to change your Tkinter application icons under Windows with one line of code :-) (and no need for tkIcon, hakicon, etc) For the record: I am running Windows XP Professional SP2 and Python 2.3.4. ---------------------------------------------------------------------- Comment By: Jan Claeys (janc13) Date: 2005-03-03 18:29 Message: Logged In: YES user_id=412240 I have successfully tested this with Python 2.3.5 & Python 2.4 on Windows 2000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096231&group_id=5470 From noreply at sourceforge.net Thu Mar 3 19:57:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 19:57:05 2005 Subject: [Patches] [ python-Patches-1156102 ] exception doc updates Message-ID: Patches item #1156102, was opened at 2005-03-03 18:57 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=1156102&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: exception doc updates Initial Comment: I was going to bang on the exception docs until I discovered that they are already somewhat out-of-date. This updates the reference manual to describe exceptions with the presumption that class exceptions are the default, and string exceptions are subsidiary and deprecated. I'll probably check this in soon unless someone complains :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1156102&group_id=5470 From noreply at sourceforge.net Thu Mar 3 22:15:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 22:15:12 2005 Subject: [Patches] [ python-Patches-1121611 ] sha and md5 modules should use OpenSSL when possible Message-ID: Patches item #1121611, was opened at 2005-02-12 17:33 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Gregory P. Smith (greg) Summary: sha and md5 modules should use OpenSSL when possible Initial Comment: The md5 and sha (sha1) modules should use OpenSSL for the algorithms when it is available as its implementations are much faster than pythons own. Attached is an initial patch to use OpenSSL for the sha module. Its not ready for committing as is yet, but it is setup to be a generic base for all OpenSSL hashes with a little bit of work in the future. Tossing this out there for people to see how trivial it is and enjoy the speedups. diff is against HEAD but it should apply to 2.4 just fine. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2005-03-03 13:15 Message: Logged In: YES user_id=413 hashlib-006.patch adds fast constructors and a speed test. documentation is the next step. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-01 01:14 Message: Logged In: YES user_id=413 hashlib-005.patch now passes its test suite and no problems appear in valgrind. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-28 10:11 Message: Logged In: YES user_id=413 a much updated patch (hashlib-patch-004.patch). it incorporates some suggestions as well as including sf patch 935454's sha256/224 and sha512/384 implementations. still not complete but shows the direction its going in (i see a segfault part way thru the test suite after running the sha512 tests). as for the private modules being under another package, i see no reason to do that since there aren't very many (how does that work for binary modules anyways?). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-18 11:21 Message: Logged In: YES user_id=764593 Should the private modules (such as _sha) be placed in a crypto package, instead of directly in the parent/everything library? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-16 22:46 Message: Logged In: YES user_id=413 hashes-openssl-002.patch replaces the sha and md5 modules with a general hashes module that wraps all hashes that OpenSSL supports. note that OpenSSLs implementations are much faster than the previous python versions as it choses versions optimized for your particular hardware. Incase python is compiled without openssl the hashes wrapper falls back on the old python sha and md5 module implementations. side note: This may be sufficient for the Debian folks to work around their random odd licensing issue. just have debian python depend on openssl; use this and remove the old md5 module/code that wouldn't get used anyways. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 From noreply at sourceforge.net Thu Mar 3 23:25:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 3 23:25:40 2005 Subject: [Patches] [ python-Patches-1156102 ] exception doc updates Message-ID: Patches item #1156102, was opened at 2005-03-03 19:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1156102&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: exception doc updates Initial Comment: I was going to bang on the exception docs until I discovered that they are already somewhat out-of-date. This updates the reference manual to describe exceptions with the presumption that class exceptions are the default, and string exceptions are subsidiary and deprecated. I'll probably check this in soon unless someone complains :) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 23:25 Message: Logged In: YES user_id=21627 Overall, the patch looks fine. One note though: in the first chunk, what about the information that you can also pass an object in the raise, in addition to the type? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1156102&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:01:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:01:07 2005 Subject: [Patches] [ python-Patches-1115086 ] support PY_LONGLONG in structmember Message-ID: Patches item #1115086, was opened at 2005-02-02 23:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115086&group_id=5470 Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sam Rushing (rushing) Assigned to: Nobody/Anonymous (nobody) Summary: support PY_LONGLONG in structmember Initial Comment: Adds signed/unsigned PY_LONG_LONG support to structmember. Need this at IronPort for Pyrex extensions that need 64-bit slots. I'm submitting a matching small patch for Pyrex. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 00:01 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as structmember.h 2.23 NEWS 1.1261 structmember.c 2.25 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115086&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:02:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:02:21 2005 Subject: [Patches] [ python-Patches-1111653 ] HEAD/PUT/DELETE support for urllib2.py Message-ID: Patches item #1111653, was opened at 2005-01-28 19:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1111653&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Terrel Shumway (drurl) Assigned to: Nobody/Anonymous (nobody) Summary: HEAD/PUT/DELETE support for urllib2.py Initial Comment: urllib2 only supports GET or POST HTTP request methods. This patch adds support for other methods. >>> import urllib2 >>> r = urllib2.Request("http://jdiworks.net/",method="HEAD") >>> u = urllib2.urlopen(r) >>> u.read() '' >>> h = u.headers.getheader >>> h("content-length") '4754' >>> h("accept-ranges") 'bytes' >>> h("date") 'Fri, 28 Jan 2005 18:39:04 GMT' >>> h("etag") '"728074-1292-314c1c40"' >>> h("last-modified") 'Thu, 01 Jul 2004 23:11:37 GMT' TODO: fix 3xx redirect with a HEAD ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 00:02 Message: Logged In: YES user_id=21627 As there is still no uploaded file, I'm closing the patch as invalid. Please resubmit a new patch when you have one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-29 14:37 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. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1111653&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:03:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:03:52 2005 Subject: [Patches] [ python-Patches-1110205 ] patch for idlelib Message-ID: Patches item #1110205, was opened at 2005-01-26 21:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110205&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sowjanya (sowjanya) >Assigned to: Kurt B. Kaiser (kbk) Summary: patch for idlelib Initial Comment: We are using the Filelist class from idlelib to create Python syntax aware source code editor in our applications. In order to be able to embed the code editor window into a Tk graphical user interface and specify the width and height of the editor (in lines and columns) we had to modify the EditorWidow and ScriptBinding classes to accept a 'top' argument (container in which to create the editor), and 'width' and 'height' arguments. We are submitting the patches for your consideration to be included into the next release of idlelib1.2a0. The patches were generated using the following command: diff -c old new ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 00:03 Message: Logged In: YES user_id=21627 Kurt, can you please take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110205&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:08:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:08:16 2005 Subject: [Patches] [ python-Patches-1107221 ] Updated "Working on Cygwin" section Message-ID: Patches item #1107221, was opened at 2005-01-22 08:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107221&group_id=5470 Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Alan Green (alanvgreen) Assigned to: Nobody/Anonymous (nobody) Summary: Updated "Working on Cygwin" section Initial Comment: Updated the "Working on Cygwin" section to correct package Cygwin names (they had changed over the years) and included some additional notes on building netpbm and LaTeX2HTML. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 00:08 Message: Logged In: YES user_id=21627 Thanks for the patch and the review. Committed as doc.tex 1.92 and 1.90.2.2. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 15:26 Message: Logged In: YES user_id=1188172 Patch looks good (no typos etc.) and should be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107221&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:15:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:15:32 2005 Subject: [Patches] [ python-Patches-1103407 ] tarfile.py: fix for bug #1100429 Message-ID: Patches item #1103407, was opened at 2005-01-16 18:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103407&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: fix for bug #1100429 Initial Comment: On platforms like Win32 which don't support symbolic and hard links, link extraction from a tar archive is simulated: If the link points to a file inside the archive this file is extracted instead of the link. In Greg's case the referenced file comes after the link in the archive which is the reason why iteration breaks: at the point in iteration when the referenced file is needed it is still unknown to the TarFile object which will then search the whole archive exhausting the iterator itself. The patch fixes the TarIter class, so it is able to notice if the TarFile has already loaded all members between two iteration steps. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 00:15 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as NEWS 1.1262 and 1.1193.2.29 tarfile.py 1.25 and 1.21.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103407&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:43:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:43:57 2005 Subject: [Patches] [ python-Patches-1094387 ] os.py: base class _Environ on dict instead of UserDict Message-ID: Patches item #1094387, was opened at 2005-01-02 11:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094387&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: os.py: base class _Environ on dict instead of UserDict Initial Comment: os.py doesn't have a note, that is has to stay compatible with python2.2 and before. Use the builtin dict class for handling the environment. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 00:43 Message: Logged In: YES user_id=21627 The patch is currently outdated. However, I'm wondering what the advantage of inheriting from dict is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094387&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:49:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:49:35 2005 Subject: [Patches] [ python-Patches-1088078 ] Patch for bug 1088077 Message-ID: Patches item #1088078, was opened at 2004-12-19 22:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088078&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug 1088077 Initial Comment: This patches adds a setsane function to the tty module. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 00:49 Message: Logged In: YES user_id=21627 I agree with all these observations. In addition, documentation is missing for the new function. Given all these issues (in particular the questionable value of the new function in the first place), I'm rejecting the patch. If you think a functionality like this should still be added to Python, please submit a new patch, and give a rationale for why this new function is needed. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2005-02-07 09:29 Message: Logged In: YES user_id=65253 Hi, I'm not a Python developer, but I've looked at your patch. The following two problems jump out at me: 1) The mode is being saved in a single global variable, which would be overwritten if the functions are called on different fds. 2) If setraw and/or setcbreak are called multiple times, the initial value of _mode is lost. The obvious fix would just be to use a dict and not set the value if it is already set. Also, I think think setsane is a somewhat misleading name, perhaps something along the lines of setinitial or restoremode would be more accurate. Aside from all that, I don't know if keeping hidden state in the module is really the best solution to the problem. Requiring the users to save and restore the value from tcgetattr is not significantly harder and makes it more obvious what is going on. If some fix is required, adding a note to the tty docs about how to save and restore the mode using termios may be enough, or perhaps adding some (really) thin savemode/restoremode wrappers to the tty module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088078&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:50:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:50:54 2005 Subject: [Patches] [ python-Patches-1075887 ] gcc compiler on Windows Message-ID: Patches item #1075887, was opened at 2004-11-30 11:06 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075887&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Martin v. L?wis (loewis) Summary: gcc compiler on Windows Initial Comment: C extension modules can be built for Python on Windows with various compilers, such as Borland's C compiler and the gcc compiler using cygwin/mingw. With Python 2.3, a binary installer for Windows can be built as follows: python setup.py build --compiler=mingw32 # compiles the extension module using the gcc compiler # on cygwin / mingw python setup.py bdist_wininst # to create the binary installer. Hence, no need for Microsoft's compiler. With Python 2.4, a problem arises with the bdist_wininst command (and also with python setup.py install) if a user does not have Microsoft's compiler installed, even if gcc or Borland's compiler is used to compile the extension module. The problem is that distutils first creates an MSVCCompiler object and then checks if anything still needs to be compiled. In Python 2.4, the __init__ function of MSVCCompiler checks if the version of the installed Microsoft VC compiler is compatible with the version that was used to build Python itself. If Microsoft's VC compiler is not installed, __init__ will fail, even though the extension module has already been compiled by gcc or Borland's compiler. The solution, in the attached patch, is to postpone the full initialization of MSVCCompiler until Distutils determines that there is something left to be compiled. For users of gcc or Borland, MSVCCompiler's __init__ function does not need Microsoft VC to be installed. For users of Microsoft VC, the remainder of the initialization is performed when MSVCCompiler is asked to compile or link something for the first time. Hence, both gcc or Borland and Microsoft VC can be used to build extension modules for Python on Windows, just like in Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075887&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:52:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:52:26 2005 Subject: [Patches] [ python-Patches-1043890 ] tarfile: add extractall() method Message-ID: Patches item #1043890, was opened at 2004-10-10 10:41 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043890&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Lars Gust?bel (gustaebel) >Assigned to: Martin v. L?wis (loewis) Summary: tarfile: add extractall() method Initial Comment: I had a discussion with tarfile.py user Joeseph Jones a few weeks ago who had problems with a certain tar archive. It contained the following: $ tar tvzf fish.tar.gz dr-xr-xr-x devnull/devnull 0 2004-09-14 23:36:01 fish/ -rw-r--r-- devnull/devnull 221190144 2004-09-14 23:35:46 fish/m8.avi Note that the fish/ directory has no write permissions. When he tried to unpack this archive with tarfile.py, the fish/m8.avi file was not extracted, because the fish/ directory is extracted first and has its attributes set to read-only. This is a major issue especially for restoring system backups. We considered several alternatives: 1. One thing Joeseph criticized was that the documentation does not at all mention that tarfile.py's random access nature brings problems with it. So, we could add an example to the example section of the docs which illustrates how to work around these. 2. In order not to change the API and be transparent we could remodel the extract() method to go down the directory tree every time it is called, change directory permissions if necessary, extract the file and restore the permissions again. 3. The TarFile object could store all extracted directories in a list and set their permissions in the end when it is closed. 4. We could introduce a new method (e.g. extractall()) that takes care of these issues. It will extract all members and keep a list of directories which it will extract with default attributes. In a second run it will set the directory attributes accordingly. I favour alternative 4 and have written a patch that implements it. It has several advantages over the other three: - It is a shortcut. If a user wants to extract an entire archive, he won't need to iterate over it, he could do it with a one-liner. - It is a concise and isolated implementation. - It would eliminate another issue that I find annoying since the beginning of tarfile but that was never worth introducing a new method: When a file is created in a directory, the directory's modification time is reset. So, after the extraction process, the mtimes are only correct on empty directories. So, tarfile.py would lose its last disadvantages in comparison to tar(1). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043890&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:55:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:55:52 2005 Subject: [Patches] [ python-Patches-959534 ] Arrange 64bits detection for ReliantUnix Message-ID: Patches item #959534, was opened at 2004-05-24 18:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=959534&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jean-frederic Clere (jfclere) Assigned to: Nobody/Anonymous (nobody) Summary: Arrange 64bits detection for ReliantUnix Initial Comment: When compiling python on ReliantUnix (5.43) the compilation fails with unresolved externals like fstatvfs64, lseek64 etc Those routines belong to 5.45. The patch detects the missing lseek64() and suppress lfs support (use_lfs=no). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 00:55 Message: Logged In: YES user_id=21627 Rejecting the patch due to lack of response. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 20:13 Message: Logged In: YES user_id=21627 Performing checks on all platforms is not a problem; the time that configure needs is not critical. If the test were run on all systems, would there be any negative functional effects? ---------------------------------------------------------------------- Comment By: Jean-frederic Clere (jfclere) Date: 2004-06-03 09:07 Message: Logged In: YES user_id=92497 Checking for Sinix is need because the SINIX unistd.h redefines lseek() into lseek64() when LFS is required (via _FILE_OFFSET_BITS and/or _LFS64_LARGEFILE). Checking for LFS via AC_TRY_LINK for most platforms means more tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-02 00:17 Message: Logged In: YES user_id=21627 Hmm. Why are you checking for Sinix at all? If the test fails, isn't it likely that LFS doesn't work on the platform? ---------------------------------------------------------------------- Comment By: Jean-frederic Clere (jfclere) Date: 2004-06-01 18:56 Message: Logged In: YES user_id=92497 Oops... That is better to check for SINIX-* before trying the link. I have more to submit because the dynamic linking needs additional libc. For example in setup.py +++ exts.append( Extension('_hotshot', ['_hotshot.c'], libraries=['c']) ) +++ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 20:27 Message: Logged In: YES user_id=21627 Why do you check for SINIX after the link test fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=959534&group_id=5470 From noreply at sourceforge.net Fri Mar 4 00:57:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 00:57:22 2005 Subject: [Patches] [ python-Patches-918101 ] tarfile.py enhancements Message-ID: Patches item #918101, was opened at 2004-03-17 16:59 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918101&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) >Assigned to: Martin v. L?wis (loewis) Summary: tarfile.py enhancements Initial Comment: I still develop tarfile.py sporadically on a separate branch (http://www.gustaebel.de/lars/tarfile/), and so there are two features from this branch that I'd like to propose for inclusion in Python's tarfile.py: 1. Overcoming the 8GB file size limit (8GB-limit.patch) At the moment it is not possible to add files to a tar archive that exceed 8GB size. Although this is POSIX compliant, GNU tar offers an extension header for largefiles that encodes file sizes in an 88-bit number instead of the common 11-digits octal number. Like all other GNU extensions in tarfile.py, this feature is turned on and off using the TarFile.posix attribute. 2. Automatic compression detection for the stream interface (stream-detect-compr.patch) tarfile.py's stream interface (which can be used to access tape devices or simply read a tar from stdin) is a bit difficult to use because it's not able to detect whether an archive is compressed or not. Compression has to be explicitly specified using mode ("r|", "r|gz", "r|bz2"). The patch introduces a fourth mode "r|*" that makes automatic detection possible. Both patches are not vitally important, but especially the 8GB-patch is useful IMO. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2004-07-21 14:55 Message: Logged In: YES user_id=642936 I just created tests for the stream-detect-compr.patch, attached as test.patch. BTW, I examined bug #949052, and opened a patch (#995126). ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2004-07-21 09:54 Message: Logged In: YES user_id=642936 tarfile.py's stream interface must be used if the user wants to read an archive that is not a seekable file, e.g. stdin or a tape device. ATM, it is the user's job to find out whether the stream is compressed (mode="r|gz" or "r|bz2") or uncompressed (mode="r|"), which makes the stream interface kind of awkward and unusable for many users. The patch introduces an additional mode "r|*" which does this job. I admit it's just a convenience thing but I think the stream interface is somehow too complicated without it. The reason why I changed the "type" argument to "comptype" was just that the TarFile class uses "comptype" and the _Stream class uses "type" for the same thing. It doesn't need to be changed. You're absolute right about the testcase. I had enough time to write one ;-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-21 00:31 Message: Logged In: YES user_id=33168 Lars, could you look at bug 949052 and provide any guidance? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-21 00:28 Message: Logged In: YES user_id=33168 I checked in the 8GB limit patch. Lib/tarfile.py 1.14. I didn't check in the stream patch for 2 reasons: 1) I don't know the need. Is this common? I've never heard of it. 2) The type parameter name was changed to comtype. I wasn't sure if this was necessary. It potentially (albeit unlikely) could break a program. I'm not concerned about changing the name of attribute. Lars, can you provide a good reason to add this part of the patch? If it's not likely to be used, I don't think it should be added. If it is added, there should also be a test. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918101&group_id=5470 From noreply at sourceforge.net Fri Mar 4 01:50:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 01:51:01 2005 Subject: [Patches] [ python-Patches-1110205 ] Make Python Editor Useful Without Full IDLE Message-ID: Patches item #1110205, was opened at 2005-01-26 15:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110205&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sowjanya (sowjanya) Assigned to: Kurt B. Kaiser (kbk) >Summary: Make Python Editor Useful Without Full IDLE Initial Comment: We are using the Filelist class from idlelib to create Python syntax aware source code editor in our applications. In order to be able to embed the code editor window into a Tk graphical user interface and specify the width and height of the editor (in lines and columns) we had to modify the EditorWidow and ScriptBinding classes to accept a 'top' argument (container in which to create the editor), and 'width' and 'height' arguments. We are submitting the patches for your consideration to be included into the next release of idlelib1.2a0. The patches were generated using the following command: diff -c old new ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-03-03 19:50 Message: Logged In: YES user_id=149084 May I assume that this is a copy of Idlefork Patch 796254? Are you the same people who submitted that anonymous patch? If so, thanks for the context diff. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 18:03 Message: Logged In: YES user_id=21627 Kurt, can you please take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110205&group_id=5470 From noreply at sourceforge.net Fri Mar 4 11:21:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 11:21:58 2005 Subject: [Patches] [ python-Patches-1156102 ] exception doc updates Message-ID: Patches item #1156102, was opened at 2005-03-03 18:57 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1156102&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: exception doc updates Initial Comment: I was going to bang on the exception docs until I discovered that they are already somewhat out-of-date. This updates the reference manual to describe exceptions with the presumption that class exceptions are the default, and string exceptions are subsidiary and deprecated. I'll probably check this in soon unless someone complains :) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-03-04 10:21 Message: Logged In: YES user_id=6656 If you mean the "if it's an instance, then ..., if it's a tuple then ... if it's anything else then..." stuff, that's described in the section on raise, which is where it belongs IMHO. By the time the exception has been raised, it really is described (conceptually, at least) by the instance. I've rephrased the first affected paragraph a bit (attached). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 22:25 Message: Logged In: YES user_id=21627 Overall, the patch looks fine. One note though: in the first chunk, what about the information that you can also pass an object in the raise, in addition to the type? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1156102&group_id=5470 From noreply at sourceforge.net Fri Mar 4 14:41:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 14:41:42 2005 Subject: [Patches] [ python-Patches-1075887 ] gcc compiler on Windows Message-ID: Patches item #1075887, was opened at 2004-11-30 11:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075887&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Martin v. L?wis (loewis) Summary: gcc compiler on Windows Initial Comment: C extension modules can be built for Python on Windows with various compilers, such as Borland's C compiler and the gcc compiler using cygwin/mingw. With Python 2.3, a binary installer for Windows can be built as follows: python setup.py build --compiler=mingw32 # compiles the extension module using the gcc compiler # on cygwin / mingw python setup.py bdist_wininst # to create the binary installer. Hence, no need for Microsoft's compiler. With Python 2.4, a problem arises with the bdist_wininst command (and also with python setup.py install) if a user does not have Microsoft's compiler installed, even if gcc or Borland's compiler is used to compile the extension module. The problem is that distutils first creates an MSVCCompiler object and then checks if anything still needs to be compiled. In Python 2.4, the __init__ function of MSVCCompiler checks if the version of the installed Microsoft VC compiler is compatible with the version that was used to build Python itself. If Microsoft's VC compiler is not installed, __init__ will fail, even though the extension module has already been compiled by gcc or Borland's compiler. The solution, in the attached patch, is to postpone the full initialization of MSVCCompiler until Distutils determines that there is something left to be compiled. For users of gcc or Borland, MSVCCompiler's __init__ function does not need Microsoft VC to be installed. For users of Microsoft VC, the remainder of the initialization is performed when MSVCCompiler is asked to compile or link something for the first time. Hence, both gcc or Borland and Microsoft VC can be used to build extension modules for Python on Windows, just like in Python 2.3. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:41 Message: Logged In: YES user_id=21627 I see. Notice that you can get the compilation to pass using \Python25\python.exe setup.py build --compiler=mingw32 bdist_wininst (i.e. all in one invocation) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075887&group_id=5470 From noreply at sourceforge.net Fri Mar 4 14:52:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 14:52:30 2005 Subject: [Patches] [ python-Patches-1075887 ] gcc compiler on Windows Message-ID: Patches item #1075887, was opened at 2004-11-30 11:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075887&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Martin v. L?wis (loewis) Summary: gcc compiler on Windows Initial Comment: C extension modules can be built for Python on Windows with various compilers, such as Borland's C compiler and the gcc compiler using cygwin/mingw. With Python 2.3, a binary installer for Windows can be built as follows: python setup.py build --compiler=mingw32 # compiles the extension module using the gcc compiler # on cygwin / mingw python setup.py bdist_wininst # to create the binary installer. Hence, no need for Microsoft's compiler. With Python 2.4, a problem arises with the bdist_wininst command (and also with python setup.py install) if a user does not have Microsoft's compiler installed, even if gcc or Borland's compiler is used to compile the extension module. The problem is that distutils first creates an MSVCCompiler object and then checks if anything still needs to be compiled. In Python 2.4, the __init__ function of MSVCCompiler checks if the version of the installed Microsoft VC compiler is compatible with the version that was used to build Python itself. If Microsoft's VC compiler is not installed, __init__ will fail, even though the extension module has already been compiled by gcc or Borland's compiler. The solution, in the attached patch, is to postpone the full initialization of MSVCCompiler until Distutils determines that there is something left to be compiled. For users of gcc or Borland, MSVCCompiler's __init__ function does not need Microsoft VC to be installed. For users of Microsoft VC, the remainder of the initialization is performed when MSVCCompiler is asked to compile or link something for the first time. Hence, both gcc or Borland and Microsoft VC can be used to build extension modules for Python on Windows, just like in Python 2.3. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:52 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as msvccompiler.py 1.65 and 1.64.2.1 NEWS 1.2363 and 1.1193.2.30 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:41 Message: Logged In: YES user_id=21627 I see. Notice that you can get the compilation to pass using \Python25\python.exe setup.py build --compiler=mingw32 bdist_wininst (i.e. all in one invocation) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075887&group_id=5470 From noreply at sourceforge.net Fri Mar 4 14:59:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 14:59:58 2005 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 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Kramm (kramm) Assigned to: Martin v. L?wis (loewis) Summary: mingw compile Initial Comment: A cross-compile of a Win32 Python under Linux using MingW (www.mingw.org) didn't work, as posixmodule.c didn't know anything about MingW. This patch fixes the various compile errors by introducing a new local MINGW define in posixmodule.c, and making several #ifdefs also take that variable into account. After this patch is applied, it's possible to compile python.exe on Linux with MingW by doing CXX=i386-mingw32msvc-g++ CPP=i386-mingw32msvc-cpp RANLIB=i386-mingw32msvc-ranlib AR=i386-mingw32msvc-ar CC="/opt/xmingw/bin/i386-mingw32msvc-gcc -DMS_WINDOWS -DPy_WIN_WIDE_FILENAMES" ./configure --host=i586-mingw32msvc sed -i s/initposix/initnt/g Modules/config.c sed -i 's/#define HAVE_DEV_PTMX 1//g' pyconfig.h make ---------------------------------------------------------------------- >Comment By: 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 Fri Mar 4 15:02:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 15:02:30 2005 Subject: [Patches] [ python-Patches-957033 ] Allow compilation of C/C++ Python extensions without MSVC Message-ID: Patches item #957033, was opened at 2004-05-19 22:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957033&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Connelly (connelly) Assigned to: Nobody/Anonymous (nobody) Summary: Allow compilation of C/C++ Python extensions without MSVC Initial Comment: This page describes how to compile C/C++ Python extensions with Mingw: http://sebsauvage.net/python/mingw.html This process works. However, you need to patch Python to get the 'python setup.py install' step to work correctly. This is the second step in installing a Python extension. The first step: 'python setup.py build -cmingw32' works fine. The second step: 'python setup.py install' fails with the following error: "error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed." This statement is factually untrue. Python uses .pyd files to run Python extensions, which are actually .dll files, and are compatible across different compilers and compiler versions. So open \Python\Lib\distutils\msvccompiler.py and remove the warning (it's around line 211). Or apply the patch: --- msvccompiler.bak Thu Dec 4 09:38:22 2003 +++ msvccompiler.py Wed May 19 13:15:34 2004 @@ -208,11 +208,10 @@ self.__root = r"Software\Microsoft\Devstudio" self.__paths = self.get_msvc_paths("path") - if len (self.__paths) == 0: - raise DistutilsPlatformError, - ("Python was built with version %s of Visual Studio, " - "and extensions need to be built with the same " - "version of the compiler, but it isn't installed." % self.__version) + # Note: Extensions CAN be built with Mingw32. + # See http://sebsauvage.net/python/mingw.html. + # The .pyd files created are DLLs, and these are compatible across + # different compilers and compiler versions. self.cc = self.find_exe("cl.exe") self.linker = self.find_exe("link.exe") ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 15:02 Message: Logged In: YES user_id=21627 With the current CVS, this problem is fixed: The install command does not require a MSVC anymore if there is nothing to build. Closing the patch as out-of-date. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-06-01 17:41 Message: Logged In: YES user_id=11105 This is not a bug. The 'install' command internally runs the 'build' command, and this command misses the -cmingw32 flag. Basically, you have two options to build and install the extension: - call 'python setup.py build -cmingw32 install' - create/edit your distutils configuration file setup.cfg. Add this section (untested, but you get the idea): [build_ext] compiler=mingw32 See distutils docs for more details - the latter way is the recommended one. Does this help? ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2004-05-19 22:41 Message: Logged In: YES user_id=1039782 Here's the upload. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2004-05-19 22:40 Message: Logged In: YES user_id=1039782 BTW: You can test this out with the extension module myspell-python, available at: http://www.zgoda.biz/dnld/myspell-python-1.0- minimal.tar.gz Follow the directions at http://sebsauvage.net/python/mingw.html. You'll encounter an error. Patch msvccompiler.py and try again; now it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957033&group_id=5470 From noreply at sourceforge.net Fri Mar 4 15:16:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 15:16:53 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) 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: John J Lee (jjlee) Date: 2005-03-04 14: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 11: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 18: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 16: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 22: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 16: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 Fri Mar 4 15:18:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 15:18:18 2005 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 08:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 15:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 07:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 07:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 06:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 17:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 05:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 04:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 02:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Fri Mar 4 15:25:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 15:25:42 2005 Subject: [Patches] [ python-Patches-1156102 ] exception doc updates Message-ID: Patches item #1156102, was opened at 2005-03-03 19:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1156102&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: exception doc updates Initial Comment: I was going to bang on the exception docs until I discovered that they are already somewhat out-of-date. This updates the reference manual to describe exceptions with the presumption that class exceptions are the default, and string exceptions are subsidiary and deprecated. I'll probably check this in soon unless someone complains :) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 15:25 Message: Logged In: YES user_id=21627 I see. This is fine; please apply. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-04 11:21 Message: Logged In: YES user_id=6656 If you mean the "if it's an instance, then ..., if it's a tuple then ... if it's anything else then..." stuff, that's described in the section on raise, which is where it belongs IMHO. By the time the exception has been raised, it really is described (conceptually, at least) by the instance. I've rephrased the first affected paragraph a bit (attached). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 23:25 Message: Logged In: YES user_id=21627 Overall, the patch looks fine. One note though: in the first chunk, what about the information that you can also pass an object in the raise, in addition to the type? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1156102&group_id=5470 From noreply at sourceforge.net Fri Mar 4 15:27:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 15:27:22 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 18:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) 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: Martin v. L?wis (loewis) Date: 2005-03-04 15: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 15: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 12: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 19: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 17: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 23: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 17: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 Fri Mar 4 15:35:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 15:35:24 2005 Subject: [Patches] [ python-Patches-1156102 ] exception doc updates Message-ID: Patches item #1156102, was opened at 2005-03-03 18:57 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1156102&group_id=5470 Category: Documentation Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: exception doc updates Initial Comment: I was going to bang on the exception docs until I discovered that they are already somewhat out-of-date. This updates the reference manual to describe exceptions with the presumption that class exceptions are the default, and string exceptions are subsidiary and deprecated. I'll probably check this in soon unless someone complains :) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-03-04 14:35 Message: Logged In: YES user_id=6656 Done, in: ref4.tex revision 1.38 ref7.tex revision 1.43 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:25 Message: Logged In: YES user_id=21627 I see. This is fine; please apply. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-04 10:21 Message: Logged In: YES user_id=6656 If you mean the "if it's an instance, then ..., if it's a tuple then ... if it's anything else then..." stuff, that's described in the section on raise, which is where it belongs IMHO. By the time the exception has been raised, it really is described (conceptually, at least) by the instance. I've rephrased the first affected paragraph a bit (attached). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 22:25 Message: Logged In: YES user_id=21627 Overall, the patch looks fine. One note though: in the first chunk, what about the information that you can also pass an object in the raise, in addition to the type? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1156102&group_id=5470 From noreply at sourceforge.net Fri Mar 4 15:40:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 15:41:01 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) 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: John J Lee (jjlee) Date: 2005-03-04 14: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 14: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 14: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 11: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 18: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 16: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 22: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 16: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 Fri Mar 4 15:41:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 15:41:58 2005 Subject: [Patches] [ python-Patches-1118602 ] Fix crash in xmlprase_GetInputContext in pyexpat.c Message-ID: Patches item #1118602, was opened at 2005-02-08 14:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118602&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Mathieu Fenniak (laotzu0) Assigned to: Martin v. L?wis (loewis) Summary: Fix crash in xmlprase_GetInputContext in pyexpat.c Initial Comment: I've run across a couple of cases where pyexpat will crash in xmlparse_GetInputContext. The problem stems from the 'offset' variable that can be returned from XML_GetInputContext - if it is non-zero, then the size being passed into PyString_FromStringAndSize is incorrectly too large. The offset should be subtracted from that size. I cannot provide a test case to reproduce this - my attempts to create a minimal test case do not crash. The application I'm developing is using simpleTAL and when a large XML comment (multiline Javascript) is entered in the software templates it will often crash. This seems to only occur on a Python installation where the module xml.sax.saxlib is not present (i.e. PyXML is not installed) - I'm not sure why this is. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 15:41 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as pyexpat.c 2.90 and 2.89.2.1 NEWS 1.1264 and 1.1193.2.31 It turns out that this was essentially a duplicate of 925152. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118602&group_id=5470 From noreply at sourceforge.net Fri Mar 4 15:52:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 15:52:12 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 18:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) 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: Martin v. L?wis (loewis) Date: 2005-03-04 15: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 15: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 15: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 15: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 12: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 19: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 17: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 23: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 17: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 Fri Mar 4 19:18:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 19:18:58 2005 Subject: [Patches] [ python-Patches-1110205 ] Make Python Editor Useful Without Full IDLE Message-ID: Patches item #1110205, was opened at 2005-01-26 20:54 Message generated for change (Comment added) made by sowjanya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110205&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sowjanya (sowjanya) Assigned to: Kurt B. Kaiser (kbk) Summary: Make Python Editor Useful Without Full IDLE Initial Comment: We are using the Filelist class from idlelib to create Python syntax aware source code editor in our applications. In order to be able to embed the code editor window into a Tk graphical user interface and specify the width and height of the editor (in lines and columns) we had to modify the EditorWidow and ScriptBinding classes to accept a 'top' argument (container in which to create the editor), and 'width' and 'height' arguments. We are submitting the patches for your consideration to be included into the next release of idlelib1.2a0. The patches were generated using the following command: diff -c old new ---------------------------------------------------------------------- >Comment By: sowjanya (sowjanya) Date: 2005-03-04 18:18 Message: Logged In: YES user_id=1202212 I couldn't find Idlefork Patch 796254 to make sure whether it is ours. Could you please send me an url for this patch or guide me in searching it. Thanks Sowjanya ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-03-04 00:50 Message: Logged In: YES user_id=149084 May I assume that this is a copy of Idlefork Patch 796254? Are you the same people who submitted that anonymous patch? If so, thanks for the context diff. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 23:03 Message: Logged In: YES user_id=21627 Kurt, can you please take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110205&group_id=5470 From noreply at sourceforge.net Fri Mar 4 19:39:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 19:39:13 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) 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: John J Lee (jjlee) Date: 2005-03-04 18: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 14: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 14: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 14: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 14: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 11: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 18: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 16: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 22: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 16: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 Fri Mar 4 19:46:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 19:47:02 2005 Subject: [Patches] [ python-Patches-1144636 ] Make urllib2.OpenerDirector instances pickle-able Message-ID: Patches item #1144636, was opened at 2005-02-20 02:48 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144636&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Make urllib2.OpenerDirector instances pickle-able Initial Comment: urllib2.OpenerDirector would be pickleable if it were not for the fact that a couple of urllib2 handlers (which build_opener() adds by default) have function instance attributes. It's trivial to replace these instance attributes with a method that delegates to the appropriate function, thus allowing pickling. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-03-04 18:46 Message: Logged In: YES user_id=261020 Hmm, maybe this fault (can't pickle) will be fixed without need for this patch in 2.5, due to the change to unbound methods that was discussed on python-dev. I don't understand that issue, so I can't say. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144636&group_id=5470 From noreply at sourceforge.net Fri Mar 4 20:04:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 20:04:22 2005 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 08:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 20:04 Message: Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 15:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 07:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 07:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 06:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 17:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 05:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 04:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 02:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Fri Mar 4 20:06:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 20:06:49 2005 Subject: [Patches] [ python-Patches-1110205 ] Make Python Editor Useful Without Full IDLE Message-ID: Patches item #1110205, was opened at 2005-01-26 21:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110205&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sowjanya (sowjanya) Assigned to: Kurt B. Kaiser (kbk) Summary: Make Python Editor Useful Without Full IDLE Initial Comment: We are using the Filelist class from idlelib to create Python syntax aware source code editor in our applications. In order to be able to embed the code editor window into a Tk graphical user interface and specify the width and height of the editor (in lines and columns) we had to modify the EditorWidow and ScriptBinding classes to accept a 'top' argument (container in which to create the editor), and 'width' and 'height' arguments. We are submitting the patches for your consideration to be included into the next release of idlelib1.2a0. The patches were generated using the following command: diff -c old new ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 20:06 Message: Logged In: YES user_id=21627 http://sourceforge.net/tracker/index.php?func=detail&aid=796254&group_id=9579&atid=309579 ---------------------------------------------------------------------- Comment By: sowjanya (sowjanya) Date: 2005-03-04 19:18 Message: Logged In: YES user_id=1202212 I couldn't find Idlefork Patch 796254 to make sure whether it is ours. Could you please send me an url for this patch or guide me in searching it. Thanks Sowjanya ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-03-04 01:50 Message: Logged In: YES user_id=149084 May I assume that this is a copy of Idlefork Patch 796254? Are you the same people who submitted that anonymous patch? If so, thanks for the context diff. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 00:03 Message: Logged In: YES user_id=21627 Kurt, can you please take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110205&group_id=5470 From noreply at sourceforge.net Fri Mar 4 20:33:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 4 20:33:08 2005 Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not unescape attribute values; patch Message-ID: Patches item #1087808, was opened at 2004-12-19 06:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Martin v. L?wis (loewis) Summary: sgmllib.SGMLParser does not unescape attribute values; patch Initial Comment: for example, in a form parsed by htmllib.HTMLParser (based on SGMLParser),