From noreply at sourceforge.net Sat Jan 1 01:29:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 01:33:00 2005 Subject: [Patches] [ python-Patches-1093896 ] miscellaneous doc typos Message-ID: Patches item #1093896, was opened at 2004-12-31 16:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093896&group_id=5470 Category: Documentation >Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: miscellaneous doc typos Initial Comment: Various copyedits for docs. [We'll see if I escape Skitt's law or not!] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-31 19:29 Message: Logged In: YES user_id=80475 Fixed. Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093896&group_id=5470 From noreply at sourceforge.net Sat Jan 1 07:12:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 07:12:58 2005 Subject: [Patches] [ python-Patches-1051395 ] locale.getdefaultlocale does not return tuple in some OS Message-ID: Patches item #1051395, was opened at 2004-10-21 06:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1051395&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Jiwon Seo (jiwon) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getdefaultlocale does not return tuple in some OS Initial Comment: Unconforming to its docstring, _parse_localename does not return result as tuple in some OSes. Either document for the function or implementation should be fixed. The patch fixes the implementation. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-01 01:12 Message: Logged In: YES user_id=80475 Applied as Lib/locale.py 1.31 and 1.28.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1051395&group_id=5470 From noreply at sourceforge.net Sat Jan 1 07:13:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 07:14:01 2005 Subject: [Patches] [ python-Patches-1046831 ] Consistent retrieval of Python version. Message-ID: Patches item #1046831, was opened at 2004-10-14 01:44 Message generated for change (Settings changed) made by rhettinger 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: Open Resolution: None 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1046831&group_id=5470 From noreply at sourceforge.net Sat Jan 1 07:14:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 07:14:54 2005 Subject: [Patches] [ python-Patches-751031 ] imghdr -- identify JPEGs in EXIF format Message-ID: Patches item #751031, was opened at 2003-06-08 15:08 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751031&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 1 Submitted By: Steven Taschuk (staschuk) >Assigned to: Raymond Hettinger (rhettinger) Summary: imghdr -- identify JPEGs in EXIF format Initial Comment: Someone posted to c.l.py [1] about some of their JPEGs not being identified as such by imghdr. Turns out they were EXIF files, and imghdr only identifies JFIF files. A little web research suggests EXIF is the usual format for JPEGS from digital cameras. The patch adds the ability to identify such files; they are reported as 'jpeg-exif'. I've no idea whether this is the Right Thing. [1] http://groups.google.com/groups?th=45c0442a1d74e9c4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751031&group_id=5470 From noreply at sourceforge.net Sat Jan 1 07:15:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 07:15:51 2005 Subject: [Patches] [ python-Patches-712317 ] Bug fix 548176: urlparse('http://foo?blah') errs Message-ID: Patches item #712317, was opened at 2003-03-30 15:16 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712317&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) >Assigned to: Raymond Hettinger (rhettinger) Summary: Bug fix 548176: urlparse('http://foo?blah') errs Initial Comment: For detailed description of the problem, see http://www.python.org/sf/548176 In summary, URLs such as http://www.example.com?query=spam are misparsed by urlparse.urlparse, which decides that everything after the '//' is the host name. This is contrary to RFC 2396 and probably contrary to the intent of RFC 1738. The patch corrects the problem, adds a test to expose it, and rearranges some of the tests to better exercise the code in question. ---------------------------------------------------------------------- Comment By: Mike Rovner (mrovner) Date: 2004-01-26 20:15 Message: Logged In: YES user_id=162094 -1. See my comment at http://www.python.org/sf/548176 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712317&group_id=5470 From noreply at sourceforge.net Sat Jan 1 08:25:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 08:26:01 2005 Subject: [Patches] [ python-Patches-1094007 ] Remove witty comment in pydoc.py Message-ID: Patches item #1094007, was opened at 2005-01-01 08:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094007&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Remove witty comment in pydoc.py Initial Comment: Reference: patch #1009389. The author of the witty "moose" comment has expressed his wish that this comment be removed; this is by far the easiest solution for the pydoc/unicode problem. Attached is the patch to remove that comment. Patch #1009389 can be closed then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094007&group_id=5470 From noreply at sourceforge.net Sat Jan 1 08:26:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 08:26:59 2005 Subject: [Patches] [ python-Patches-1094007 ] Remove witty comment in pydoc.py Message-ID: Patches item #1094007, was opened at 2005-01-01 08:25 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094007&group_id=5470 >Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Remove witty comment in pydoc.py Initial Comment: Reference: patch #1009389. The author of the witty "moose" comment has expressed his wish that this comment be removed; this is by far the easiest solution for the pydoc/unicode problem. Attached is the patch to remove that comment. Patch #1009389 can be closed then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094007&group_id=5470 From noreply at sourceforge.net Sat Jan 1 08:46:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 08:46:26 2005 Subject: [Patches] [ python-Patches-1094007 ] Remove witty comment in pydoc.py Message-ID: Patches item #1094007, was opened at 2005-01-01 02:25 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094007&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Raymond Hettinger (rhettinger) Summary: Remove witty comment in pydoc.py Initial Comment: Reference: patch #1009389. The author of the witty "moose" comment has expressed his wish that this comment be removed; this is by far the easiest solution for the pydoc/unicode problem. Attached is the patch to remove that comment. Patch #1009389 can be closed then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094007&group_id=5470 From noreply at sourceforge.net Sat Jan 1 08:48:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 08:48:45 2005 Subject: [Patches] [ python-Patches-1065986 ] Fix pydoc crashing on unicode strings Message-ID: Patches item #1065986, was opened at 2004-11-13 20:36 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1065986&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) >Assigned to: Raymond Hettinger (rhettinger) Summary: Fix pydoc crashing on unicode strings Initial Comment: The pydoc module currently only outputs ASCII and crashes with UnicodeEncodeError when printing a unicode string (in contexts where it prints the str rather than a repr, e.g. docstrings or variables like `__credits__`). The most ironic example of it is that since patch 1009389 was committed, ``pydoc.py pydoc`` crashes on its own `__credits__`! This patch changes pydoc help functions to return unicode strings only when needed; it returns ASCII strings if all characters are from ASCII. Therefore there should be no compatibility problems. For output, all pager functions were changed to encode to the locale's preferred encoding and HTML output was changed to always use UTF-8. cgitb.py, DocXMLRPCServer.py and/or SimpleXMLRPCServer.py seems to rely on pydoc to some degree. I didn't touch them, so they might still be broken in this respect. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2004-11-17 06:45 Message: Logged In: YES user_id=45338 I'm so sorry this has caused so much trouble. The silly moose comment is my fault; it can be removed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-14 05:22 Message: Logged In: YES user_id=21627 This is a too major change so short before the 2.4 release, so postponing it 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1065986&group_id=5470 From noreply at sourceforge.net Sat Jan 1 08:50:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 08:50:53 2005 Subject: [Patches] [ python-Patches-1094011 ] Docs for file() vs open() Message-ID: Patches item #1094011, was opened at 2005-01-01 08:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094011&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for file() vs open() Initial Comment: This is in reference to the thread on python-dev starting 2004/07/07, subject "file() or open()?". Guido stated there that one should use open() to open files: """Anyway, here's my future-proof distinction: use open() as the factory function, and file for type-testing.""" The docs, however, still convince the reader that open() is retained for backwards compatibility and near deprecation. This patch corrects the issue, mostly using Guido's own new wording. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094011&group_id=5470 From noreply at sourceforge.net Sat Jan 1 08:53:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 08:53:25 2005 Subject: [Patches] [ python-Patches-1094007 ] Remove witty comment in pydoc.py Message-ID: Patches item #1094007, was opened at 2005-01-01 02:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094007&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Raymond Hettinger (rhettinger) Summary: Remove witty comment in pydoc.py Initial Comment: Reference: patch #1009389. The author of the witty "moose" comment has expressed his wish that this comment be removed; this is by far the easiest solution for the pydoc/unicode problem. Attached is the patch to remove that comment. Patch #1009389 can be closed then. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-01 02:53 Message: Logged In: YES user_id=80475 Okay. Applied to Lib/pydoc.py 1.101 and 1.100.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094007&group_id=5470 From noreply at sourceforge.net Sat Jan 1 09:00:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 09:00:20 2005 Subject: [Patches] [ python-Patches-1094011 ] Docs for file() vs open() Message-ID: Patches item #1094011, was opened at 2005-01-01 02:50 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094011&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Raymond Hettinger (rhettinger) Summary: Docs for file() vs open() Initial Comment: This is in reference to the thread on python-dev starting 2004/07/07, subject "file() or open()?". Guido stated there that one should use open() to open files: """Anyway, here's my future-proof distinction: use open() as the factory function, and file for type-testing.""" The docs, however, still convince the reader that open() is retained for backwards compatibility and near deprecation. This patch corrects the issue, mostly using Guido's own new wording. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094011&group_id=5470 From noreply at sourceforge.net Sat Jan 1 09:26:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 09:26:46 2005 Subject: [Patches] [ python-Patches-1094015 ] Improvements for shutil.copytree() Message-ID: Patches item #1094015, was opened at 2005-01-01 09:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094015&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Improvements for shutil.copytree() Initial Comment: See bugs #975763 and #1048878. The patch changes shutil.copytree() to use os.makedirs() instead of os.mkdir() and to copy directory bits using copystat(), because file bits are copied, too. It includes a doc change to mention these details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094015&group_id=5470 From noreply at sourceforge.net Sat Jan 1 10:37:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 10:37:53 2005 Subject: [Patches] [ python-Patches-1071764 ] a new subprocess.call which raises an error on non-zero rc Message-ID: Patches item #1071764, was opened at 2004-11-23 15:45 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470 Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Craig-Wood (ncw) Assigned to: Peter ?strand (astrand) Summary: a new subprocess.call which raises an error on non-zero rc Initial Comment: The attached patch introduces a 3rd utility function - xcall() to the subprocess module. This function acts just like call but raises errors if the command had a non-zero return code. This saves writing if call(...): raise OSError(...) It is most useful for shell script replacement programming. Checking the return codes of commands called is often forgotten in shell programming. When you've moved up to python because shell is too limiting (usually about 10 lines of shell in my case ;-) you want to make sure that all your commands work so you write robust code. I consider raising an exception to be much more pythonic than checking a return code (ie "Errors should never pass silently" from Zen of Python) Eg # An easy to miss error >>> subprocess.call(["mkdir", "a/b"]) mkdir: cannot create directory `a/b': No such file or directory 1 >>> # user forgot to check non-zero return code # becomes an impossible to miss exception >>> subprocess.xcall(["mkdir", "a/b"]) mkdir: cannot create directory `a/b': No such file or directory Traceback (most recent call last): File "", line 1, in ? File "subprocess.py", line 462, in xcall raise CalledProcessError(rc, "Command %s returned non zero exit status" % args[0]) subprocess.CalledProcessError: [Errno 1] Command ['mkdir', 'a/b'] returned non zero exit status >>> See attached patch for more! Its been tested under python 2.3 on windows and linux. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-01-01 10:37 Message: Logged In: YES user_id=344921 Patch applied. New revisions: subprocess.py 1.12 test_subprocess.py 1.17 libsubprocess.tex 1.5 ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-13 03:57 Message: Logged In: YES user_id=344921 If there are no objections, I will commit the "Adapted patch against trunk". ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-05 22:20 Message: Logged In: YES user_id=344921 My suggested name is "check_call". ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-01 15:04 Message: Logged In: YES user_id=344921 Since this is a new feature, the patch will go into trunk, but not the 2.4 maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470 From noreply at sourceforge.net Sat Jan 1 20:43:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 20:43:59 2005 Subject: [Patches] [ python-Patches-1094164 ] xml.dom.minidom.Node.replaceChild(obj, x, x) removes child x Message-ID: Patches item #1094164, was opened at 2005-01-01 20:43 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=1094164&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Felix Rabe (xitnalta) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom.minidom.Node.replaceChild(obj, x, x) removes child x Initial Comment: A child was removed from a node if an attempt was made to replace it with itself. The cause was the comparison "if newChild is oldChild:" happening too late in the function's code, so I moved it before the "newChild.parentNode" check. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094164&group_id=5470 From noreply at sourceforge.net Sat Jan 1 20:45:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 20:45:18 2005 Subject: [Patches] [ python-Patches-1094164 ] xml.dom.minidom.Node.replaceChild(obj, x, x) removes child x Message-ID: Patches item #1094164, was opened at 2005-01-01 20:43 Message generated for change (Comment added) made by xitnalta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094164&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Felix Rabe (xitnalta) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom.minidom.Node.replaceChild(obj, x, x) removes child x Initial Comment: A child was removed from a node if an attempt was made to replace it with itself. The cause was the comparison "if newChild is oldChild:" happening too late in the function's code, so I moved it before the "newChild.parentNode" check. ---------------------------------------------------------------------- >Comment By: Felix Rabe (xitnalta) Date: 2005-01-01 20:45 Message: Logged In: YES user_id=163986 The patch applies to CVS python/dist/src checked out half an hour ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094164&group_id=5470 From noreply at sourceforge.net Sun Jan 2 11:22:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 11:22:03 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 (Tracker Item Submitted) made by Item Submitter 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: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094387&group_id=5470 From noreply at sourceforge.net Sun Jan 2 19:26:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 19:26:41 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-02 11:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From noreply at sourceforge.net Sun Jan 2 20:20:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 20:20:12 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-02 13:26 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From noreply at sourceforge.net Mon Jan 3 08:17:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 08:17:55 2005 Subject: [Patches] [ python-Patches-1094815 ] self.button.pack() in tkinter.tex example Message-ID: Patches item #1094815, was opened at 2005-01-03 16:17 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=1094815&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: [N/A] (ymasuda) Assigned to: Nobody/Anonymous (nobody) Summary: self.button.pack() in tkinter.tex example Initial Comment: In section "Coupling Widget Variables", there is a meaningless line:: self.entrythingy.pack() self.button.pack() # <-- THIS ONE # here is the application variable self.contents = StringVar() This breaks execution of the sample:: Traceback (most recent call last): File "", line 29, in ? File "", line 11, in __init__ AttributeError: App instance has no attribute 'button' attached patch is for deletion of that line. # This was originally reported by Mr. Suzumizaki, to Python documentation translating project in Japan. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094815&group_id=5470 From noreply at sourceforge.net Mon Jan 3 18:38:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 18:38:16 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-02 19:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-01-03 18:38 Message: Logged In: YES user_id=1188172 Let me add that the main functionality consists in the easy initializing and updating (otherwise, you just could use an empty class). I'm +1 on the class, but I would call it `bunch'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From noreply at sourceforge.net Tue Jan 4 00:46:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 00:46:21 2005 Subject: [Patches] [ python-Patches-1095362 ] fixes urllib2 digest to allow arbitrary methods Message-ID: Patches item #1095362, was opened at 2005-01-03 15:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095362&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Reese (rrttjj) Assigned to: Nobody/Anonymous (nobody) Summary: fixes urllib2 digest to allow arbitrary methods Initial Comment: urllib2.AbstractDigestAuthHandler.get_authorization always forced the method to be either 'GET' or 'HEAD' when computing the digest. This meant that digest auth for any other method would fail automatically; for example, DELETE or PUT, for any HTTP servers that support them, or DAV verbs like PROPFIND. This single line change just calls Request.get_method instead of hardcoding the defaulting logic. Request.get_method still forces the method to be either GET or HEAD, but a determined caller can override Request if they need to use a different method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095362&group_id=5470 From noreply at sourceforge.net Tue Jan 4 05:05:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 05:06:00 2005 Subject: [Patches] [ python-Patches-851459 ] Argument passing from /usr/bin/idle2.3 to idle.py Message-ID: Patches item #851459, was opened at 2003-11-30 06:27 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470 Category: None Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Sean Reifschneider (jafo) Summary: Argument passing from /usr/bin/idle2.3 to idle.py Initial Comment: /usr/bin/idle2.3 wrapper (from the 2.3.2-1pydotorg rpm) ignores command-line arguments when calling idle.py. Fixed only by adding "$*" to the script. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2005-01-04 04:05 Message: Logged In: YES user_id=81797 I've tried checking out python23-maint, but the resulting tree I'm getting has the latest .spec file. I can make the changes to 2.3, but I need some help on how to get a tree I can check in against, or if I should submit patches to the tracker. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-22 18:15 Message: Logged In: YES user_id=149084 This really ought to get into release24-maint and probably release23-maint if you think anyone will ever build an rpm from 2.3.5 (which is due out soon). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-12-21 02:25 Message: Logged In: YES user_id=81797 I went ahead and turned this into Python code and called "execvp", passing the command arguments onto the idle call. This way there are no worries about how the shell handles $* expansion. The current CVS version results in something looking like: #!/usr/bin/env python2.4 import os, sys os.execvp("/usr/bin/python2.4", ["/usr/bin/python2.4", "/usr/lib/python2.4/idlelib/idle.py"] + sys.argv[1:]) print "Failed to exec Idle" sys.exit(1) (assuming default build settings) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-20 20:53 Message: Logged In: YES user_id=149084 Appears to be an issue with the Tools section of ..../Misc/RPM/python-2.4.spec Backport to release23-maint Assigning to Sean Reifschneider ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470 From noreply at sourceforge.net Tue Jan 4 09:15:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 09:15:30 2005 Subject: [Patches] [ python-Patches-1095541 ] fix for trivial flatten bug in astgen Message-ID: Patches item #1095541, was opened at 2005-01-04 03:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095541&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: fix for trivial flatten bug in astgen Initial Comment: The flatten in compiler.ast (from astgen) doesn't work for sublists, although the source shows it tries to: >>> compiler.ast.flatten([1,2,(3,4)]) [1, 2, 3, 4] >>> compiler.ast.flatten([1,2,[3,4]]) [1, 2, [3, 4]] The dangers of calling your lists 'list'.. (type is list check fails.) A brief glance suggests it gets called with tuples instead so I don't think the bug has any obvious consequences. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095541&group_id=5470 From noreply at sourceforge.net Tue Jan 4 15:47:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 15:47:54 2005 Subject: [Patches] [ python-Patches-1095784 ] exclude CVS conflict files in sdist command Message-ID: Patches item #1095784, was opened at 2005-01-04 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095784&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: exclude CVS conflict files in sdist command Initial Comment: I created a patch that adds CVS conflict files (ie. files starting with ".#") to the standard exclude list of source package files. Perhaps other versioning system files or directories (from arch, svk, etc.) should also be added to the exclude list. But since I do only work with CVS, this patch only adds the CVS conflict files. Patch is against CVS HEAD from 20050104. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095784&group_id=5470 From noreply at sourceforge.net Tue Jan 4 18:59:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 18:59:53 2005 Subject: [Patches] [ python-Patches-1007991 ] @decorators, including classes Message-ID: Patches item #1007991, was opened at 2004-08-12 10:53 Message generated for change (Settings changed) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007991&group_id=5470 Category: Parser/Compiler Group: Python 2.4 >Status: Closed >Resolution: Postponed Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Nobody/Anonymous (nobody) Summary: @decorators, including classes Initial Comment: This patch is modeled on the original @ patch #979728 Functions are now ignorant of their decorated status. The regular function & class functions are called from the com_decorated_thing() function which applies the decorators. the new Grammar production is decorated_thing: decorators (funcdef|classdef) passes all tests (including augmented test_decorators) com_decorated_thing() in compile.c uses a VAR_LOAD to get the class/function to decorate. There is probably an easier way to do this. I updated the compiler package (ast.txt, pycodegen.py, symbols.py, transformer.py) and it passes all tests but I'm not sure it is correct (the tests pass as long as they don't throw an exception). ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2005-01-04 12:59 Message: Logged In: YES user_id=591932 Closed the patch and marked it "postponed" I'd like to see class decorators in 2.5, I'll submit another patch at a later time (when hopefully more people are clamoring for it). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007991&group_id=5470 From noreply at sourceforge.net Tue Jan 4 20:20:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 20:21:02 2005 Subject: [Patches] [ python-Patches-1093253 ] Refactoring Python/import.c Message-ID: Patches item #1093253, was opened at 2004-12-30 13:50 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Refactoring Python/import.c Initial Comment: This patch refactores Python/import.c. find_module() was changed to return an PyObject* pointer which contains the module's pathname, instead of filling out a char* buffer. load_module() accepts the PyObject* pathname instead of a char*. The patch is probably missing some error checking, and the 8 character hack for loading extensions on OS2 is not implemented, but the test case runs without errors on Windows XP pro. If a change in spirit of this patch is accepted, I'm willing to further work on it so that eventually unicode entries on sys.path, which can not be encoded with the default file system encodings, will work as expected (currently they don't). See also: http://mail.python.org/pipermail/python-list/2004-December/256969.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2005-01-04 20:20 Message: Logged In: YES user_id=11105 New patch attached with multiple implementations of case_ok, and more error checking: import.c.patch2 Slightly tested on OSX, Linux, Windows. The case_ok function still needs to be fixed for RISCOS (which I cannot test). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-31 15:17 Message: Logged In: YES user_id=6656 Perhaps there should be multiple implementations of case_ok ... i.e. #if PLAT1 int case_ok(...) { ... } #elif PLAT2 int case_ok(...) { ... } #endif the current spaghetti is confusing, even by the standards of import.c... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-12-31 15:11 Message: Logged In: YES user_id=11105 Yes, I overlooked that the initialization of the variables is inside an #if defined(MS_WINDOWS) block. Probably it would be better to leave the signature of case_ok() as before and call it through a wrapper which converts the arguments. I will prepare a new patch in a few days. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-31 14:57 Message: Logged In: YES user_id=6656 Applied the patch and built on OS X. This was the result: $ ./python.exe 'import site' failed; use -v for traceback ../Python/import.c:1496: failed assertion `dirlen <= MAXPATHLEN' Abort trap dirlen is 796092779, which seems fishy :) An uninitialized variable, maybe? Haven't looked, really... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470 From noreply at sourceforge.net Wed Jan 5 05:09:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 05:10:03 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 17:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096231&group_id=5470 From noreply at sourceforge.net Wed Jan 5 08:15:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 08:15:27 2005 Subject: [Patches] [ python-Patches-742621 ] ast-branch: msvc project sync Message-ID: Patches item #742621, was opened at 2003-05-23 17:20 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742621&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Jeremy Hylton (jhylton) Summary: ast-branch: msvc project sync Initial Comment: The PCBuild project files weren't updated to reflect the new files used by ast-branch. Attached is a patch to get it back into sync. It also adds references to Python-ast.h and code.h to zipimport.c and pyexpat.c so that they will compile properly. Parsermodule still won't compile [for obvious reasons ;-)] I couldn't figure out how to setup a command-line script in VC 6.0, so the adsl_c.py script would still need to be done manually to get a working compile. If anyone knows how the _ssl project was setup to run a python script, I'd appreciate some pointers. ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2005-01-05 01:15 Message: Logged In: YES user_id=699438 I've attached an updated patch that gets things working against current cvs. This also includes some fixes for typos that appear to have slipped through gcc and my have caused obscure bugs in *nix as well. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-05-28 06:51 Message: Logged In: YES user_id=11105 Logistix, to add a command line project in MSVC6, you select 'Add new Project to workspace' from the pcbuild workspace context menu, and in the dialog that appears you click the 'Makefile' icon in the projects tab, enter a project name, click ok and then you can enter the command lines to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742621&group_id=5470 From noreply at sourceforge.net Wed Jan 5 16:56:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 16:56:57 2005 Subject: [Patches] [ python-Patches-851459 ] Argument passing from /usr/bin/idle2.3 to idle.py Message-ID: Patches item #851459, was opened at 2003-11-30 06:27 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Sean Reifschneider (jafo) Summary: Argument passing from /usr/bin/idle2.3 to idle.py Initial Comment: /usr/bin/idle2.3 wrapper (from the 2.3.2-1pydotorg rpm) ignores command-line arguments when calling idle.py. Fixed only by adding "$*" to the script. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2005-01-05 15:56 Message: Logged In: YES user_id=81797 mwh helped me get the right check-out of the maintenance releases. I've committed these changes to the 2.3 and 2.4 maintenance branches. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-01-04 04:05 Message: Logged In: YES user_id=81797 I've tried checking out python23-maint, but the resulting tree I'm getting has the latest .spec file. I can make the changes to 2.3, but I need some help on how to get a tree I can check in against, or if I should submit patches to the tracker. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-22 18:15 Message: Logged In: YES user_id=149084 This really ought to get into release24-maint and probably release23-maint if you think anyone will ever build an rpm from 2.3.5 (which is due out soon). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-12-21 02:25 Message: Logged In: YES user_id=81797 I went ahead and turned this into Python code and called "execvp", passing the command arguments onto the idle call. This way there are no worries about how the shell handles $* expansion. The current CVS version results in something looking like: #!/usr/bin/env python2.4 import os, sys os.execvp("/usr/bin/python2.4", ["/usr/bin/python2.4", "/usr/lib/python2.4/idlelib/idle.py"] + sys.argv[1:]) print "Failed to exec Idle" sys.exit(1) (assuming default build settings) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-20 20:53 Message: Logged In: YES user_id=149084 Appears to be an issue with the Tools section of ..../Misc/RPM/python-2.4.spec Backport to release23-maint Assigning to Sean Reifschneider ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470 From noreply at sourceforge.net Thu Jan 6 08:26:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 08:26:46 2005 Subject: [Patches] [ python-Patches-1096244 ] time.tzset() not built on Solaris Message-ID: Patches item #1096244, was opened at 2005-01-04 21:26 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096244&group_id=5470 >Category: Build >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Bond (gnbond) Assigned to: Nobody/Anonymous (nobody) Summary: time.tzset() not built on Solaris Initial Comment: The time.tzset() function is not included in Solaris builds, because the code in configure.in that checks for the existence of tzset() relies on struct tm having a tm_zone member - which Solaris does not have (at least not up to 2.8). The attached patch to configure.in allows Solaris to detect the existence of tzset() and Python builds OK, and the resulting time.tzset() function seems to work just fine. diff -u configure.in.DIST configure.in --- configure.in.DIST 2005-01-05 16:25:24.830001000 +1100 +++ configure.in 2005-01-05 16:25:38.227000000 +1100 @@ -2912,10 +2912,6 @@ tzset(); if (localtime(&groundhogday)->tm_hour != 11) exit(1); - if (strcmp(localtime(&groundhogday)->tm_zone, "AEDT")) - exit(1); - if (strcmp(localtime(&midyear)->tm_zone, "AEST")) - exit(1); exit(0); } ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-01-05 23:26 Message: Logged In: YES user_id=357491 But that fix removes a sanity check to detect broken tzset implementations. Is there a similar way to check on Solaris to make sure tzset is not broken? If so resubmit a patch (I reclassified this tracker item appropriately) that makes the test conditional on Solaris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096244&group_id=5470 From noreply at sourceforge.net Thu Jan 6 21:17:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 21:17:44 2005 Subject: [Patches] [ python-Patches-1093253 ] Refactoring Python/import.c Message-ID: Patches item #1093253, was opened at 2004-12-30 13:50 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Refactoring Python/import.c Initial Comment: This patch refactores Python/import.c. find_module() was changed to return an PyObject* pointer which contains the module's pathname, instead of filling out a char* buffer. load_module() accepts the PyObject* pathname instead of a char*. The patch is probably missing some error checking, and the 8 character hack for loading extensions on OS2 is not implemented, but the test case runs without errors on Windows XP pro. If a change in spirit of this patch is accepted, I'm willing to further work on it so that eventually unicode entries on sys.path, which can not be encoded with the default file system encodings, will work as expected (currently they don't). See also: http://mail.python.org/pipermail/python-list/2004-December/256969.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2005-01-06 21:17 Message: Logged In: YES user_id=11105 For easier reading, I've attached the complete, new Python/import.c file. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-01-04 20:20 Message: Logged In: YES user_id=11105 New patch attached with multiple implementations of case_ok, and more error checking: import.c.patch2 Slightly tested on OSX, Linux, Windows. The case_ok function still needs to be fixed for RISCOS (which I cannot test). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-31 15:17 Message: Logged In: YES user_id=6656 Perhaps there should be multiple implementations of case_ok ... i.e. #if PLAT1 int case_ok(...) { ... } #elif PLAT2 int case_ok(...) { ... } #endif the current spaghetti is confusing, even by the standards of import.c... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-12-31 15:11 Message: Logged In: YES user_id=11105 Yes, I overlooked that the initialization of the variables is inside an #if defined(MS_WINDOWS) block. Probably it would be better to leave the signature of case_ok() as before and call it through a wrapper which converts the arguments. I will prepare a new patch in a few days. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-31 14:57 Message: Logged In: YES user_id=6656 Applied the patch and built on OS X. This was the result: $ ./python.exe 'import site' failed; use -v for traceback ../Python/import.c:1496: failed assertion `dirlen <= MAXPATHLEN' Abort trap dirlen is 796092779, which seems fishy :) An uninitialized variable, maybe? Haven't looked, really... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470 From noreply at sourceforge.net Thu Jan 6 21:20:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 21:20:18 2005 Subject: [Patches] [ python-Patches-1093253 ] Refactoring Python/import.c Message-ID: Patches item #1093253, was opened at 2004-12-30 13:50 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Martin v. L?wis (loewis) Summary: Refactoring Python/import.c Initial Comment: This patch refactores Python/import.c. find_module() was changed to return an PyObject* pointer which contains the module's pathname, instead of filling out a char* buffer. load_module() accepts the PyObject* pathname instead of a char*. The patch is probably missing some error checking, and the 8 character hack for loading extensions on OS2 is not implemented, but the test case runs without errors on Windows XP pro. If a change in spirit of this patch is accepted, I'm willing to further work on it so that eventually unicode entries on sys.path, which can not be encoded with the default file system encodings, will work as expected (currently they don't). See also: http://mail.python.org/pipermail/python-list/2004-December/256969.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2005-01-06 21:20 Message: Logged In: YES user_id=11105 Martin, this is the first step for making unicode entries on sys.path work the way that is expected on Windows. You requested patches, so please take a look, if you have time. Otherwise, unassign yourself. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-01-06 21:17 Message: Logged In: YES user_id=11105 For easier reading, I've attached the complete, new Python/import.c file. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-01-04 20:20 Message: Logged In: YES user_id=11105 New patch attached with multiple implementations of case_ok, and more error checking: import.c.patch2 Slightly tested on OSX, Linux, Windows. The case_ok function still needs to be fixed for RISCOS (which I cannot test). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-31 15:17 Message: Logged In: YES user_id=6656 Perhaps there should be multiple implementations of case_ok ... i.e. #if PLAT1 int case_ok(...) { ... } #elif PLAT2 int case_ok(...) { ... } #endif the current spaghetti is confusing, even by the standards of import.c... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-12-31 15:11 Message: Logged In: YES user_id=11105 Yes, I overlooked that the initialization of the variables is inside an #if defined(MS_WINDOWS) block. Probably it would be better to leave the signature of case_ok() as before and call it through a wrapper which converts the arguments. I will prepare a new patch in a few days. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-31 14:57 Message: Logged In: YES user_id=6656 Applied the patch and built on OS X. This was the result: $ ./python.exe 'import site' failed; use -v for traceback ../Python/import.c:1496: failed assertion `dirlen <= MAXPATHLEN' Abort trap dirlen is 796092779, which seems fishy :) An uninitialized variable, maybe? Haven't looked, really... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470 From noreply at sourceforge.net Fri Jan 7 01:56:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 01:56:36 2005 Subject: [Patches] [ python-Patches-1096244 ] time.tzset() not built on Solaris Message-ID: Patches item #1096244, was opened at 2005-01-05 16:26 Message generated for change (Comment added) made by gnbond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096244&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Bond (gnbond) Assigned to: Nobody/Anonymous (nobody) Summary: time.tzset() not built on Solaris Initial Comment: The time.tzset() function is not included in Solaris builds, because the code in configure.in that checks for the existence of tzset() relies on struct tm having a tm_zone member - which Solaris does not have (at least not up to 2.8). The attached patch to configure.in allows Solaris to detect the existence of tzset() and Python builds OK, and the resulting time.tzset() function seems to work just fine. diff -u configure.in.DIST configure.in --- configure.in.DIST 2005-01-05 16:25:24.830001000 +1100 +++ configure.in 2005-01-05 16:25:38.227000000 +1100 @@ -2912,10 +2912,6 @@ tzset(); if (localtime(&groundhogday)->tm_hour != 11) exit(1); - if (strcmp(localtime(&groundhogday)->tm_zone, "AEDT")) - exit(1); - if (strcmp(localtime(&midyear)->tm_zone, "AEST")) - exit(1); exit(0); } ---------------------------------------------------------------------- >Comment By: Gregory Bond (gnbond) Date: 2005-01-07 11:56 Message: Logged In: YES user_id=293157 Hmm, I'm no autoconf guru, but try the attached patch. It seems to do the right thing on Solaris (tzset but no tm_zone) and FreeBSD (tzset and tm_zone). Amazing what you can find with half an hour of Google! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-06 18:26 Message: Logged In: YES user_id=357491 But that fix removes a sanity check to detect broken tzset implementations. Is there a similar way to check on Solaris to make sure tzset is not broken? If so resubmit a patch (I reclassified this tracker item appropriately) that makes the test conditional on Solaris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096244&group_id=5470 From noreply at sourceforge.net Fri Jan 7 02:44:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 02:44:09 2005 Subject: [Patches] [ python-Patches-1096244 ] time.tzset() not built on Solaris Message-ID: Patches item #1096244, was opened at 2005-01-05 16:26 Message generated for change (Comment added) made by gnbond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096244&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Bond (gnbond) Assigned to: Nobody/Anonymous (nobody) Summary: time.tzset() not built on Solaris Initial Comment: The time.tzset() function is not included in Solaris builds, because the code in configure.in that checks for the existence of tzset() relies on struct tm having a tm_zone member - which Solaris does not have (at least not up to 2.8). The attached patch to configure.in allows Solaris to detect the existence of tzset() and Python builds OK, and the resulting time.tzset() function seems to work just fine. diff -u configure.in.DIST configure.in --- configure.in.DIST 2005-01-05 16:25:24.830001000 +1100 +++ configure.in 2005-01-05 16:25:38.227000000 +1100 @@ -2912,10 +2912,6 @@ tzset(); if (localtime(&groundhogday)->tm_hour != 11) exit(1); - if (strcmp(localtime(&groundhogday)->tm_zone, "AEDT")) - exit(1); - if (strcmp(localtime(&midyear)->tm_zone, "AEST")) - exit(1); exit(0); } ---------------------------------------------------------------------- >Comment By: Gregory Bond (gnbond) Date: 2005-01-07 12:44 Message: Logged In: YES user_id=293157 I've added second patch with more comprehensive diffs that also checks whether tzset() affects tzname[] (for those systems without tm_zone). This may be considered overkill! ---------------------------------------------------------------------- Comment By: Gregory Bond (gnbond) Date: 2005-01-07 11:56 Message: Logged In: YES user_id=293157 Hmm, I'm no autoconf guru, but try the attached patch. It seems to do the right thing on Solaris (tzset but no tm_zone) and FreeBSD (tzset and tm_zone). Amazing what you can find with half an hour of Google! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-06 18:26 Message: Logged In: YES user_id=357491 But that fix removes a sanity check to detect broken tzset implementations. Is there a similar way to check on Solaris to make sure tzset is not broken? If so resubmit a patch (I reclassified this tracker item appropriately) that makes the test conditional on Solaris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096244&group_id=5470 From noreply at sourceforge.net Fri Jan 7 04:57:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 04:57:41 2005 Subject: [Patches] [ python-Patches-1096244 ] time.tzset() not built on Solaris Message-ID: Patches item #1096244, was opened at 2005-01-04 21:26 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096244&group_id=5470 Category: Build >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Bond (gnbond) >Assigned to: Brett Cannon (bcannon) Summary: time.tzset() not built on Solaris Initial Comment: The time.tzset() function is not included in Solaris builds, because the code in configure.in that checks for the existence of tzset() relies on struct tm having a tm_zone member - which Solaris does not have (at least not up to 2.8). The attached patch to configure.in allows Solaris to detect the existence of tzset() and Python builds OK, and the resulting time.tzset() function seems to work just fine. diff -u configure.in.DIST configure.in --- configure.in.DIST 2005-01-05 16:25:24.830001000 +1100 +++ configure.in 2005-01-05 16:25:38.227000000 +1100 @@ -2912,10 +2912,6 @@ tzset(); if (localtime(&groundhogday)->tm_hour != 11) exit(1); - if (strcmp(localtime(&groundhogday)->tm_zone, "AEDT")) - exit(1); - if (strcmp(localtime(&midyear)->tm_zone, "AEST")) - exit(1); exit(0); } ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-01-06 19:57 Message: Logged In: YES user_id=357491 Well, considering tzset can be called when HAVE_TZNAME is set it definitely does not hurt to check it. The patch basically looks good, but I don't have time right now for a thorough check so I am not going to check it in right away. But it will get in. ---------------------------------------------------------------------- Comment By: Gregory Bond (gnbond) Date: 2005-01-06 17:44 Message: Logged In: YES user_id=293157 I've added second patch with more comprehensive diffs that also checks whether tzset() affects tzname[] (for those systems without tm_zone). This may be considered overkill! ---------------------------------------------------------------------- Comment By: Gregory Bond (gnbond) Date: 2005-01-06 16:56 Message: Logged In: YES user_id=293157 Hmm, I'm no autoconf guru, but try the attached patch. It seems to do the right thing on Solaris (tzset but no tm_zone) and FreeBSD (tzset and tm_zone). Amazing what you can find with half an hour of Google! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-05 23:26 Message: Logged In: YES user_id=357491 But that fix removes a sanity check to detect broken tzset implementations. Is there a similar way to check on Solaris to make sure tzset is not broken? If so resubmit a patch (I reclassified this tracker item appropriately) that makes the test conditional on Solaris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096244&group_id=5470 From noreply at sourceforge.net Fri Jan 7 05:35:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 05:35:35 2005 Subject: [Patches] [ python-Patches-1094011 ] Docs for file() vs open() Message-ID: Patches item #1094011, was opened at 2005-01-01 02:50 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094011&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Raymond Hettinger (rhettinger) Summary: Docs for file() vs open() Initial Comment: This is in reference to the thread on python-dev starting 2004/07/07, subject "file() or open()?". Guido stated there that one should use open() to open files: """Anyway, here's my future-proof distinction: use open() as the factory function, and file for type-testing.""" The docs, however, still convince the reader that open() is retained for backwards compatibility and near deprecation. This patch corrects the issue, mostly using Guido's own new wording. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094011&group_id=5470 From noreply at sourceforge.net Fri Jan 7 07:28:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 07:31:57 2005 Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to AST Message-ID: Patches item #1097671, was opened at 2005-01-07 01:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Jeremy Hylton (jhylton) Summary: Info Associated with Merge to AST Initial Comment: Attached file is the output of the merge from MAIN to ast-branch. -j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC) (estimated time of first merge) -j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC) C Include/compile.h C Include/symtable.h C Lib/distutils/sysconfig.py C Lib/test/test_compile.py NOT MERGED C Lib/test/output/test_profile C Modules/main.c C Objects/listobject.c C Objects/tupleobject.c C Python/bltinmodule.c C Python/compile.c NOT MERGED C Python/future.c C Python/pythonrun.c C Python/symtable.c Other conflicts resolved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470 From noreply at sourceforge.net Fri Jan 7 07:32:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 07:34:13 2005 Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to AST Message-ID: Patches item #1097671, was opened at 2005-01-07 01:28 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Jeremy Hylton (jhylton) Summary: Info Associated with Merge to AST Initial Comment: Attached file is the output of the merge from MAIN to ast-branch. -j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC) (estimated time of first merge) -j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC) C Include/compile.h C Include/symtable.h C Lib/distutils/sysconfig.py C Lib/test/test_compile.py NOT MERGED C Lib/test/output/test_profile C Modules/main.c C Objects/listobject.c C Objects/tupleobject.c C Python/bltinmodule.c C Python/compile.c NOT MERGED C Python/future.c C Python/pythonrun.c C Python/symtable.c Other conflicts resolved. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-07 01:32 Message: Logged In: YES user_id=149084 Hm, file was a little too big. bzip2 it, 10x compression ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470 From noreply at sourceforge.net Fri Jan 7 09:15:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 09:16:05 2005 Subject: [Patches] [ python-Patches-751031 ] imghdr -- identify JPEGs in EXIF format Message-ID: Patches item #751031, was opened at 2003-06-08 15:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751031&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Steven Taschuk (staschuk) Assigned to: Raymond Hettinger (rhettinger) Summary: imghdr -- identify JPEGs in EXIF format Initial Comment: Someone posted to c.l.py [1] about some of their JPEGs not being identified as such by imghdr. Turns out they were EXIF files, and imghdr only identifies JFIF files. A little web research suggests EXIF is the usual format for JPEGS from digital cameras. The patch adds the ability to identify such files; they are reported as 'jpeg-exif'. I've no idea whether this is the Right Thing. [1] http://groups.google.com/groups?th=45c0442a1d74e9c4 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-07 03:15 Message: Logged In: YES user_id=80475 Added Exif detection to Py2.5. See Lib/imghdr.py 1.12 Exif is JFIF style coding where the APP1 marker has been added with extra information (thumbnail image and shooting data.) For a good overview of the coding, see: http://park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751031&group_id=5470 From noreply at sourceforge.net Fri Jan 7 11:06:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 11:06:41 2005 Subject: [Patches] [ python-Patches-1097739 ] Direct framework linking for MACOSX_DEPLOYMENT_TARGET < 10.3 Message-ID: Patches item #1097739, was opened at 2005-01-07 05:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097739&group_id=5470 Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Direct framework linking for MACOSX_DEPLOYMENT_TARGET < 10.3 Initial Comment: It is not a good idea to use -framework (even with -F) if it is necessary to link to a less-than-current framework. For Python, this is the case. This patch to configure.in should (in theory) resolve this issue. Note that since only the .in is patched, autoconf must be run after application. I have only tested the 10.3 scenario, but will comment as soon as the 10.2 build has finished and I've tested it. Background reading: http://bob.pythonmac.org/archives/2005/01/05/versioned- frameworks-considered-harmful/ http://mail.python.org/pipermail/python-dev/2005-January/ thread.html#50649 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097739&group_id=5470 From noreply at sourceforge.net Fri Jan 7 12:44:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 12:44:57 2005 Subject: [Patches] [ python-Patches-1097797 ] Encoding for Code Page 273 used by EBCDIC Germany Austria Message-ID: Patches item #1097797, was opened at 2005-01-07 11:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097797&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Bierenfeld (mbieren) Assigned to: Nobody/Anonymous (nobody) Summary: Encoding for Code Page 273 used by EBCDIC Germany Austria Initial Comment: CP273.TXT to be used with gencodec.py. Enables Communication with "old" IBM Mainframes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097797&group_id=5470 From noreply at sourceforge.net Fri Jan 7 13:25:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 13:25:45 2005 Subject: [Patches] [ python-Patches-1097797 ] Encoding for Code Page 273 used by EBCDIC Germany Austria Message-ID: Patches item #1097797, was opened at 2005-01-07 12:44 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097797&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Bierenfeld (mbieren) Assigned to: Nobody/Anonymous (nobody) Summary: Encoding for Code Page 273 used by EBCDIC Germany Austria Initial Comment: CP273.TXT to be used with gencodec.py. Enables Communication with "old" IBM Mainframes ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-01-07 13:25 Message: Logged In: YES user_id=38388 Can you provide a reference of where and how this encoding is used ? We also need information of where the attached file originated. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097797&group_id=5470 From noreply at sourceforge.net Fri Jan 7 14:09:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 14:09:07 2005 Subject: [Patches] [ python-Patches-1097739 ] Direct framework linking for MACOSX_DEPLOYMENT_TARGET < 10.3 Message-ID: Patches item #1097739, was opened at 2005-01-07 11:06 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097739&group_id=5470 Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Direct framework linking for MACOSX_DEPLOYMENT_TARGET < 10.3 Initial Comment: It is not a good idea to use -framework (even with -F) if it is necessary to link to a less-than-current framework. For Python, this is the case. This patch to configure.in should (in theory) resolve this issue. Note that since only the .in is patched, autoconf must be run after application. I have only tested the 10.3 scenario, but will comment as soon as the 10.2 build has finished and I've tested it. Background reading: http://bob.pythonmac.org/archives/2005/01/05/versioned- frameworks-considered-harmful/ http://mail.python.org/pipermail/python-dev/2005-January/ thread.html#50649 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-01-07 14:09 Message: Logged In: YES user_id=45365 Looks good. Checked in as configure.in 1.480, configure 1.467. Will backport to 2.4 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097739&group_id=5470 From noreply at sourceforge.net Fri Jan 7 15:45:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 15:45:44 2005 Subject: [Patches] [ python-Patches-1097797 ] Encoding for Code Page 273 used by EBCDIC Germany Austria Message-ID: Patches item #1097797, was opened at 2005-01-07 11:44 Message generated for change (Comment added) made by mbieren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097797&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Bierenfeld (mbieren) Assigned to: Nobody/Anonymous (nobody) Summary: Encoding for Code Page 273 used by EBCDIC Germany Austria Initial Comment: CP273.TXT to be used with gencodec.py. Enables Communication with "old" IBM Mainframes ---------------------------------------------------------------------- >Comment By: Michael Bierenfeld (mbieren) Date: 2005-01-07 14:45 Message: Logged In: YES user_id=1074928 The encoding is used on IBM Mainframes here in Germany and Austria. Mostly on "old" VM/VSE Machines. Rawdata is transferred via MQSeries and then encoded from "cp273" to "latin_1". The file has been translated from the original IBM RFC by myself. www.unicode.org has no equivalent file on their FTP-Servers (ftp://ftp.unicode.org/Public/MAPPINGS/). CP273 is an alias for this charset. source: IBM NLS RM Vol2 SE09-8002-01, March 1990 Regards Michael ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-01-07 12:25 Message: Logged In: YES user_id=38388 Can you provide a reference of where and how this encoding is used ? We also need information of where the attached file originated. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097797&group_id=5470 From noreply at sourceforge.net Sat Jan 8 13:32:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 13:32:25 2005 Subject: [Patches] [ python-Patches-1094015 ] Improvements for shutil.copytree() Message-ID: Patches item #1094015, was opened at 2005-01-01 09:26 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094015&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: Improvements for shutil.copytree() Initial Comment: See bugs #975763 and #1048878. The patch changes shutil.copytree() to use os.makedirs() instead of os.mkdir() and to copy directory bits using copystat(), because file bits are copied, too. It includes a doc change to mention these details. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 13:32 Message: Logged In: YES user_id=469548 Applied on HEAD. Thanks for the patch! Log message: Checking in Doc/lib/libshutil.tex; /cvsroot/python/python/dist/src/Doc/lib/libshutil.tex,v <-- libshutil.tex new revision: 1.16; previous revision: 1.15 done Checking in Lib/shutil.py; /cvsroot/python/python/dist/src/Lib/shutil.py,v <-- shutil.py new revision: 1.35; previous revision: 1.34 done ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094015&group_id=5470 From noreply at sourceforge.net Sat Jan 8 14:13:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 14:13:56 2005 Subject: [Patches] [ python-Patches-943206 ] Convert glob.glob to generator-based DFS Message-ID: Patches item #943206, was opened at 2004-04-27 20:25 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943206&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Convert glob.glob to generator-based DFS Initial Comment: `glob.glob()` currently calls itself recursively to build a list of matches of the dirname part of the pattern and then filters by the basename part. This is effectively BFS. ``glob.glob('*/*/*/*/*/foo')`` will build a huge list of all directories 5 levels deep even if only a handful of them contain a ``foo`` entry. A generator-based recusion would never have to store these list at once by implementing DFS. This patch converts the `glob` function to an `iglob` recursive generator . `glob()` now just returns ``list(iglob(pattern))``. I also cleaned up the code a bit (reduced duplicate `has_magic()` checks and created a second `glob0` helper func so that the main loop need not be duplicated). This patch assumes patch 941486 adding `os.path.lexists()` was applied; if not the lexists calls will have to be adjasted. Tests and docs patches included. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 14:13 Message: Logged In: YES user_id=469548 Checked in on HEAD. Thanks for the patch! Log message: Checking in Doc/lib/libglob.tex; /cvsroot/python/python/dist/src/Doc/lib/libglob.tex,v <-- libglob.tex new revision: 1.14; previous revision: 1.13 done Checking in Lib/glob.py; /cvsroot/python/python/dist/src/Lib/glob.py,v <-- glob.py new revision: 1.12; previous revision: 1.11 cvs diff: [13:13:17] waiting for jlgijsbers's lock in /cvsroot/python/python/dist/src/Doc/lib done Checking in Lib/test/test_glob.py; /cvsroot/python/python/dist/src/Lib/test/test_glob.py,v <-- test_glob.py new revision: 1.9; previous revision: 1.8 done ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-08-20 13:25 Message: Logged In: YES user_id=36166 Refreshed against current trunk (2.4a2+ 2004-08-20). It's a forward patch -p0, at dist/src. Again, it assumes patch 941486 (glob-pathfix.diff version) had been applied; if not s/lexists/exists/g but then neither version of 941486 will apply cleanly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943206&group_id=5470 From noreply at sourceforge.net Sat Jan 8 14:56:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 14:57:01 2005 Subject: [Patches] [ python-Patches-1079734 ] Make cgi.py use email instead of rfc822 or mimetools Message-ID: Patches item #1079734, was opened at 2004-12-06 05:22 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079734&group_id=5470 Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Josh Hoyt (joshhoyt) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Make cgi.py use email instead of rfc822 or mimetools Initial Comment: Remove dependencies on (deprecated) rfc822 and mimetools modules, replacing with email. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 14:56 Message: Logged In: YES user_id=469548 Checked in as rev 1.83 of cgi.py. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079734&group_id=5470 From noreply at sourceforge.net Sat Jan 8 21:18:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 21:18:35 2005 Subject: [Patches] [ python-Patches-936774 ] pydoc data descriptor unification Message-ID: Patches item #936774, was opened at 2004-04-17 07:07 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936774&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John Belmonte (jbelmonte) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: pydoc data descriptor unification Initial Comment: This patch to pydoc unifies the display of data descriptors, including slots, properties, and custom descriptors. The changes are as follows: * removed special handling of properties * added special handling of data descriptors - All data descriptors are grouped together in a section. For each item, the attribute name and doc string, if present, is displayed. * disabled display of __slots__ attribute - since slots are descriptors, they are listed in the section described above A complementary change to Python will be to support setting of doc strings on slots. The proposal is to use dictionary values when __slots__ is a dictionary object, as suggested in Guido's "Unifying types and classes". The rationale for these changes is described in . ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 21:18 Message: Logged In: YES user_id=469548 Checked in as rev 1.102 of pydoc.py, with some minor changes: * renamed _docproperty to _docdescriptor * made names of data descriptors bold, and put a newline between each of them, to be consistent with the rest of the methods and data ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936774&group_id=5470 From noreply at sourceforge.net Sun Jan 9 01:39:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 01:39:48 2005 Subject: [Patches] [ python-Patches-1051321 ] xml.dom missing API docs (bugs 1010196, 1013525) Message-ID: Patches item #1051321, was opened at 2004-10-21 10:38 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1051321&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mike Brown (mike_j_brown) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: xml.dom missing API docs (bugs 1010196, 1013525) Initial Comment: This patch addresses bugs 1013525 ("xml.dom documentation omits createDocument, ...DocumentType") and 1010196 ("xml.dom documentation omits hasAttribute, hasAttributeNS") In the documentation for createDocument(), it is now stated that the Python DOM API allows implementations to forego creation of the document element child node, if no namespace and local name arguments are given. (This possibility is left open and unaddressed in the W3C spec). The patch also fixes a broken reference to an external document, and adds a mention that the Python DOM API does not require enforcement of W3C DOM requirements that are not accounted for in the IDL definitions upon which the Python mapping is based. The patch was developed against Python 2.4b1's /python/dist/src/Doc/lib/xmldom.tex and is untested. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:39 Message: Logged In: YES user_id=469548 Documentation is correct as far as I can see. Checked in on HEAD and maint24. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1051321&group_id=5470 From noreply at sourceforge.net Sun Jan 9 02:41:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 02:41:15 2005 Subject: [Patches] [ python-Patches-1017550 ] Fix for bug 1017546 Message-ID: Patches item #1017550, was opened at 2004-08-27 14:26 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1017550&group_id=5470 Category: Tests Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Michael (ms_) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug 1017546 Initial Comment: Attached patch is against current Anon CVS - this patch ensures that if any tests fail any files that require cleaning up are cleaned up. It's a minimal touch patch rather than anything else. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:40 Message: Logged In: YES user_id=469548 The new test_inspect no longer writes temporary files, so I'm closing this patch. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-28 14:14 Message: Logged In: YES user_id=469548 Note that I've ported test_inspect to unittest a few days ago. It's currently waiting for review at http://python.org/sf/736962. I think it fixes bug 1017546 as well, but it would be nice if you could take a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1017550&group_id=5470 From noreply at sourceforge.net Sun Jan 9 02:59:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 02:59:13 2005 Subject: [Patches] [ python-Patches-1098732 ] Enhance tracebacks and stack traces with vars Message-ID: Patches item #1098732, was opened at 2005-01-08 19:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1098732&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance tracebacks and stack traces with vars Initial Comment: I think it would be useful to sometimes have local variable values printed with tracebacks and stack frames. The attached patch is a first cut at that. I don't know if people would want that as the default, so I've defaulted argument printing to disabled. With arg printing enabled, executing this script: #!/usr/bin/env python import sys import traceback def exch(ty, val, tb): traceback.print_exception(ty, val, tb, args=True) sys.excepthook = exch def f(n,d): return n/d def g(a): return a/(a-1) for i in range(5,-1,-1): print g(i) displays this output: 1 1 1 2 Traceback (most recent call last): File "/Users/skip/tmp/tb.py", line 17, in ? print g(i) exch: f: g: i: 1 File "/Users/skip/tmp/tb.py", line 14, in g return a/(a-1) a: 1 ZeroDivisionError: integer division or modulo by zero ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1098732&group_id=5470 From noreply at sourceforge.net Sun Jan 9 03:04:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 03:04:55 2005 Subject: [Patches] [ python-Patches-1079729 ] Make cgi.py use logging module Message-ID: Patches item #1079729, was opened at 2004-12-06 05:05 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079729&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Josh Hoyt (joshhoyt) Assigned to: Nobody/Anonymous (nobody) Summary: Make cgi.py use logging module Initial Comment: The attached patch makes the CGI module use the logging module for logging. There is no change in behaviour for the old idioms of using the cgi module's built-in logging facility, but this allows users to use the logging framework to direct and format log messages. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 03:04 Message: Logged In: YES user_id=469548 You might want to follow the proposal in PEP 337 (create a cgi._log, use py. prefix). Of course, you could also disagree with the PEP, in which case you should take it up on python-dev ;). Either way, please assign this to me once you've got a PEP behind you and I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079729&group_id=5470 From noreply at sourceforge.net Sun Jan 9 04:01:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 04:01:57 2005 Subject: [Patches] [ python-Patches-1098749 ] Single-line option to pygettext.py Message-ID: Patches item #1098749, was opened at 2005-01-09 03:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1098749&group_id=5470 Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: Single-line option to pygettext.py Initial Comment: i added an option that make pygettext consider certain multi-line strings as single-line strings. If you're using an editor like kbabel, it's nice, you don't see the newlines. This comes really handy for strings to be used as HTML, where line breaks don't matter (and I'm sure for many other uses). You can select which keywords trigger this special extraction. All the other gettext tools work normally. Default behaviour does not change. I use it something like this: POTCMD = pygettext.py --verbose --extract-all --no-default-keywords --keyword-single=_ --keyword-single=N_ --keyword=__ ... pot: $(POTCMD) -d $(PROJECT) -p $(dir $@) $(PYFILES) cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1098749&group_id=5470 From noreply at sourceforge.net Sun Jan 9 06:54:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 06:54:31 2005 Subject: [Patches] [ python-Patches-1095362 ] fixes urllib2 digest to allow arbitrary methods Message-ID: Patches item #1095362, was opened at 2005-01-04 00:46 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095362&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John Reese (rrttjj) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: fixes urllib2 digest to allow arbitrary methods Initial Comment: urllib2.AbstractDigestAuthHandler.get_authorization always forced the method to be either 'GET' or 'HEAD' when computing the digest. This meant that digest auth for any other method would fail automatically; for example, DELETE or PUT, for any HTTP servers that support them, or DAV verbs like PROPFIND. This single line change just calls Request.get_method instead of hardcoding the defaulting logic. Request.get_method still forces the method to be either GET or HEAD, but a determined caller can override Request if they need to use a different method. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 06:54 Message: Logged In: YES user_id=469548 A very determined caller indeed. I've checked in the patch on maint24 and HEAD. Less duplication and more flexibility never hurt anyone, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095362&group_id=5470 From noreply at sourceforge.net Sun Jan 9 16:11:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 16:11:05 2005 Subject: [Patches] [ python-Patches-684944 ] extend readline functionality in pdb Message-ID: Patches item #684944, was opened at 2003-02-11 23:09 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684944&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: extend readline functionality in pdb Initial Comment: This patch allows readline completion of global and local variables while running code under pdb. Currently completion only works with the builtin pdb commands when in pdb. This patch uses the default pdb completer (in cmd.Cmd) to preserve the old completions, but adds completions in the current pdb execution frame. Patch is against current cvs. Let me know what you think. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 16:11 Message: Logged In: YES user_id=469548 I like the idea, but the implementation is currently too inclusive. It does completion the same for all commands, even for those where that doesn't make sense, such as enable, disable and quit. I'd accept a patch that used 'complete_*' functions for the individual commands where the completion makes sense. Let me know if you're still interested on working on this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684944&group_id=5470 From noreply at sourceforge.net Sun Jan 9 16:32:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 16:32:53 2005 Subject: [Patches] [ python-Patches-712317 ] Bug fix 548176: urlparse('http://foo?blah') errs Message-ID: Patches item #712317, was opened at 2003-03-30 22:16 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712317&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Steven Taschuk (staschuk) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Bug fix 548176: urlparse('http://foo?blah') errs Initial Comment: For detailed description of the problem, see http://www.python.org/sf/548176 In summary, URLs such as http://www.example.com?query=spam are misparsed by urlparse.urlparse, which decides that everything after the '//' is the host name. This is contrary to RFC 2396 and probably contrary to the intent of RFC 1738. The patch corrects the problem, adds a test to expose it, and rearranges some of the tests to better exercise the code in question. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 16:32 Message: Logged In: YES user_id=469548 See bug #548176 for why this patch is okay anyway. Checked in on maint24 and HEAD. ---------------------------------------------------------------------- Comment By: Mike Rovner (mrovner) Date: 2004-01-27 02:15 Message: Logged In: YES user_id=162094 -1. See my comment at http://www.python.org/sf/548176 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712317&group_id=5470 From noreply at sourceforge.net Sun Jan 9 18:09:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 18:09:22 2005 Subject: [Patches] [ python-Patches-707900 ] bug fix 702858: deepcopying reflexive objects Message-ID: Patches item #707900, was opened at 2003-03-22 05:08 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707900&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Neal Norwitz (nnorwitz) Summary: bug fix 702858: deepcopying reflexive objects Initial Comment: A fix for bug 702858, which concerns the inability of copy.deepcopy to correctly process reflexive new-style class instances, that is, instances referring to themselves. The fix is one line; the other 51 lines in the patch are altered and enhanced altered tests in test_copy.py for this kind of thing. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 18:09 Message: Logged In: YES user_id=469548 Closing this, as no 2.2 bugfix release if forthcoming anymore. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 05:27 Message: Logged In: YES user_id=33168 I'm working on this (slowly). It wasn't a simple backport. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-13 21:29 Message: Logged In: YES user_id=6380 Reopened - Neal, would you mind backporting this to 2.2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-13 21:27 Message: Logged In: YES user_id=6380 Looks fine to me; classic instances already did the same thing. Thanks, Steven! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 17:28 Message: Logged In: YES user_id=31435 Assigned to Guido because he knows more about this and I'm out of time for the next two days. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 16:42 Message: Logged In: YES user_id=33168 This patch works on 2.3. I'm not sure if this is fixing a bug or a feature. The change seems reasonable, but I don't know enough about copy to know if there are any negative consequences. I can check in if someone else agrees. Tim? Guido? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707900&group_id=5470 From noreply at sourceforge.net Sun Jan 9 18:11:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 18:11:12 2005 Subject: [Patches] [ python-Patches-737999 ] minor codeop fixes Message-ID: Patches item #737999, was opened at 2003-05-15 03:55 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737999&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Samuele Pedroni (pedronis) Summary: minor codeop fixes Initial Comment: *) compile_command("",eval) -> None , previously raised syntax error about "pass" *) symbol must be eval or single, now raises ValueError accordingly as specified in the documentation patch both for 2.3 and 2.2 maint for codeop.py and test/test_codeop.py (beefed up) (for Jython at the moment we use the test suite of 2.2 maint, that's why this is relevant) ---------------------------------------------------------------------- Comment By: Samuele Pedroni (pedronis) Date: 2003-05-17 04:46 Message: Logged In: YES user_id=61408 committed: test_codeop.py 1.6 test_codeop.py 1.3.12.1 (release22-maint) codeop.py 1.5.16.1 (release22-maint) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-16 14:00 Message: Logged In: YES user_id=6656 Given that codeop has *never* lived up to its promise to raise ValueError on 'exec', perhaps the docs should be fixed rather than the code? (I don't understand the point of supporting anything but 'single', but...). Certainly this change *should not* be made on the 22-maint branch. Can you check in your tests to both branches and port Guido's codeop.py change? Fixing up the docs gets you extra points, I think :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737999&group_id=5470 From noreply at sourceforge.net Mon Jan 10 01:44:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 01:44:30 2005 Subject: [Patches] [ python-Patches-839496 ] SimpleHTTPServer reports wrong content-length for text files Message-ID: Patches item #839496, was opened at 2003-11-10 21:42 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839496&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer reports wrong content-length for text files Initial Comment: (Python 2.3.2 on Windows) SimpleHTTPServer reports the size of the file on disk as Content-Length. This works except for text files. If the content type starts with "text/" it is opening the file in 'text' mode rather than 'binary' mode. At least on Windows this causes newline translations, thereby making the actual size of the content transmitted *less* than the content-length! I don't know why SimpleHTTPServer is reading text files with text mode. The included patch removes this distinction so all files are opened in binary mode (and, also on windows, the actual size transmitted is the same as the reported content-length). --Irmen de Jong ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2005-01-10 01:44 Message: Logged In: YES user_id=129426 Upon re-reading the w3 spec, it seems that we're safe. As long as the use of CR or LF or CR+LF is consistent in the whole text file. The spec says: "HTTP relaxes this requirement [=the requirement of being in canonical form] and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP." So my patch is safe, I think. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-07-19 22:59 Message: Logged In: YES user_id=129426 Hm, perhaps the easy way out (see my patch) is not the best solution: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 It seems it's best to convert text responses to CR LF format? If we should do this, we must somehow 're-calculate' the content-length after the CR LF conversion. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-06-06 13:18 Message: Logged In: YES user_id=129426 The attached httptest.zip contains a test scenario. When run on windows, it will show the problem. First start 'startserver.py' and then from the same directory run test.py. I get this: [E:\temp\httptest]python test.py The reported content-length is: 1047 bytes The real filesize is: 1047 bytes The data I actually received from the httpserver is: 1028 bytes ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-05-31 18:51 Message: Logged In: YES user_id=129426 The attached trivial patch removes the special case for text files. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-05-13 13:21 Message: Logged In: YES user_id=129426 This bug is also still present in the SimpleHTTPServer.py from Python 2.3.3 (and in the current CVS version, too). Is there a reason why it treats text files differently? If so, then at least the reported content-length must be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839496&group_id=5470 From noreply at sourceforge.net Mon Jan 10 10:28:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 10:28:12 2005 Subject: [Patches] [ python-Patches-839496 ] SimpleHTTPServer reports wrong content-length for text files Message-ID: Patches item #839496, was opened at 2003-11-10 21:42 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839496&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Irmen de Jong (irmen) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: SimpleHTTPServer reports wrong content-length for text files Initial Comment: (Python 2.3.2 on Windows) SimpleHTTPServer reports the size of the file on disk as Content-Length. This works except for text files. If the content type starts with "text/" it is opening the file in 'text' mode rather than 'binary' mode. At least on Windows this causes newline translations, thereby making the actual size of the content transmitted *less* than the content-length! I don't know why SimpleHTTPServer is reading text files with text mode. The included patch removes this distinction so all files are opened in binary mode (and, also on windows, the actual size transmitted is the same as the reported content-length). --Irmen de Jong ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-10 10:28 Message: Logged In: YES user_id=469548 Okay, I've checked in the fix on maint24 and HEAD. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-10 01:44 Message: Logged In: YES user_id=129426 Upon re-reading the w3 spec, it seems that we're safe. As long as the use of CR or LF or CR+LF is consistent in the whole text file. The spec says: "HTTP relaxes this requirement [=the requirement of being in canonical form] and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP." So my patch is safe, I think. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-07-19 22:59 Message: Logged In: YES user_id=129426 Hm, perhaps the easy way out (see my patch) is not the best solution: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 It seems it's best to convert text responses to CR LF format? If we should do this, we must somehow 're-calculate' the content-length after the CR LF conversion. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-06-06 13:18 Message: Logged In: YES user_id=129426 The attached httptest.zip contains a test scenario. When run on windows, it will show the problem. First start 'startserver.py' and then from the same directory run test.py. I get this: [E:\temp\httptest]python test.py The reported content-length is: 1047 bytes The real filesize is: 1047 bytes The data I actually received from the httpserver is: 1028 bytes ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-05-31 18:51 Message: Logged In: YES user_id=129426 The attached trivial patch removes the special case for text files. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-05-13 13:21 Message: Logged In: YES user_id=129426 This bug is also still present in the SimpleHTTPServer.py from Python 2.3.3 (and in the current CVS version, too). Is there a reason why it treats text files differently? If so, then at least the reported content-length must be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839496&group_id=5470 From noreply at sourceforge.net Mon Jan 10 15:08:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 15:08:42 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-02 13:26 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2005-01-10 09:08 Message: Logged In: YES user_id=99874 Would someone be willing to provide the motivation for adding this class? I'm certainly willing to listen, but I'm not convinced this is worth adding to the std library. (I guess that's a -0 vote.) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-01-03 12:38 Message: Logged In: YES user_id=1188172 Let me add that the main functionality consists in the easy initializing and updating (otherwise, you just could use an empty class). I'm +1 on the class, but I would call it `bunch'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From noreply at sourceforge.net Mon Jan 10 16:15:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 16:15:09 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-02 11:26 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- >Comment By: Steven Bethard (bediviere) Date: 2005-01-10 08:15 Message: Logged In: YES user_id=945502 I submitted a PEP for it on 2 Jan 2005, but I haven't heard back from peps@python.org yet. Sorry, I didn't realize it might take so long to get a PEP number. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-01-10 07:08 Message: Logged In: YES user_id=99874 Would someone be willing to provide the motivation for adding this class? I'm certainly willing to listen, but I'm not convinced this is worth adding to the std library. (I guess that's a -0 vote.) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-01-03 10:38 Message: Logged In: YES user_id=1188172 Let me add that the main functionality consists in the easy initializing and updating (otherwise, you just could use an empty class). I'm +1 on the class, but I would call it `bunch'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From noreply at sourceforge.net Tue Jan 11 14:18:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 14:18:37 2005 Subject: [Patches] [ python-Patches-1100140 ] improved smtp connect debugging Message-ID: Patches item #1100140, was opened at 2005-01-11 14:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100140&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: improved smtp connect debugging Initial Comment: The current SMTP debug code prints three times the same tuple (host, port). I changed the second and third one to print the IP address and error msg. Attached is a diff against current CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100140&group_id=5470 From noreply at sourceforge.net Tue Jan 11 17:53:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 17:57:20 2005 Subject: [Patches] [ python-Patches-1054967 ] bdist_deb - Debian packager Message-ID: Patches item #1054967, was opened at 2004-10-27 02:48 Message generated for change (Comment added) made by leonidasxiv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 Category: Distutils and setup.py Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Sean Reifschneider (jafo) Summary: bdist_deb - Debian packager Initial Comment: Here's a first crack at a bdist_deb. This patch implements two new distutils commands: bdist_deb: Build Debian packages debianize: Create and populate a top-level debian subdirectory. (Essentially dh_make for distutils packages.) There is a slightly detailed README.bdist_deb included in the patches. I'm open to suggestions for improvements and bug-fixes. ---------------------------------------------------------------------- Comment By: Marek Kubica (leonidasxiv) Date: 2005-01-11 17:53 Message: Logged In: YES user_id=872713 I was looking a long time for something like this. I really hope seeing this in Python 2.5, although I'm not familiar with Python's development process. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-11 17:18 Message: Logged In: YES user_id=45814 Another updated patch set. The only change is a bug fix: when using a hand-build set of debian/* files, dh_make will now deduce the correct Debian revision and build architecture. (Bug reported by Bastian Kleineidam.) Patches, as always are on today's CVS version of distutils. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 16:39 Message: Logged In: YES user_id=170840 I've created a patch to make your bdist_deb/dh_make commands compatible with Python 1.5.2; it can be found here: http://erlug.linux.it/~da/tmp/distutils-cvs_debpy152-20041109.patch Beware that I've tested it for a very short time, so double check everything (especially the permissions on file/umasks). Moreover, the patch changes also some other files like build_py.py, install_lib.py, bdist_rpm.py, that were not 1.5.2 compatible - these changes are part of another patch I've posted today. HTH. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-08 22:38 Message: Logged In: YES user_id=45814 Another updated patch set: As suggested by Bastian Kleineidam, when the source distribution includes it's own debian subdirectory, bdist_deb (rather than just crapping out) will now skip the dh_make stage, and just run debuild. As always, patches on the current CVS version of distutils are attached below. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-02 23:20 Message: Logged In: YES user_id=45814 Here's try number three! Changes are mostly fixes for woody. The README.bdist_deb (included in the patch set) enumerates the changes in more detail. (I've bitten the bullet and installed woody on one of my machines, so I'm fairly confident it should work now.) The patches, on todays CVS are, as always, attached below. ==== Note to Davide, Thank you, again, very much for all the testing. A couple of the lintian warnings ('prerm-does-not-remove-usr-doc-link' and 'postinst-does-not-set-usr-doc-link') that are listed in your test suite output are due, I think, to your mixed system. Specifically, I suspect you've got the woody version of lintian (which wants to see symlinks from /usr/doc/ to /usr/share/doc/), but a later version of debhelper. (Woody's dh_installdocs (in the debhelper package) automatically generates those links, later versions don't; /usr/doc has been phased out.) Anyhow, I'm not going to fix those warnings (unless it turns out that you're seeing them on your pure woody system.) On package with python scripts (in /usr/bin) Woody's lintian generates an 'unusual-interpreter' warning which I think is spurious (i.e. it is not a valid warning.) (Lintian 1.20.17 doesn't recognize things like /usr/bin/python2.1 as a valid interpreter --- it seems valid enough to me.) Best Regards, Jeff ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-30 10:57 Message: Logged In: YES user_id=170840 I've tried the 29/10 patch with my home system (dpkg-dev 1.10, debhelper 4.1.90 and dh-make 0.30) and another "pure woody" system (dpkg-dev 1.9.21, debhelper 4.0.2 and dh-make 0.30). I've used your test suite and some of my personal projects (using both bdist_deb and dh_make); as far as I can tell, it works very well. :-) bdist_deb always worked as expected, producing good debian packages. I've used dh_make and then I've run "dpkg-buildpackage -rfakeroot" and I got some errors (but I'm not sure they depends on your code). Also your test suite produced some failures. Here you can find the output of "dpkg-buildpackage -rfakeroot" and of your tests suite (both were running on my home system): http://erlug.linux.it/~da/tmp/dpkg-buildpackage http://erlug.linux.it/~da/tmp/testsuite Thank you for your great effort! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-10-29 21:38 Message: Logged In: YES user_id=45814 Thanks for the comments. Here's a second attempt. Changes include: It might work with woody. (I'd appreciate it if you could try again, Davide) 'debianize' command renamed to 'dh_make'. Use debchange to create debian/changelog. This eliminates the need to duplicate debchange's logic to deduce the packagers name and e-mail. A more complete test script. Patches are on today's CVS. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-27 16:47 Message: Logged In: YES user_id=170840 I've a woody with some packages backported from sarge (debhelper 4.1.90 and dpkg-dev 1.10). Running python2.3 ./setup.py bdist_deb with some of my projects, I got the error: dpkg-buildpackage: unknown option or argument --check-dirname-level=1 Debian dpkg-buildpackage . Commenting out the "check-dirname-level" and "check-dirname-regex" options in the bdist_deb.py file the script can go on, but it exits with the error: debian/rules:11: *** first argument to `word' function must be greater than 0. Stop. Hope this helps. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-10-27 05:44 Message: Logged In: YES user_id=81797 I'm just doing a review of this code. A couple of things: There's been some concern expressed about get_default_maintainer. Namely, that if debchange changes it's algorithm, it won't be reflected in this code. It seems like one possible way around that would be to build a directory with a "debian" directory under it, a fake "changelog", and then call debchange to write the data out, and parse it. Too bad there's not a direct hook into debchange to get that information. Can _formatdate, if email doesn't exist, use rfc822.formatdate()? Ditto for _parseaddr? It looks pretty good. However, when trying to build a .deb of my jotweb2 package, it's failing with: [...] dh_testdir dh_testroot dh_installchangelogs- dh_installdocs cp: cannot stat `doc': No such file or directory dh_installdocs: command returned error code 256 [...] I'm not sure exactly why. I do have a "doc" directory in my main package directory, but I don't reference to it in my setup.py or MANIFEST. Adding it to the MANIFEST doesn't seem to help this. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 From noreply at sourceforge.net Tue Jan 11 18:11:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 18:12:00 2005 Subject: [Patches] [ python-Patches-1100294 ] Log gc times when DEBUG_STATS set Message-ID: Patches item #1100294, was opened at 2005-01-11 11:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100294&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Log gc times when DEBUG_STATS set Initial Comment: The attached patch adds collection time to the information the garbage collector prints when DEBUG_STATS is enabled. I was more-or-less challenged at work to show that garbage collection wouldn't cripple our long-running, high-performance servers at crucial times. This seemed the best way to demonstrate that it didn't present a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100294&group_id=5470 From noreply at sourceforge.net Tue Jan 11 23:20:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 23:20:33 2005 Subject: [Patches] [ python-Patches-742621 ] ast-branch: msvc project sync Message-ID: Patches item #742621, was opened at 2003-05-23 17:20 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742621&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Jeremy Hylton (jhylton) Summary: ast-branch: msvc project sync Initial Comment: The PCBuild project files weren't updated to reflect the new files used by ast-branch. Attached is a patch to get it back into sync. It also adds references to Python-ast.h and code.h to zipimport.c and pyexpat.c so that they will compile properly. Parsermodule still won't compile [for obvious reasons ;-)] I couldn't figure out how to setup a command-line script in VC 6.0, so the adsl_c.py script would still need to be done manually to get a working compile. If anyone knows how the _ssl project was setup to run a python script, I'd appreciate some pointers. ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2005-01-11 16:20 Message: Logged In: YES user_id=699438 Attaching updated patch for VC7.1. Patches 3 files. pcbuild.vcprod xml config file to add new files and remove old. No impact on linux builds. pc/config.c removes reference to parsermodule file. No impact on linux builds. newcompile.c required a one-line change to an array prototype. Using the keyword 'static' causes VC to think that it's the real array def and it complains because there is no data. Commenting out 'static' fixes the problem. Unsure of impact on other builds. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-01-05 01:15 Message: Logged In: YES user_id=699438 I've attached an updated patch that gets things working against current cvs. This also includes some fixes for typos that appear to have slipped through gcc and my have caused obscure bugs in *nix as well. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-05-28 06:51 Message: Logged In: YES user_id=11105 Logistix, to add a command line project in MSVC6, you select 'Add new Project to workspace' from the pcbuild workspace context menu, and in the dialog that appears you click the 'Makefile' icon in the projects tab, enter a project name, click ok and then you can enter the command lines to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742621&group_id=5470 From noreply at sourceforge.net Wed Jan 12 01:49:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 01:49:27 2005 Subject: [Patches] [ python-Patches-1100562 ] deepcopying listlike and dictlike objects Message-ID: Patches item #1100562, was opened at 2005-01-12 01:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100562&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: deepcopying listlike and dictlike objects Initial Comment: This patch should fix this https://sourceforge.net/tracker/index.php?func=detail&aid=1099746&group_id=5470&atid=105470 problem. It does it by changing the order in which objects are deepcopied. First the attributes and then the list/dict elements are copied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100562&group_id=5470 From noreply at sourceforge.net Wed Jan 12 01:50:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 01:50:05 2005 Subject: [Patches] [ python-Patches-1100563 ] ast-branch: fix for coredump from new import grammar Message-ID: Patches item #1100563, was opened at 2005-01-11 18:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100563&group_id=5470 Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: ast-branch: fix for coredump from new import grammar Initial Comment: New import grammar causes a coredump in the ast- branch. Attached is a fix. After this is applied we start getting coredumps from generator expressions in the test suite. I'm reasonably sure (and correct me if I'm wrong) that the generator expressions fix is more elaborate, as it requires patches to the bytecode generation as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100563&group_id=5470 From noreply at sourceforge.net Wed Jan 12 01:50:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 01:50:37 2005 Subject: [Patches] [ python-Patches-1100563 ] ast-branch: fix for coredump from new import grammar Message-ID: Patches item #1100563, was opened at 2005-01-11 18:50 Message generated for change (Settings changed) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100563&group_id=5470 Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Jeremy Hylton (jhylton) Summary: ast-branch: fix for coredump from new import grammar Initial Comment: New import grammar causes a coredump in the ast- branch. Attached is a fix. After this is applied we start getting coredumps from generator expressions in the test suite. I'm reasonably sure (and correct me if I'm wrong) that the generator expressions fix is more elaborate, as it requires patches to the bytecode generation as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100563&group_id=5470 From noreply at sourceforge.net Wed Jan 12 05:50:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 05:50:57 2005 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 12:55 Message generated for change (Comment added) made by mdr0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- >Comment By: Mark D. Roth (mdr0) Date: 2005-01-11 22:50 Message: Logged In: YES user_id=994239 Sorry for the delayed response; I've been out of town for a while. I understand the point about being able to create threads as needed using asynchat/asyncore. However, if there is no advantage to using the SocketServer framework, why is it there? Is it just for backward compatibility? There are a number of modules in the standard library that use the SocketServer framework. Is an effort being made to rewrite all of them to use asynchat/asyncore? Or are these modules simply grandfathered in, even though no new SocketServer modules are being accepted? In any case, for anyone that might be interested, here's a new version of BaseSMTPServer with the following changes: * Fixed a few incorrect SMTP reply codes. * Imrproved EOF handling. Please let me know what you thinlk. Thanks! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-12-18 14:08 Message: Logged In: YES user_id=366566 Regarding blocking process_message implementations: there really is no issue here. If a blocking operation needs to be performed, then a thread can be created inside process_message. Nothing is gained by starting a thread any earlier than this. Arguably, it is even a loss since it is more computationally and resource intensive to do so. Support for blocking message processing therefore does not seem to be sufficient reason for including this module. Are there other advantages? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-10 01:36 Message: Logged In: YES user_id=341410 It still has a couple tabs, but I don't believe that is a big deal. I think it fits in with the standard SocketServer framework, and that it would make sense to add it, but I don't have any authority to make decisions. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-10 00:40 Message: Logged In: YES user_id=994239 Here's a new version of BaseSMTPServer with the following changes: * Added lots of documentation. * Changed code style to conform with PEP 8. * Added allow_host() method. * Added smtp_NOOP() method. * Improved interface to process_message() and access-control methods. Please let me know what you think. Thanks! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 16:20 Message: Logged In: YES user_id=341410 Hrm, nevemind, I just noticed mdr0's post. I'll leave the rest up to someone who has the authority to make decisions. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 16:11 Message: Logged In: YES user_id=341410 Re: features Aside from NOOP (which is easily added), the provided BaseSMTPServer seems to offer the same amount of functionality as smtpd (ignoring DebuggingServer, PureProxy and MailmanProxy, which are trivially borrowed from smtpd). Re: What's the benefit... Someone who wanted to use a synchronous SMTP server would have one available. I think that we should probably wait until the original author answers how this relates to smtpd.py, and perhaps decide then. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-07 01:11 Message: Logged In: YES user_id=994239 Yes, I am aware of smtpd.py. My understanding is (although please correct me if I'm wrong) that the asyncore/asynchat framework will not be able to service network clients if the found_terminator() method performs an operation that blocks. The BaseSMTPServer class doesn't suffer from that problem, because it's threaded. If you're interested in integrating this module, I'd be happy to clean it up to conform with the Python style guidelines, add documentation, and implement the allow_host() method. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 03:43 Message: Logged In: YES user_id=92689 I just wanted to check whether the author _knows_ smtpd.py, since he doesn't mention it. Maybe I should put it more bluntly: What's the benefit of having an incompatible, less featureful, threaded version of smtpd.py in the library? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 03:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 01:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Wed Jan 12 14:52:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 14:53:01 2005 Subject: [Patches] [ python-Patches-723312 ] ability to pass a timeout to underlying socket Message-ID: Patches item #723312, was opened at 2003-04-17 21:03 Message generated for change (Comment added) made by gregweb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 6 Submitted By: Matthew Russell (mattruss) Assigned to: Skip Montanaro (montanaro) Summary: ability to pass a timeout to underlying socket Initial Comment: this patch superceeds an earlier one i posted (#714592) - a bit *too* enthusiastic am afraid (sorry!) classes in modules such as httplib, ftpplib do not currently allow an easy way to take advantage of the new socket timeout feature in 2.3. This patch provides that abilty though one additonal class in socket.py ( socket.NetworkConnection ) and accompying test in test_socket.py (basic though the test is :-s ) As an extra benifit, the patch removes duplicate code, as each connect method in the main class of most modules (FTP, HTTPConnection, Telnet, POP3 etc) are copies of each other. The modules that use sockets are: * ftplib * httplib * telnetlib * poplib * urllib * imaplib * nntplib * xmlrpclib Of these I have only been able to easily refactor NetworkConnection into httplib, ftplib, telnetllib, poplib and smtplib. I did look to see if there were any unittests for theese modules in .Lib/test but found none (? - I appologise if there are some, i am new to the library tests) I did however check that the test() [like] methods at the bottom of each of the afore mentioned modules worked. thanks for your advice again Skip :o) Matt ---------------------------------------------------------------------- Comment By: Gr?goire Weber (gregweb) Date: 2005-01-12 14:52 Message: Logged In: YES user_id=812601 Just lobbying: It would be nice to have that on board in futire python versions. Would this be possible in python 2.4.1? I need timeouts for xmlrpclib and subclassed xmlrpclib.Transport for my needs. But nevertheless it would be nice to have that in python 2.4.1. Thanks! Gregoire ---------------------------------------------------------------------- Comment By: Matthew Russell (mattruss) Date: 2003-04-21 01:20 Message: Logged In: YES user_id=737261 Errata: i forgot to mention urlllib2 as modules affected. the line above starting "The modules that use sockets are: " should really read: "classes in the modules stated below would benifit from the ability pass timeouts:" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 From noreply at sourceforge.net Wed Jan 12 15:53:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 15:53:03 2005 Subject: [Patches] [ python-Patches-1100942 ] datetime.strptime constructor added Message-ID: Patches item #1100942, was opened at 2005-01-12 14:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100942&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Josh (josh-sf) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.strptime constructor added Initial Comment: Alllow creating new datetime objects by parsing date strings. datetime already has strftime, so adding strptime is logical. The new constructor is equivalent to datetime(*(time.strptime(date_string, format)[0:6])). Patch includes documentation and unit test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100942&group_id=5470 From noreply at sourceforge.net Wed Jan 12 19:14:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 19:14:45 2005 Subject: [Patches] [ python-Patches-1101097 ] Feed style codec API Message-ID: Patches item #1101097, was opened at 2005-01-12 19:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Feed style codec API Initial Comment: The attached patch implements a feed style codec API by adding feed methods to StreamReader and StreamWriter (see SF patch #998993 for a history of this issue). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 From noreply at sourceforge.net Thu Jan 13 06:51:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 06:51:55 2005 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 15:35 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) >Assigned to: Kurt B. Kaiser (kbk) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 05:46 Message: Logged In: YES user_id=6656 bugger, wrong report :-/ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 05:45 Message: Logged In: YES user_id=6656 This looks much better to me! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 20:11 Message: Logged In: YES user_id=341410 What problem is needed? Perhaps you mean "this solution is desireable". ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 15:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 15:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 15:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\Documents and Settings\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\bob') '~billy\bob' >>> ntpath.expanduser('~\bob') 'C:\Documents and Settings\jcarlson\bob' >>> ntpath.expanduser('~billy\%TESTING%\%TESTING1%\%TESTING2%') '~billy\%TESTING%\%TESTING1%\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\billy' >>> ntpath_patched.expanduser('~billy\bob') 'C:Documents and Settings\billy\bob' >>> ntpath_patched.expanduser('~\bob') 'C:Documents and Settings\jcarlson\bob' >>> ntpath_patched.expanduser('~billy\%TESTING%\%TESTING1%\%TESTING2%') 'C:Documents and Settings\billy\Final\Path\Final\Path\Final\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Thu Jan 13 16:45:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 16:45:23 2005 Subject: [Patches] [ python-Patches-1101726 ] Patch for potential buffer overrun in tokenizer.c Message-ID: Patches item #1101726, was opened at 2005-01-13 06:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for potential buffer overrun in tokenizer.c Initial Comment: The fp_readl function in tokenizer.c has a potential buffer overrun; see: www.python.org/sf/1089395 It is also triggered by trying to generate the pycom file for the Excel 11.0 typelib, which is where I ran into it. The attached patch allows successful generation of the Excel file; it also runs the fail.py script from the above report without an access violation. It also doesn't break any of the tests in the regression suite (probably something like fail.py should be added as a test). It is not as efficient as it might be; with a function for determining the number of unicode characters in a utf8 string, you could avoid some memory allocations. Perhaps such a function should be added to unicodeobject.c? And, of course, the patch definitely needs review. I'm especially concerned that my use of tok->decoding_buffer might be violating some kind of assumption that I missed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 From luciagomes8475z at hotmail.com Fri Jan 14 23:33:28 2005 From: luciagomes8475z at hotmail.com (Lucia Gomes) Date: Fri Jan 14 23:33:28 2005 Subject: [Patches] listagem de e-mails Message-ID: <20050114223327.44AFE1E4012@bag.python.org> Mais Emails, venda online de listas de email, fazemos mala direta e propaganda de sua empresa ou neg?cio para milh?es de emails. Temos listas de email Mala Direta, Mala-Direta, Cadastro de Emails, Lista de Emails, Mailing List, Milh?es de Emails, Programas de Envio de Email, Email Bombers, Extratores de Email, Listas Segmentadas de Email, Emails Segmentados, Emails em Massa, E-mails http://www.estacion.de/maladireta Temos listas de email Mala Direta, Mala-Direta, Cadastro de Emails, Lista de Emails, Mailing List, Milh?es de Emails, Programas de Envio de Email, Email Bombers, Extratores de Email, Listas Segmentadas de Email, Emails Segmentados, Emails em Massa, E-mails http://www.estacion.de/maladireta From noreply at sourceforge.net Sat Jan 15 00:37:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 00:37:50 2005 Subject: [Patches] [ python-Patches-1102710 ] ast-branch: hacks so asdl_c.py generates compilable code Message-ID: Patches item #1102710, was opened at 2005-01-14 17:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102710&group_id=5470 Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: ast-branch: hacks so asdl_c.py generates compilable code Initial Comment: This isn't the most clean or proper patch, but it makes sure that asdl.c doesn't need to be edited by hand after it is generated by asdl_c.py. Implementing decorators and genexps will require adjustments to the Python.asdl file, and I'd rather not have to keep on re-correcting the output while implementing them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102710&group_id=5470 From noreply at sourceforge.net Sat Jan 15 00:38:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 00:38:18 2005 Subject: [Patches] [ python-Patches-1102710 ] ast-branch: hacks so asdl_c.py generates compilable code Message-ID: Patches item #1102710, was opened at 2005-01-14 17:37 Message generated for change (Settings changed) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102710&group_id=5470 Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Jeremy Hylton (jhylton) Summary: ast-branch: hacks so asdl_c.py generates compilable code Initial Comment: This isn't the most clean or proper patch, but it makes sure that asdl.c doesn't need to be edited by hand after it is generated by asdl_c.py. Implementing decorators and genexps will require adjustments to the Python.asdl file, and I'd rather not have to keep on re-correcting the output while implementing them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102710&group_id=5470 From noreply at sourceforge.net Sat Jan 15 12:37:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 12:37:27 2005 Subject: [Patches] [ python-Patches-1102879 ] Fix for 926423: socket timeouts + Ctrl-C don't play nice Message-ID: Patches item #1102879, was opened at 2005-01-15 12:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 926423: socket timeouts + Ctrl-C don't play nice Initial Comment: Please have a close look at the attached patch. Essentially, it fixes internal_select to not return zero on error condition, and also adds a test for errno at all calls to internal_select. A few remarks: 1) as indicated in the patch, I'm not sure if errno should also be tested in the internal_connect function; 2) 'timeout' is no longer a boolean indicating a timeout condition, it should probably be renamed to 'selectresult' or something similar; 3) I'm not too happy with the fact that the if(timeout==-1 && erro) test must be duplicated in a lot of functions; 4) does it do the right thing? The check for timeout==-1 MUST be there otherwise a lot of errors turn up in the regression tests. With this patch they run fine, btw ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 From noreply at sourceforge.net Sat Jan 15 20:34:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 20:34:19 2005 Subject: [Patches] [ python-Patches-1103046 ] Boxing up PyDECREF correctly Message-ID: Patches item #1103046, was opened at 2005-01-15 20:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Norbert Nemec (nnemec) Assigned to: Nobody/Anonymous (nobody) Summary: Boxing up PyDECREF correctly Initial Comment: The patch below solves problem in cases like: if(something) PyDECREF(xxx) else dosomethingelse(); (Patch against Python 2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 From noreply at sourceforge.net Sat Jan 15 23:23:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 23:23:29 2005 Subject: [Patches] [ python-Patches-1103116 ] AF_NETLINK sockets basic support Message-ID: Patches item #1103116, was opened at 2005-01-15 23:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103116&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Philippe Biondi (drphil) Assigned to: Nobody/Anonymous (nobody) Summary: AF_NETLINK sockets basic support Initial Comment: This patch adds everything needed to manipulate NETLINK addresses so that it is possible to use NETLINK sockets. Nothing is done in the patch for autoconf stuff, even if the following should do the trick : --- configure.in.ori 2005-01-10 17:09:32.000000000 +0100 +++ configure.in 2005-01-06 18:53:18.000000000 +0100 @@ -967,7 +967,7 @@ sys/audioio.h sys/bsdtty.h sys/file.h sys/loadavg.h sys/lock.h sys/mkdev.h sys/modem.h sys/param.h sys/poll.h sys/select.h sys/socket.h sys/time.h sys/times.h -sys/un.h sys/utsname.h sys/wait.h pty.h libutil.h +sys/un.h linux/netlink.h sys/utsname.h sys/wait.h pty.h libutil.h sys/resource.h netpacket/packet.h sysexits.h bluetooth.h bluetooth/bluetooth.h) AC_HEADER_DIRENT --- pyconfig.h.ori 2005-01-10 17:11:11.000000000 +0100 +++ pyconfig.h 2005-01-06 19:27:33.000000000 +0100 @@ -559,6 +559,9 @@ /* Define to 1 if you have the header file. */ #define HAVE_SYS_UN_H 1 +/* Define to 1 if you have the header file. */ +#define HAVE_LINUX_NETLINK_H 1 + /* Define to 1 if you have the header file. */ #define HAVE_SYS_UTSNAME_H 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103116&group_id=5470 From noreply at sourceforge.net Sun Jan 16 01:28:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 01:28:43 2005 Subject: [Patches] [ python-Patches-1103116 ] AF_NETLINK sockets basic support Message-ID: Patches item #1103116, was opened at 2005-01-15 23:23 Message generated for change (Comment added) made by drphil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103116&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Philippe Biondi (drphil) Assigned to: Nobody/Anonymous (nobody) Summary: AF_NETLINK sockets basic support Initial Comment: This patch adds everything needed to manipulate NETLINK addresses so that it is possible to use NETLINK sockets. Nothing is done in the patch for autoconf stuff, even if the following should do the trick : --- configure.in.ori 2005-01-10 17:09:32.000000000 +0100 +++ configure.in 2005-01-06 18:53:18.000000000 +0100 @@ -967,7 +967,7 @@ sys/audioio.h sys/bsdtty.h sys/file.h sys/loadavg.h sys/lock.h sys/mkdev.h sys/modem.h sys/param.h sys/poll.h sys/select.h sys/socket.h sys/time.h sys/times.h -sys/un.h sys/utsname.h sys/wait.h pty.h libutil.h +sys/un.h linux/netlink.h sys/utsname.h sys/wait.h pty.h libutil.h sys/resource.h netpacket/packet.h sysexits.h bluetooth.h bluetooth/bluetooth.h) AC_HEADER_DIRENT --- pyconfig.h.ori 2005-01-10 17:11:11.000000000 +0100 +++ pyconfig.h 2005-01-06 19:27:33.000000000 +0100 @@ -559,6 +559,9 @@ /* Define to 1 if you have the header file. */ #define HAVE_SYS_UN_H 1 +/* Define to 1 if you have the header file. */ +#define HAVE_LINUX_NETLINK_H 1 + /* Define to 1 if you have the header file. */ #define HAVE_SYS_UTSNAME_H 1 ---------------------------------------------------------------------- >Comment By: Philippe Biondi (drphil) Date: 2005-01-16 01:28 Message: Logged In: YES user_id=340305 This additionnal patch give a more correct use of PyArg_ParseTuple --- socketmodule.c.ori 2005-01-15 23:55:47.000000000 +0100 +++ socketmodule.c 2005-01-16 01:25:54.000000000 +0100 @@ -1106,7 +1106,7 @@ args->ob_type->tp_name); return 0; } - if (!PyArg_ParseTuple(args, "II", &pid, &groups)) + if (!PyArg_ParseTuple(args, "II:getsockaddrarg", &pid, &groups)) return 0; addr->nl_family = AF_NETLINK; addr->nl_pid = pid; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103116&group_id=5470 From noreply at sourceforge.net Sun Jan 16 01:34:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 01:34:41 2005 Subject: [Patches] [ python-Patches-1103046 ] Boxing up PyDECREF correctly Message-ID: Patches item #1103046, was opened at 2005-01-15 14:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Norbert Nemec (nnemec) Assigned to: Nobody/Anonymous (nobody) Summary: Boxing up PyDECREF correctly Initial Comment: The patch below solves problem in cases like: if(something) PyDECREF(xxx) else dosomethingelse(); (Patch against Python 2.4) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-15 19:34 Message: Logged In: YES user_id=31435 What problem? It's intended that you put a semicolon following Py_DECREF() invocations, and if you do I don't see any problem here. The "do ... while(0)" trick isn't optimized away by all compilers, so it's not without cost. Because Py_DECREF appears a *lot* in the source code, I don't want its expansion to introduce needless overheads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 From noreply at sourceforge.net Sun Jan 16 01:57:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 01:57:03 2005 Subject: [Patches] [ python-Patches-1103046 ] Boxing up PyDECREF correctly Message-ID: Patches item #1103046, was opened at 2005-01-15 14:34 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Norbert Nemec (nnemec) Assigned to: Nobody/Anonymous (nobody) Summary: Boxing up PyDECREF correctly Initial Comment: The patch below solves problem in cases like: if(something) PyDECREF(xxx) else dosomethingelse(); (Patch against Python 2.4) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-15 19:57 Message: Logged In: YES user_id=80475 Sorry, I concur with Tim. The "problem" has not not proven to be a real world issue in the many years that Python has been in the wild. For some compilers, there is a cost to the "solution". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-15 19:34 Message: Logged In: YES user_id=31435 What problem? It's intended that you put a semicolon following Py_DECREF() invocations, and if you do I don't see any problem here. The "do ... while(0)" trick isn't optimized away by all compilers, so it's not without cost. Because Py_DECREF appears a *lot* in the source code, I don't want its expansion to introduce needless overheads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 From noreply at sourceforge.net Sun Jan 16 02:01:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 02:01:37 2005 Subject: [Patches] [ python-Patches-1103046 ] Boxing up PyDECREF correctly Message-ID: Patches item #1103046, was opened at 2005-01-15 14:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Norbert Nemec (nnemec) Assigned to: Nobody/Anonymous (nobody) Summary: Boxing up PyDECREF correctly Initial Comment: The patch below solves problem in cases like: if(something) PyDECREF(xxx) else dosomethingelse(); (Patch against Python 2.4) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-15 20:01 Message: Logged In: YES user_id=31435 I wanted to hear what "the problem" was first . If, e.g., it's some overly helpful compiler complaining about a non-existing (in reality) ambiguity about if/else pairing, then sticking the "if" part in a block (delimit it with curly braces) should shut it up. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-15 19:57 Message: Logged In: YES user_id=80475 Sorry, I concur with Tim. The "problem" has not not proven to be a real world issue in the many years that Python has been in the wild. For some compilers, there is a cost to the "solution". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-15 19:34 Message: Logged In: YES user_id=31435 What problem? It's intended that you put a semicolon following Py_DECREF() invocations, and if you do I don't see any problem here. The "do ... while(0)" trick isn't optimized away by all compilers, so it's not without cost. Because Py_DECREF appears a *lot* in the source code, I don't want its expansion to introduce needless overheads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 From noreply at sourceforge.net Sun Jan 16 05:02:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 05:02:33 2005 Subject: [Patches] [ python-Patches-1103213 ] Adding the missing socket.recvall() method Message-ID: Patches item #1103213, was opened at 2005-01-16 05:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103213&group_id=5470 Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: Adding the missing socket.recvall() method Initial Comment: This patch is a first take at adding a recvall method to the socket object, to mirror the existence of the sendall method. If the MSG_WAITALL flag is available, the recvall method just calls recv() with that flag. If it is not available, it uses an internal loop (during the loop, threads are allowed, so this improves concurrency). Having this method makes Python code much simpler; before you had to test for MSG_WAITALL yourself and write your own loop in Python if the flag is not there (on Windows for instance). (also, having the loop in C improves performance and concurrency compared to the same loop in Python) Note: the patch hasn't been tested very well yet. (code is based on a separate extension module found here: http://www.it-ernst.de/python/ ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103213&group_id=5470 From noreply at sourceforge.net Sun Jan 16 10:32:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 10:32:50 2005 Subject: [Patches] [ python-Patches-1103046 ] Boxing up PyDECREF correctly Message-ID: Patches item #1103046, was opened at 2005-01-15 20:34 Message generated for change (Comment added) made by nnemec You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Norbert Nemec (nnemec) Assigned to: Nobody/Anonymous (nobody) Summary: Boxing up PyDECREF correctly Initial Comment: The patch below solves problem in cases like: if(something) PyDECREF(xxx) else dosomethingelse(); (Patch against Python 2.4) ---------------------------------------------------------------------- >Comment By: Norbert Nemec (nnemec) Date: 2005-01-16 10:32 Message: Logged In: YES user_id=621175 OK, sorry - the original problem really was a rather confusing warning for the statement if(something) Py_DECREF(xxx); The compiler warned about an ambiguous "else", so I had to dig into the Python sources to understand the problem. Constructing the case above I mixed something up and thought there might be an even bigger problem, which is, of course, not the case. So: it falls back to just a potential obscure warning compared to some potential overhead. Obviously you prefer the obscure warning... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-16 02:01 Message: Logged In: YES user_id=31435 I wanted to hear what "the problem" was first . If, e.g., it's some overly helpful compiler complaining about a non-existing (in reality) ambiguity about if/else pairing, then sticking the "if" part in a block (delimit it with curly braces) should shut it up. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-16 01:57 Message: Logged In: YES user_id=80475 Sorry, I concur with Tim. The "problem" has not not proven to be a real world issue in the many years that Python has been in the wild. For some compilers, there is a cost to the "solution". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-16 01:34 Message: Logged In: YES user_id=31435 What problem? It's intended that you put a semicolon following Py_DECREF() invocations, and if you do I don't see any problem here. The "do ... while(0)" trick isn't optimized away by all compilers, so it's not without cost. Because Py_DECREF appears a *lot* in the source code, I don't want its expansion to introduce needless overheads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 From noreply at sourceforge.net Sun Jan 16 14:04:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 14:04:51 2005 Subject: [Patches] [ python-Patches-1100140 ] improved smtp connect debugging Message-ID: Patches item #1100140, was opened at 2005-01-11 14:18 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100140&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: improved smtp connect debugging Initial Comment: The current SMTP debug code prints three times the same tuple (host, port). I changed the second and third one to print the IP address and error msg. Attached is a diff against current CVS. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-16 14:04 Message: Logged In: YES user_id=469548 Checked in on HEAD. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100140&group_id=5470 From noreply at sourceforge.net Sun Jan 16 16:23:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 16:26:48 2005 Subject: [Patches] [ python-Patches-946207 ] Non-blocking Socket Server Message-ID: Patches item #946207, was opened at 2004-05-02 04:45 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946207&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Assigned to: Nobody/Anonymous (nobody) Summary: Non-blocking Socket Server Initial Comment: Changed the included Python 2.3.3 SocketServer.py to be non-blocking. I have made a web-server on BaseHTTPServer, but the server could get shot down externally by sending malformed request. Making it very Easy to Perform a Denial of Service. The problem also exists in "Module Docs" web-server To experience problem run Module Docs, and verify that web-server is working telnet to webserver (telnet 127.0.0.1 7464#) type "GET /\r" access any web-page on web-server and notice how it is hung. Replace existing SocketServer.py with included SocketServer.py and re-test noticing that the problem is gone. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:23 Message: Logged In: YES user_id=129426 There's nothing wrong with the default socket server. It is blocking by design. The module provides a few mixins that change the way the requests are handled (see mmangino's comment) Making it threaded by default wouldn't work because not all systems support threading. That's why there is also the forking mixin. ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-13 21:46 Message: Logged In: YES user_id=74879 Actually, forget the previous request. The better change would be for you to create a ThreadedHTTPServer that inherits from SocketServer.ThreadingTCPServer, i.e. you could use class ThreadingHTTPServer(SocketServer.ThreadingTCPServer): allow_reuse_address = 1 # Seems to make sense in testing environment def server_bind(self): """Override server_bind to store the server name.""" SocketServer.TCPServer.server_bind(self) host, port = self.socket.getsockname()[:2] self.server_name = socket.getfqdn(host) self.server_port = port And then start the server with httpd = ThreadingHTTPServer(server_address,handler) ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-13 21:21 Message: Logged In: YES user_id=74879 Can you post a diff for this to make it easier to understand what has changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946207&group_id=5470 From noreply at sourceforge.net Sun Jan 16 16:34:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 16:34:07 2005 Subject: [Patches] [ python-Patches-756021 ] Allow socket.inet_aton(" 255.255.255.255" ) on Windows Message-ID: Patches item #756021, was opened at 2003-06-17 18:30 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756021&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Gertzfield (che_fox) Assigned to: Nobody/Anonymous (nobody) Summary: Allow socket.inet_aton("255.255.255.255") on Windows Initial Comment: Currently there's an XXX comment in socketmodule.c for the Windows implementation (actually, for any platform that doesn't have inet_aton) of socket.inet_aton: /* XXX Problem here: inet_aton('255.255.255.255') raises an exception while it should be a valid address. */ This patch (against Python CVS) fixes this problem by special-casing "255.255.255.255" as input when inet_addr returns -1 (usually an error). We just strcmp() the input string with "255.255.255.255" if inet_addr returned -1; if it matches, we allow PyString_FromStringAndSize() to do its thing on -1. Also, I noticed that the unit tests for module.inet_aton and friends were skipped if the platform didn't have inet_pton; this is an obvious error, and so I've split out the tests for inet_pton and inet_ntop's IPv4 functionality from inet_aton and inet_ntoa, as well as adding an explicit test for the now-handled "255.255.255.255" case. Finally, I haven't gotten CVS python to build on Windows under Visual Studio.NET (I get 'invalid project errors' when it tries to convert the VS6 project files -- and I don't have VS6) although I've tested this patch and the new tests on Debian Linux. This patch really should be applied to the 2.2 maintenance branch as well as 2.3, since "255.255.255.255" is a legal IP address and is not documented to raise an exception in the Python docs (even though it does currently on Windows). ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:34 Message: Logged In: YES user_id=129426 Looks good but I have one suggestion: isn't it better to test for "255.255.255.255" before calling inet_addr and then return '\xff\xff\xff\xff' directly, rather than relying on INADDR_NONE being 0xffffffff ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756021&group_id=5470 From noreply at sourceforge.net Sun Jan 16 16:41:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 16:41:59 2005 Subject: [Patches] [ python-Patches-740827 ] add urldecode() method to urllib Message-ID: Patches item #740827, was opened at 2003-05-21 02:43 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: add urldecode() method to urllib Initial Comment: Adds a urldecode() method to urllib. The method does the opposite of urlencode, turns a url-encoded string into a list of two-tuples of name/value pairs. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:41 Message: Logged In: YES user_id=129426 I've always found it strange that url-manipulating methods were present in the cgi module. I agree that it would be nicer to have them grouped together in a single module such as urlparse. So I wouldn't add urldecode to urllib. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 18:00 Message: Logged In: YES user_id=357491 I think so, but I don't know which one. I only use urllib.urlopen ever so if you have a specific suggestion from experience please make it and submit a patch. Since I don't use either modules extensively someone else is going to need to step in and help make any final decisions. ---------------------------------------------------------------------- Comment By: Matthew Boedicker (mboedick) Date: 2003-05-21 16:25 Message: Logged In: YES user_id=119895 It is not different than cgi.parse_qsl. Must have missed that module when I was looking for this functionality. To me it seems like urlencode and urldecode (as well as quote, quote_plus, unquote, etc.) belong in urlparse. Do you think it would be valuable to include a pointer to cgi.parse_qsl in urllib or urllparse? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 05:21 Message: Logged In: YES user_id=357491 How is this different from cgi.parse_sql ? If it is not different, consider just having a wrapper for urldecode that calls cgi.parse_sql . Do you think urllib is the best place for this? What about urlparse? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 From noreply at sourceforge.net Sun Jan 16 16:48:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 16:48:56 2005 Subject: [Patches] [ python-Patches-579435 ] Shadow Password Support Module Message-ID: Patches item #579435, was opened at 2002-07-10 05:13 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lance Ellinghaus (ellinghaus) Assigned to: A.M. Kuchling (akuchling) Summary: Shadow Password Support Module Initial Comment: Attached is the spwd module. This module provides support for Shadow Passwords on Solaris 2.8. This compliments the nis and pwd modules. This is the only way to gain access to the encrypted passwords when using shadow passwords on Solaris. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:48 Message: Logged In: YES user_id=129426 I would be happy if this module in one form or another makes it into Python; I recently wanted to do user authentication based on unix passwords but the regular passwd functions cannot retrieve the password to check against). As an aside, how does PAM relate to this? I fooled around a bit with a python pam module, but simply didn't understand it and couldn't get it to work properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 18:38 Message: Logged In: YES user_id=21627 If we eventually want to support all the shadow passwort APIs, we should make this a separate module - with that approach, building spwd can might fail without causing a failure to compile pwd. Unfortunately, the patch is still incomplete: there is no change to setup.py, and no documentation change. Are there any volunteers interesting in completing it? If not, I'm going to close it again. Anybody hunting for such a module will still be able to find it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-01-13 16:32 Message: Logged In: YES user_id=11375 As it happens, I was hunting for Python shadow password support and came across this patch. The module isn't Solaris-specific, and would be necessary on Linux, too. However, the interface for getting shadow passwords doesn't seem to be standardized; see http://www.unixpapa.com/incnote/passwd. html for a list. (The Single Unix spec doesn't seem to mention shadow passwords.) One question is whether we want a new module for this, or if the functions should be in the existing pwd module. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:22 Message: Logged In: YES user_id=33168 There doesn't seem to be much interest in this patch. I don't think it reaches a wide-enough audience, therefore, I'm rejecting it. If there is broader support (many people are interested in seeing shadow password support in the core), we can add it later. I think it would be best to provide this as a third-party module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 From noreply at sourceforge.net Sun Jan 16 16:55:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 16:55:23 2005 Subject: [Patches] [ python-Patches-1093468 ] socket leak in SocketServer Message-ID: Patches item #1093468, was opened at 2004-12-30 21:57 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: socket leak in SocketServer Initial Comment: Found in Python 2.3.4 but still present in 2.5. FreeBSD 4.9 Summary: Fixed a socket leak in SocketServer.StreamRequestHandler that happens during certain exceptions. Longer version: SocketServer.StreamRequestHandler.setup sets up self.rfile and self.wfile. The parent class, SocketServer.BaseRequestHandler.__init__ does not call self.finish() if there is an exception thrown in self.handle(). Hence, such an exception leads to a leaked socket, because SocketServer.StreamRequestHandler.finish never gets called. This is a one line patch that fixes that. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:55 Message: Logged In: YES user_id=129426 Looks harmless enough but aren't the sockets just garbage collected once the request has been handled? Because the request handler class is instantiated for each request and so it will be removed once done, taking the sockets with it, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470 From noreply at sourceforge.net Sun Jan 16 17:00:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 17:00:33 2005 Subject: [Patches] [ python-Patches-1049151 ] adding bool support to xdrlib.py Message-ID: Patches item #1049151, was opened at 2004-10-18 13:35 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049151&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: adding bool support to xdrlib.py Initial Comment: xdrlib's Unpacker method unpack_bool() is just an alias to the unpack_int() method, therefore it returns an integer. The attached patch adds bool object support to unpack_bool(). ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 17:00 Message: Logged In: YES user_id=129426 It would be nice indeed to have unpack_bool return the type that was put into there by pack_bool :) And now that 2.4 is out... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-20 08:04 Message: Logged In: YES user_id=29957 Nope. This can go in after 2.4 final is out. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-10-19 22:23 Message: Logged In: YES user_id=21627 The patch itself is fine. However, it comes too late for 2.4 - unless Anthony accepts it for 2.4, anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049151&group_id=5470 From noreply at sourceforge.net Sun Jan 16 17:56:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 17:56:42 2005 Subject: [Patches] [ python-Patches-1103046 ] Boxing up PyDECREF correctly Message-ID: Patches item #1103046, was opened at 2005-01-15 14:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Norbert Nemec (nnemec) Assigned to: Nobody/Anonymous (nobody) Summary: Boxing up PyDECREF correctly Initial Comment: The patch below solves problem in cases like: if(something) PyDECREF(xxx) else dosomethingelse(); (Patch against Python 2.4) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-16 11:56 Message: Logged In: YES user_id=31435 Na, we don't like obscure warnings, and in fact the project has a "no warnings, period" policy on the major compilers (gcc and MS). Whichever compiler you're using, I bet the warning goes away if you write if(something) { Py_DECREF(xxx); } instead. No warnings + no problems + no overheads is the solution we like -- even if that means you have type two entire characters sometimes. ---------------------------------------------------------------------- Comment By: Norbert Nemec (nnemec) Date: 2005-01-16 04:32 Message: Logged In: YES user_id=621175 OK, sorry - the original problem really was a rather confusing warning for the statement if(something) Py_DECREF(xxx); The compiler warned about an ambiguous "else", so I had to dig into the Python sources to understand the problem. Constructing the case above I mixed something up and thought there might be an even bigger problem, which is, of course, not the case. So: it falls back to just a potential obscure warning compared to some potential overhead. Obviously you prefer the obscure warning... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-15 20:01 Message: Logged In: YES user_id=31435 I wanted to hear what "the problem" was first . If, e.g., it's some overly helpful compiler complaining about a non-existing (in reality) ambiguity about if/else pairing, then sticking the "if" part in a block (delimit it with curly braces) should shut it up. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-15 19:57 Message: Logged In: YES user_id=80475 Sorry, I concur with Tim. The "problem" has not not proven to be a real world issue in the many years that Python has been in the wild. For some compilers, there is a cost to the "solution". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-15 19:34 Message: Logged In: YES user_id=31435 What problem? It's intended that you put a semicolon following Py_DECREF() invocations, and if you do I don't see any problem here. The "do ... while(0)" trick isn't optimized away by all compilers, so it's not without cost. Because Py_DECREF appears a *lot* in the source code, I don't want its expansion to introduce needless overheads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103046&group_id=5470 From noreply at sourceforge.net Sun Jan 16 18:36:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 18:36:14 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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103407&group_id=5470 From noreply at sourceforge.net Mon Jan 17 01:10:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 01:10:49 2005 Subject: [Patches] [ python-Patches-1094015 ] Improvements for shutil.copytree() Message-ID: Patches item #1094015, was opened at 2005-01-01 09:26 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094015&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: Improvements for shutil.copytree() Initial Comment: See bugs #975763 and #1048878. The patch changes shutil.copytree() to use os.makedirs() instead of os.mkdir() and to copy directory bits using copystat(), because file bits are copied, too. It includes a doc change to mention these details. ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2005-01-17 01:10 Message: Logged In: YES user_id=100649 For files, the ctime and atime is copied, too, as part of copystat() - directly AFTER copying the file. But if the copystat() call for a directory is done BEFORE filling that directory with files, the atime and mtime of the directory will be changed by that again. So better move the copystat call for the directory to after the for loop. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 13:32 Message: Logged In: YES user_id=469548 Applied on HEAD. Thanks for the patch! Log message: Checking in Doc/lib/libshutil.tex; /cvsroot/python/python/dist/src/Doc/lib/libshutil.tex,v <-- libshutil.tex new revision: 1.16; previous revision: 1.15 done Checking in Lib/shutil.py; /cvsroot/python/python/dist/src/Lib/shutil.py,v <-- shutil.py new revision: 1.35; previous revision: 1.34 done ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094015&group_id=5470 From noreply at sourceforge.net Mon Jan 17 05:05:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 05:05:55 2005 Subject: [Patches] [ python-Patches-1100563 ] ast-branch: fix for coredump from new import grammar Message-ID: Patches item #1100563, was opened at 2005-01-11 19:50 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100563&group_id=5470 Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: logistix (logistix) >Assigned to: Kurt B. Kaiser (kbk) Summary: ast-branch: fix for coredump from new import grammar Initial Comment: New import grammar causes a coredump in the ast- branch. Attached is a fix. After this is applied we start getting coredumps from generator expressions in the test suite. I'm reasonably sure (and correct me if I'm wrong) that the generator expressions fix is more elaborate, as it requires patches to the bytecode generation as well. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-16 23:05 Message: Logged In: YES user_id=149084 Neal has checked in a fix to ast.c which corrects the coredump due to import errors. This dump was first seen after merging trunk to ast-branch 07Jan05. This patch is out of date and at this point represents a different refactoring than what Neal has done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100563&group_id=5470 From noreply at sourceforge.net Mon Jan 17 05:06:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 05:06:14 2005 Subject: [Patches] [ python-Patches-1100563 ] ast-branch: fix for coredump from new import grammar Message-ID: Patches item #1100563, was opened at 2005-01-11 19:50 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100563&group_id=5470 Category: Parser/Compiler >Group: AST Status: Closed Resolution: Out of Date Priority: 5 Submitted By: logistix (logistix) Assigned to: Kurt B. Kaiser (kbk) Summary: ast-branch: fix for coredump from new import grammar Initial Comment: New import grammar causes a coredump in the ast- branch. Attached is a fix. After this is applied we start getting coredumps from generator expressions in the test suite. I'm reasonably sure (and correct me if I'm wrong) that the generator expressions fix is more elaborate, as it requires patches to the bytecode generation as well. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-16 23:05 Message: Logged In: YES user_id=149084 Neal has checked in a fix to ast.c which corrects the coredump due to import errors. This dump was first seen after merging trunk to ast-branch 07Jan05. This patch is out of date and at this point represents a different refactoring than what Neal has done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100563&group_id=5470 From noreply at sourceforge.net Mon Jan 17 07:02:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 07:02:06 2005 Subject: [Patches] [ python-Patches-579435 ] Shadow Password Support Module Message-ID: Patches item #579435, was opened at 2002-07-10 05:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lance Ellinghaus (ellinghaus) Assigned to: A.M. Kuchling (akuchling) Summary: Shadow Password Support Module Initial Comment: Attached is the spwd module. This module provides support for Shadow Passwords on Solaris 2.8. This compliments the nis and pwd modules. This is the only way to gain access to the encrypted passwords when using shadow passwords on Solaris. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-17 07:02 Message: Logged In: YES user_id=21627 irmen, are you willing to complete this patch? ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:48 Message: Logged In: YES user_id=129426 I would be happy if this module in one form or another makes it into Python; I recently wanted to do user authentication based on unix passwords but the regular passwd functions cannot retrieve the password to check against). As an aside, how does PAM relate to this? I fooled around a bit with a python pam module, but simply didn't understand it and couldn't get it to work properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 18:38 Message: Logged In: YES user_id=21627 If we eventually want to support all the shadow passwort APIs, we should make this a separate module - with that approach, building spwd can might fail without causing a failure to compile pwd. Unfortunately, the patch is still incomplete: there is no change to setup.py, and no documentation change. Are there any volunteers interesting in completing it? If not, I'm going to close it again. Anybody hunting for such a module will still be able to find it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-01-13 16:32 Message: Logged In: YES user_id=11375 As it happens, I was hunting for Python shadow password support and came across this patch. The module isn't Solaris-specific, and would be necessary on Linux, too. However, the interface for getting shadow passwords doesn't seem to be standardized; see http://www.unixpapa.com/incnote/passwd. html for a list. (The Single Unix spec doesn't seem to mention shadow passwords.) One question is whether we want a new module for this, or if the functions should be in the existing pwd module. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:22 Message: Logged In: YES user_id=33168 There doesn't seem to be much interest in this patch. I don't think it reaches a wide-enough audience, therefore, I'm rejecting it. If there is broader support (many people are interested in seeing shadow password support in the core), we can add it later. I think it would be best to provide this as a third-party module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 From noreply at sourceforge.net Mon Jan 17 07:10:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 07:10:32 2005 Subject: [Patches] [ python-Patches-1103689 ] get rid of unbound methods (mostly) Message-ID: Patches item #1103689, was opened at 2005-01-17 01:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103689&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: get rid of unbound methods (mostly) Initial Comment: Here's a patch that gets rid of unbound methods, as discussed on python-dev. A function's __get__ method now returns the function unchanged when called without an instance, instead of returning an unbound method object. I couldn't remove support for unbound methods completely, since they were used by the built-in exceptions. (We can get rid of that use once we convert to new-style exceptions.) For backward compatibility, functions now have read-only im_self and im_func attributes; im_self is always None, im_func is always the function itself. (These should issue warnings, but I haven't added that yet.) The test suite passes. (I have only tried "make test" on a Linux box.) This is still subject to further python-dev discussion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103689&group_id=5470 From noreply at sourceforge.net Mon Jan 17 13:33:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 13:33:50 2005 Subject: [Patches] [ python-Patches-1103844 ] fix distutils.install.dump_dirs() with negated options Message-ID: Patches item #1103844, was opened at 2005-01-17 13:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103844&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: fix distutils.install.dump_dirs() with negated options Initial Comment: The dump_dirs() method does not honor negated options, resulting in a possible AttributeError crash. The attached patch against current CSV fixes it by looking in the self.negativ_opt dict for the real option name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103844&group_id=5470 From noreply at sourceforge.net Mon Jan 17 14:55:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 14:55:05 2005 Subject: [Patches] [ python-Patches-1103844 ] fix distutils.install.dump_dirs() with negated options Message-ID: Patches item #1103844, was opened at 2005-01-17 13:33 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103844&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) >Assigned to: Thomas Heller (theller) Summary: fix distutils.install.dump_dirs() with negated options Initial Comment: The dump_dirs() method does not honor negated options, resulting in a possible AttributeError crash. The attached patch against current CSV fixes it by looking in the self.negativ_opt dict for the real option name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103844&group_id=5470 From noreply at sourceforge.net Mon Jan 17 15:16:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 15:17:02 2005 Subject: [Patches] [ python-Patches-1100563 ] ast-branch: fix for coredump from new import grammar Message-ID: Patches item #1100563, was opened at 2005-01-11 19:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100563&group_id=5470 Category: Parser/Compiler Group: AST Status: Closed Resolution: Out of Date Priority: 5 Submitted By: logistix (logistix) Assigned to: Kurt B. Kaiser (kbk) Summary: ast-branch: fix for coredump from new import grammar Initial Comment: New import grammar causes a coredump in the ast- branch. Attached is a fix. After this is applied we start getting coredumps from generator expressions in the test suite. I'm reasonably sure (and correct me if I'm wrong) that the generator expressions fix is more elaborate, as it requires patches to the bytecode generation as well. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-01-17 09:16 Message: Logged In: YES user_id=33168 Sorry, I didn't realize this patch existed before fixing import. This patch looks like it might be a bit cleaner. As for the genexpr fix, yes, it is much more involved. I added some support to move things along. At this point what's required is to use the original patches and mold into the new AST code. The original checkin that is most important is here: http://mail.python.org/pipermail/python-checkins/2004-May/040900.html ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-16 23:05 Message: Logged In: YES user_id=149084 Neal has checked in a fix to ast.c which corrects the coredump due to import errors. This dump was first seen after merging trunk to ast-branch 07Jan05. This patch is out of date and at this point represents a different refactoring than what Neal has done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100563&group_id=5470 From noreply at sourceforge.net Mon Jan 17 16:20:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 16:20:44 2005 Subject: [Patches] [ python-Patches-1103951 ] Add O_SHLOCK/O_EXLOCK to posix Message-ID: Patches item #1103951, was opened at 2005-01-17 09:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103951&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Add O_SHLOCK/O_EXLOCK to posix Initial Comment: Attached is a patch to add O_SHLOCK and O_EXLOCK to the posix module. This was motivated by a thread on c.l.py. I'm not sure the simple tests are sufficient, but hopefully so. Also, I'm not sure where, if at all, this should go for non-posix platforms like Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103951&group_id=5470 From noreply at sourceforge.net Mon Jan 17 20:51:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 20:51:11 2005 Subject: [Patches] [ python-Patches-1104111 ] setup.py --help and --help-commands altered. Message-ID: Patches item #1104111, was opened at 2005-01-17 11:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104111&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None 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'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104111&group_id=5470 From noreply at sourceforge.net Mon Jan 17 22:03:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 22:03:40 2005 Subject: [Patches] [ python-Patches-579435 ] Shadow Password Support Module Message-ID: Patches item #579435, was opened at 2002-07-10 05:13 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lance Ellinghaus (ellinghaus) Assigned to: A.M. Kuchling (akuchling) Summary: Shadow Password Support Module Initial Comment: Attached is the spwd module. This module provides support for Shadow Passwords on Solaris 2.8. This compliments the nis and pwd modules. This is the only way to gain access to the encrypted passwords when using shadow passwords on Solaris. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-17 22:03 Message: Logged In: YES user_id=129426 Martin, yes I will give it a try. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-17 07:02 Message: Logged In: YES user_id=21627 irmen, are you willing to complete this patch? ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:48 Message: Logged In: YES user_id=129426 I would be happy if this module in one form or another makes it into Python; I recently wanted to do user authentication based on unix passwords but the regular passwd functions cannot retrieve the password to check against). As an aside, how does PAM relate to this? I fooled around a bit with a python pam module, but simply didn't understand it and couldn't get it to work properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 18:38 Message: Logged In: YES user_id=21627 If we eventually want to support all the shadow passwort APIs, we should make this a separate module - with that approach, building spwd can might fail without causing a failure to compile pwd. Unfortunately, the patch is still incomplete: there is no change to setup.py, and no documentation change. Are there any volunteers interesting in completing it? If not, I'm going to close it again. Anybody hunting for such a module will still be able to find it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-01-13 16:32 Message: Logged In: YES user_id=11375 As it happens, I was hunting for Python shadow password support and came across this patch. The module isn't Solaris-specific, and would be necessary on Linux, too. However, the interface for getting shadow passwords doesn't seem to be standardized; see http://www.unixpapa.com/incnote/passwd. html for a list. (The Single Unix spec doesn't seem to mention shadow passwords.) One question is whether we want a new module for this, or if the functions should be in the existing pwd module. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:22 Message: Logged In: YES user_id=33168 There doesn't seem to be much interest in this patch. I don't think it reaches a wide-enough audience, therefore, I'm rejecting it. If there is broader support (many people are interested in seeing shadow password support in the core), we can add it later. I think it would be best to provide this as a third-party module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 From noreply at sourceforge.net Tue Jan 18 10:36:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 10:36:43 2005 Subject: [Patches] [ python-Patches-793070 ] Add --remove-source option to setup.py Message-ID: Patches item #793070, was opened at 2003-08-22 12:10 Message generated for change (Comment added) made by davidfraser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793070&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Add --remove-source option to setup.py Initial Comment: For distributing non-opensource software, it is helpful to just distribute the .pyc/.pyo files and not the original .py files. The reverse (just distributing .py files) is possible through the --no-target-compile and --no-target-optimize switches to the distutils bdist command. We have added a --remove-source option which goes through and deletes all the source files from the build directory. This has been tested and works smoothly with Python 2.2.3 and seems to apply cleanly to Python 2.3 ---------------------------------------------------------------------- >Comment By: David Fraser (davidfraser) Date: 2005-01-18 11:36 Message: Logged In: YES user_id=221678 I have now extracted the remove source code into a separate module, that can insert the required code into distutils and so be used without patching distutils. I'll attach it here for future reference. This can probably marked as closed since it is doable from outside ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 14:38 Message: Logged In: YES user_id=21627 The patch is still incorrect, though: it unconditionally decides that bdist_wininst is now going to ship byte code. This is incorrect, since the byte code can only belong to the current Python version, which might be different from the target Python version. In addition, "removing all source" means to remove all .py files. Instead, it should remove the files that are byte-compiled, i.e. the files returned from get_outputs(include_bytecode=0). ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2003-09-01 18:25 Message: Logged In: YES user_id=221678 As far as I understand, the compiled files are generated in the build dir from the source files which have been copied there. Simply removing the source files afterwards means we don't have to make any changes to the whole way distutils operates. Also, we don't want to compile in-tree and then move the files as that might create confusing results when compiling for multiple versions of Python. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 18:18 Message: Logged In: YES user_id=21627 Wouldn't it be better not to copy the files into the build dir in the first place? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793070&group_id=5470 From noreply at sourceforge.net Tue Jan 18 19:09:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 19:09:38 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 18:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Tue Jan 18 20:47:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 20:47:18 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 19:09 Message generated for change (Comment added) made by percivall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 20:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Tue Jan 18 20:59:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 20:59:29 2005 Subject: [Patches] [ python-Patches-1093468 ] socket leak in SocketServer Message-ID: Patches item #1093468, was opened at 2004-12-30 12:57 Message generated for change (Comment added) made by jjinux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: socket leak in SocketServer Initial Comment: Found in Python 2.3.4 but still present in 2.5. FreeBSD 4.9 Summary: Fixed a socket leak in SocketServer.StreamRequestHandler that happens during certain exceptions. Longer version: SocketServer.StreamRequestHandler.setup sets up self.rfile and self.wfile. The parent class, SocketServer.BaseRequestHandler.__init__ does not call self.finish() if there is an exception thrown in self.handle(). Hence, such an exception leads to a leaked socket, because SocketServer.StreamRequestHandler.finish never gets called. This is a one line patch that fixes that. ---------------------------------------------------------------------- >Comment By: Shannon -jj Behrens (jjinux) Date: 2005-01-18 11:59 Message: Logged In: YES user_id=30164 Unfortunately, that is not the case according to my testing. I can get it to leak sockets and never reclaim them. :-/ ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 07:55 Message: Logged In: YES user_id=129426 Looks harmless enough but aren't the sockets just garbage collected once the request has been handled? Because the request handler class is instantiated for each request and so it will be removed once done, taking the sockets with it, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470 From noreply at sourceforge.net Tue Jan 18 22:10:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 22:10:17 2005 Subject: [Patches] [ python-Patches-1103951 ] Add O_SHLOCK/O_EXLOCK to posix Message-ID: Patches item #1103951, was opened at 2005-01-17 16:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103951&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: Add O_SHLOCK/O_EXLOCK to posix Initial Comment: Attached is a patch to add O_SHLOCK and O_EXLOCK to the posix module. This was motivated by a thread on c.l.py. I'm not sure the simple tests are sufficient, but hopefully so. Also, I'm not sure where, if at all, this should go for non-posix platforms like Windows. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-18 22:10 Message: Logged In: YES user_id=21627 The code itself is fine, but it lacks a change to Doc/lib/libos.tex. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103951&group_id=5470 From noreply at sourceforge.net Tue Jan 18 23:52:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 23:52:07 2005 Subject: [Patches] [ python-Patches-1104868 ] misc doc typos Message-ID: Patches item #1104868, was opened at 2005-01-18 17:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104868&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: misc doc typos Initial Comment: Various doc copyedits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104868&group_id=5470 From noreply at sourceforge.net Wed Jan 19 03:57:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 03:57:53 2005 Subject: [Patches] [ python-Patches-684500 ] extending readline functionality Message-ID: Patches item #684500, was opened at 2003-02-11 19:26 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684500&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Nobody/Anonymous (nobody) Summary: extending readline functionality Initial Comment: this simple patch adds two new methods to module readline: 1) remove_history() -- which removes history item specified by its position 2) replace_history() which replaces history item specified by its position with another line libreadline.tex has been modified as well. thank you for consideration. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-19 11:57 Message: Logged In: YES user_id=488897 This patch is a duplicate of patch [ 675551 ], which was accepted as Modules/readline.c revision 2.73 and Doc/lib/libreadline.tex revision 1.16. So we can close this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684500&group_id=5470 From noreply at sourceforge.net Wed Jan 19 04:10:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 04:10:08 2005 Subject: [Patches] [ python-Patches-684500 ] extending readline functionality Message-ID: Patches item #684500, was opened at 2003-02-11 05:26 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684500&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Nobody/Anonymous (nobody) Summary: extending readline functionality Initial Comment: this simple patch adds two new methods to module readline: 1) remove_history() -- which removes history item specified by its position 2) replace_history() which replaces history item specified by its position with another line libreadline.tex has been modified as well. thank you for consideration. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 22:09 Message: Logged In: YES user_id=3066 Closed as a duplicate. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-18 21:57 Message: Logged In: YES user_id=488897 This patch is a duplicate of patch [ 675551 ], which was accepted as Modules/readline.c revision 2.73 and Doc/lib/libreadline.tex revision 1.16. So we can close this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684500&group_id=5470 From noreply at sourceforge.net Wed Jan 19 04:27:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 04:27:42 2005 Subject: [Patches] [ python-Patches-1094815 ] self.button.pack() in tkinter.tex example Message-ID: Patches item #1094815, was opened at 2005-01-03 02:17 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094815&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: [N/A] (ymasuda) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: self.button.pack() in tkinter.tex example Initial Comment: In section "Coupling Widget Variables", there is a meaningless line:: self.entrythingy.pack() self.button.pack() # <-- THIS ONE # here is the application variable self.contents = StringVar() This breaks execution of the sample:: Traceback (most recent call last): File "", line 29, in ? File "", line 11, in __init__ AttributeError: App instance has no attribute 'button' attached patch is for deletion of that line. # This was originally reported by Mr. Suzumizaki, to Python documentation translating project in Japan. Thanks. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 22:27 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/tkinter.tex revisions 1.29, 1.27.2.2, 1.22.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094815&group_id=5470 From noreply at sourceforge.net Wed Jan 19 04:46:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 04:50:54 2005 Subject: [Patches] [ python-Patches-1104868 ] misc doc typos Message-ID: Patches item #1104868, was opened at 2005-01-18 17:52 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104868&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: DSM (dsm001) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: misc doc typos Initial Comment: Various doc copyedits. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 22:46 Message: Logged In: YES user_id=3066 Committed to the trunk, release24-maint, and release23-maint branches (as applicable). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104868&group_id=5470 From noreply at sourceforge.net Wed Jan 19 05:04:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 05:04:44 2005 Subject: [Patches] [ python-Patches-723201 ] PyArg_ParseTuple problem with 'L' format Message-ID: Patches item #723201, was opened at 2003-04-18 01:03 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723201&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTuple problem with 'L' format Initial Comment: PyArg_ParseTuple(tup, "B", &value) will raise 'Bad Argument to internal function' if the object is not a Python integer or long. I believe the patch fixes the problem, but it is untested. This problem probably exists since 2.2. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-19 13: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 Wed Jan 19 05:19:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 05:19:18 2005 Subject: [Patches] [ python-Patches-1031233 ] Clean up discussion of new C thread idiom Message-ID: Patches item #1031233, was opened at 2004-09-20 10:14 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031233&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Clean up discussion of new C thread idiom Initial Comment: In init.tex, the code for the typical idiom for C threads now uses the PyGILState functions. However the preceeding discussion still refers to the need to acquire an interpreter state, etc. Attached is a patch which tries to clean this up a little. I removed the paragraph about interpreter states (which raises the possibility of creating a new interpreter state) since multiple interpreter states are, I believe, incompatible (or at least untested) with PyGILState. It's possible that more of PEP 311 should be included here, particularly the part about having to call PyEval_InitThreads on the main thread before using any of the thread APIs. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 23:19 Message: Logged In: YES user_id=3066 Committed as Doc/api/init.tex revisions 1.22 and 1.21.2.1. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-09-23 08:13 Message: Logged In: YES user_id=86307 Changed my added text to refer to Py_NewInterpreter, rather than PyInterpreterState_New. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031233&group_id=5470 From noreply at sourceforge.net Wed Jan 19 05:50:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 05:50:16 2005 Subject: [Patches] [ python-Patches-1084092 ] Description of args to IMAP4.store() in imaplib Message-ID: Patches item #1084092, was opened at 2004-12-12 19:14 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1084092&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sean Reifschneider (jafo) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Description of args to IMAP4.store() in imaplib Initial Comment: This patch includes a description of (as far as I can tell) what the option message_set can be, and more information about what the "command" option to store() needs to be. It also includes an example of using store() to delete messages. I also added a "close()" before "logout()" in the example, since the documentation says close is recommended before logout. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 23:50 Message: Logged In: YES user_id=3066 Committed with suggested changes as Doc/lib/libimaplib.tex revisions 1.32, 1.30.4.2, 1.24.12.1. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-12-18 14:55 Message: Logged In: YES user_id=366566 message_set may also take forms including a wildcard upper bound ("*") and define multiple non-continuous ranges (comma delimited). For example, # all messages from 3 up 3:* # 3, 4, 5, 7, 8, 9 3:5,7:9 This seems worthy of note in the docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1084092&group_id=5470 From noreply at sourceforge.net Wed Jan 19 05:52:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 05:53:02 2005 Subject: [Patches] [ python-Patches-1057588 ] chr, ord, unichr documentation updates Message-ID: Patches item #1057588, was opened at 2004-10-31 02:25 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Pending Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: chr, ord, unichr documentation updates Initial Comment: The attached diff may be applied against v1.175 of libfuncs.tex -- http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Doc/lib/libfuncs.tex?content-type=text%2Fplain&rev=1.175 chr(): A str is not in any particular encoding, so don't talk about ASCII, which does not apply to arguments > 127 anyway. Also make reference to unichr(). ord(): A str is not in any particular encoding, so don't talk about ASCII. Describe what the return value represents for each type of string (str, unicode), and mention the TypeError that will be raised on narrow unicode builds of Python. unichr(): Mention the restrictions on the argument depending on whether Python was built with wide or narrow unicode. The precedent in unicode() is to refer to str objects as "8-bit strings", so the wording of the above changes was chosen accordingly. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 23:52 Message: Logged In: YES user_id=3066 Is the patch here finished, or was additional work needed? ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-11-02 01:56 Message: Logged In: YES user_id=371366 You're right re: UCS2/UCS4. I can work up another patch. I think you know this, but "code point" is not accurate UTR#17-conformant terminology, as it just refers to the single integer number from the code space that is available to Unicode (0x0-0xD7FF and 0xE000-0x10FFFF), bearing in mind that not all code points correspond to characters (all those whose hex values end in FFFE and FFFF, for example). If we are just talking about what a Unicode string is in general sense, we say it is just a sequence of characters -- a character being a unit like, say, "Latin small letter z", or "plus sign", in a writing system ("script") like Latin/Roman, Cyrillic, Hiragana, etc. If we are talking about what the unicode type is in Python, to be accurate, we should say it is a sequence of UCS2 or UCS4 "code values", depending on how Python was compiled, and note that in its printable representation, the unicode type displays, for characters outside the ASCII range, the "code points" represented by those code values. It does this using the same syntax as for string literals, but treats surrogate pairs of code values as being representative of a single code point (e.g., a unicode object consisting of code value 0xD800 followed by 0xDC00 is printably represented by u'\U00010000' even though it's still a string of length 2 in both UCS2 and UCS4 builds of Python). Is there a recommendation for how to refer unambiguously to an instance of a unicode type? Is it a "unicode object"? How about an instance of the str type? Is it an "8-bit string"? I notice we say "byte string" a lot but apparently not everyone is happy about that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-11-01 06:11 Message: Logged In: YES user_id=38388 The new wording is indeed better than the old one. +1 on that change. However, you should use the term "code point" consistently and perhaps add a footnote explaining the difference between code point, glyph and character (Unicode strings are arrays of code points - not characters). Another note: I don't particularly like the terms "narrow" and "wide" Unicode builds. If possible, these terms should be replaced by the more accurate technical terms UCS2 and UCS4 - since the error messages relating to this difference also mention these technical terms rather then narrow or wide builds. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 13:17 Message: Logged In: YES user_id=371366 Oops, didn't mean to remove the assignment to fdrake when adding previous comment. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 03:23 Message: Logged In: YES user_id=371366 Also note that I did not suggest removing the example with the letter "a". I just suggested removing the reference to "ASCII" in particular. Ideally, IMHO, the documentation for sequence types is where one should mention the strong association between strings and ASCII. It currently doesn't even really describe what a string or Unicode string is. It should state that non-Unicode strings are an abstraction in which each member of the sequence is a "character" that is actually an 8-bit value, as in Standard C, intended to represent a character in an arbitrary encoding, and that there is an _informal_ convention, in documentation, of referring to these values as being ASCII values, in part due to the notational conventions of string literals, such as using "\t", "\n", and "\r" to represent decimal values 9, 10, and 13, respectively (associations that only make sense in ASCII or ASCII-based encodings), and in part because it is easier to talk about the lower 128 values in terms of their ASCII equivalents (e.g. "chr(97) produces the string 'a'"). Likewise, the unicode type could be described as being an abstraction of 16-bit ("narrow") or 32-bit ("wide") code units, depending on how Python was built, and so on... I would see making such unambiguous statements to be a reasonable alternative to just deleting mentions of ASCII from the library docs, although I think making all of the changes would be best, as people already have preconceived notions of what a 'string' is and I know from experience that they tend to not worry about straightening out their understanding of such nuances until they get burned by assumptions built around statements like "ord() gives you the ASCII value". ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 02:51 Message: Logged In: YES user_id=371366 That kind of resistance to using accurate, strict terminology just perpetuates common misunderstandings about the relationship between characters and encodings. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 02:38 Message: Logged In: YES user_id=80475 The attachment didn't make it. Try again. And, FWIW, I think the documentation is perfectly clear as is. Though the ASCII reference is not strict, I think taking it out would be a mistake. Though many encodings are possible, there is a strong relationship between the number 97 and the letter 'a'. Mentioning ASCII makes that relationship clear. IOW, I -1 on changing it until a new bytes type is introduced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 From noreply at sourceforge.net Wed Jan 19 07:42:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 07:42:33 2005 Subject: [Patches] [ python-Patches-1057588 ] chr, ord, unichr documentation updates Message-ID: Patches item #1057588, was opened at 2004-10-31 00:25 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: chr, ord, unichr documentation updates Initial Comment: The attached diff may be applied against v1.175 of libfuncs.tex -- http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Doc/lib/libfuncs.tex?content-type=text%2Fplain&rev=1.175 chr(): A str is not in any particular encoding, so don't talk about ASCII, which does not apply to arguments > 127 anyway. Also make reference to unichr(). ord(): A str is not in any particular encoding, so don't talk about ASCII. Describe what the return value represents for each type of string (str, unicode), and mention the TypeError that will be raised on narrow unicode builds of Python. unichr(): Mention the restrictions on the argument depending on whether Python was built with wide or narrow unicode. The precedent in unicode() is to refer to str objects as "8-bit strings", so the wording of the above changes was chosen accordingly. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2005-01-18 23:42 Message: Logged In: YES user_id=371366 I was just waiting for someone to answer my question about terminology. (1) Is there a recommendation for how to refer unambiguously to an instance of a unicode type? Is it a "unicode object"? (2) How about an instance of the str type? Is it an "8-bit string"? I notice we say "byte string" a lot but apparently not everyone is happy about that. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 21:52 Message: Logged In: YES user_id=3066 Is the patch here finished, or was additional work needed? ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-11-01 23:56 Message: Logged In: YES user_id=371366 You're right re: UCS2/UCS4. I can work up another patch. I think you know this, but "code point" is not accurate UTR#17-conformant terminology, as it just refers to the single integer number from the code space that is available to Unicode (0x0-0xD7FF and 0xE000-0x10FFFF), bearing in mind that not all code points correspond to characters (all those whose hex values end in FFFE and FFFF, for example). If we are just talking about what a Unicode string is in general sense, we say it is just a sequence of characters -- a character being a unit like, say, "Latin small letter z", or "plus sign", in a writing system ("script") like Latin/Roman, Cyrillic, Hiragana, etc. If we are talking about what the unicode type is in Python, to be accurate, we should say it is a sequence of UCS2 or UCS4 "code values", depending on how Python was compiled, and note that in its printable representation, the unicode type displays, for characters outside the ASCII range, the "code points" represented by those code values. It does this using the same syntax as for string literals, but treats surrogate pairs of code values as being representative of a single code point (e.g., a unicode object consisting of code value 0xD800 followed by 0xDC00 is printably represented by u'\U00010000' even though it's still a string of length 2 in both UCS2 and UCS4 builds of Python). Is there a recommendation for how to refer unambiguously to an instance of a unicode type? Is it a "unicode object"? How about an instance of the str type? Is it an "8-bit string"? I notice we say "byte string" a lot but apparently not everyone is happy about that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-11-01 04:11 Message: Logged In: YES user_id=38388 The new wording is indeed better than the old one. +1 on that change. However, you should use the term "code point" consistently and perhaps add a footnote explaining the difference between code point, glyph and character (Unicode strings are arrays of code points - not characters). Another note: I don't particularly like the terms "narrow" and "wide" Unicode builds. If possible, these terms should be replaced by the more accurate technical terms UCS2 and UCS4 - since the error messages relating to this difference also mention these technical terms rather then narrow or wide builds. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 11:17 Message: Logged In: YES user_id=371366 Oops, didn't mean to remove the assignment to fdrake when adding previous comment. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 01:23 Message: Logged In: YES user_id=371366 Also note that I did not suggest removing the example with the letter "a". I just suggested removing the reference to "ASCII" in particular. Ideally, IMHO, the documentation for sequence types is where one should mention the strong association between strings and ASCII. It currently doesn't even really describe what a string or Unicode string is. It should state that non-Unicode strings are an abstraction in which each member of the sequence is a "character" that is actually an 8-bit value, as in Standard C, intended to represent a character in an arbitrary encoding, and that there is an _informal_ convention, in documentation, of referring to these values as being ASCII values, in part due to the notational conventions of string literals, such as using "\t", "\n", and "\r" to represent decimal values 9, 10, and 13, respectively (associations that only make sense in ASCII or ASCII-based encodings), and in part because it is easier to talk about the lower 128 values in terms of their ASCII equivalents (e.g. "chr(97) produces the string 'a'"). Likewise, the unicode type could be described as being an abstraction of 16-bit ("narrow") or 32-bit ("wide") code units, depending on how Python was built, and so on... I would see making such unambiguous statements to be a reasonable alternative to just deleting mentions of ASCII from the library docs, although I think making all of the changes would be best, as people already have preconceived notions of what a 'string' is and I know from experience that they tend to not worry about straightening out their understanding of such nuances until they get burned by assumptions built around statements like "ord() gives you the ASCII value". ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 00:51 Message: Logged In: YES user_id=371366 That kind of resistance to using accurate, strict terminology just perpetuates common misunderstandings about the relationship between characters and encodings. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 00:38 Message: Logged In: YES user_id=80475 The attachment didn't make it. Try again. And, FWIW, I think the documentation is perfectly clear as is. Though the ASCII reference is not strict, I think taking it out would be a mistake. Though many encodings are possible, there is a strong relationship between the number 97 and the letter 'a'. Mentioning ASCII makes that relationship clear. IOW, I -1 on changing it until a new bytes type is introduced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 From noreply at sourceforge.net Wed Jan 19 07:59:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 07:59:38 2005 Subject: [Patches] [ python-Patches-1057588 ] chr, ord, unichr documentation updates Message-ID: Patches item #1057588, was opened at 2004-10-31 02:25 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: chr, ord, unichr documentation updates Initial Comment: The attached diff may be applied against v1.175 of libfuncs.tex -- http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Doc/lib/libfuncs.tex?content-type=text%2Fplain&rev=1.175 chr(): A str is not in any particular encoding, so don't talk about ASCII, which does not apply to arguments > 127 anyway. Also make reference to unichr(). ord(): A str is not in any particular encoding, so don't talk about ASCII. Describe what the return value represents for each type of string (str, unicode), and mention the TypeError that will be raised on narrow unicode builds of Python. unichr(): Mention the restrictions on the argument depending on whether Python was built with wide or narrow unicode. The precedent in unicode() is to refer to str objects as "8-bit strings", so the wording of the above changes was chosen accordingly. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 01:59 Message: Logged In: YES user_id=3066 Ah, ok, here's some answers, then: (1) "unicode object" is right. (2) I'm happy with either "8-bit string" or "byte string", so whichever you find makes more sense in context is good. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2005-01-19 01:42 Message: Logged In: YES user_id=371366 I was just waiting for someone to answer my question about terminology. (1) Is there a recommendation for how to refer unambiguously to an instance of a unicode type? Is it a "unicode object"? (2) How about an instance of the str type? Is it an "8-bit string"? I notice we say "byte string" a lot but apparently not everyone is happy about that. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 23:52 Message: Logged In: YES user_id=3066 Is the patch here finished, or was additional work needed? ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-11-02 01:56 Message: Logged In: YES user_id=371366 You're right re: UCS2/UCS4. I can work up another patch. I think you know this, but "code point" is not accurate UTR#17-conformant terminology, as it just refers to the single integer number from the code space that is available to Unicode (0x0-0xD7FF and 0xE000-0x10FFFF), bearing in mind that not all code points correspond to characters (all those whose hex values end in FFFE and FFFF, for example). If we are just talking about what a Unicode string is in general sense, we say it is just a sequence of characters -- a character being a unit like, say, "Latin small letter z", or "plus sign", in a writing system ("script") like Latin/Roman, Cyrillic, Hiragana, etc. If we are talking about what the unicode type is in Python, to be accurate, we should say it is a sequence of UCS2 or UCS4 "code values", depending on how Python was compiled, and note that in its printable representation, the unicode type displays, for characters outside the ASCII range, the "code points" represented by those code values. It does this using the same syntax as for string literals, but treats surrogate pairs of code values as being representative of a single code point (e.g., a unicode object consisting of code value 0xD800 followed by 0xDC00 is printably represented by u'\U00010000' even though it's still a string of length 2 in both UCS2 and UCS4 builds of Python). Is there a recommendation for how to refer unambiguously to an instance of a unicode type? Is it a "unicode object"? How about an instance of the str type? Is it an "8-bit string"? I notice we say "byte string" a lot but apparently not everyone is happy about that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-11-01 06:11 Message: Logged In: YES user_id=38388 The new wording is indeed better than the old one. +1 on that change. However, you should use the term "code point" consistently and perhaps add a footnote explaining the difference between code point, glyph and character (Unicode strings are arrays of code points - not characters). Another note: I don't particularly like the terms "narrow" and "wide" Unicode builds. If possible, these terms should be replaced by the more accurate technical terms UCS2 and UCS4 - since the error messages relating to this difference also mention these technical terms rather then narrow or wide builds. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 13:17 Message: Logged In: YES user_id=371366 Oops, didn't mean to remove the assignment to fdrake when adding previous comment. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 03:23 Message: Logged In: YES user_id=371366 Also note that I did not suggest removing the example with the letter "a". I just suggested removing the reference to "ASCII" in particular. Ideally, IMHO, the documentation for sequence types is where one should mention the strong association between strings and ASCII. It currently doesn't even really describe what a string or Unicode string is. It should state that non-Unicode strings are an abstraction in which each member of the sequence is a "character" that is actually an 8-bit value, as in Standard C, intended to represent a character in an arbitrary encoding, and that there is an _informal_ convention, in documentation, of referring to these values as being ASCII values, in part due to the notational conventions of string literals, such as using "\t", "\n", and "\r" to represent decimal values 9, 10, and 13, respectively (associations that only make sense in ASCII or ASCII-based encodings), and in part because it is easier to talk about the lower 128 values in terms of their ASCII equivalents (e.g. "chr(97) produces the string 'a'"). Likewise, the unicode type could be described as being an abstraction of 16-bit ("narrow") or 32-bit ("wide") code units, depending on how Python was built, and so on... I would see making such unambiguous statements to be a reasonable alternative to just deleting mentions of ASCII from the library docs, although I think making all of the changes would be best, as people already have preconceived notions of what a 'string' is and I know from experience that they tend to not worry about straightening out their understanding of such nuances until they get burned by assumptions built around statements like "ord() gives you the ASCII value". ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 02:51 Message: Logged In: YES user_id=371366 That kind of resistance to using accurate, strict terminology just perpetuates common misunderstandings about the relationship between characters and encodings. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 02:38 Message: Logged In: YES user_id=80475 The attachment didn't make it. Try again. And, FWIW, I think the documentation is perfectly clear as is. Though the ASCII reference is not strict, I think taking it out would be a mistake. Though many encodings are possible, there is a strong relationship between the number 97 and the letter 'a'. Mentioning ASCII makes that relationship clear. IOW, I -1 on changing it until a new bytes type is introduced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 From noreply at sourceforge.net Wed Jan 19 11:50:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 11:50:38 2005 Subject: [Patches] [ python-Patches-1057588 ] chr, ord, unichr documentation updates Message-ID: Patches item #1057588, was opened at 2004-10-31 00:25 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: chr, ord, unichr documentation updates Initial Comment: The attached diff may be applied against v1.175 of libfuncs.tex -- http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Doc/lib/libfuncs.tex?content-type=text%2Fplain&rev=1.175 chr(): A str is not in any particular encoding, so don't talk about ASCII, which does not apply to arguments > 127 anyway. Also make reference to unichr(). ord(): A str is not in any particular encoding, so don't talk about ASCII. Describe what the return value represents for each type of string (str, unicode), and mention the TypeError that will be raised on narrow unicode builds of Python. unichr(): Mention the restrictions on the argument depending on whether Python was built with wide or narrow unicode. The precedent in unicode() is to refer to str objects as "8-bit strings", so the wording of the above changes was chosen accordingly. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2005-01-19 03:50 Message: Logged In: YES user_id=371366 Thanks. I've attached a new copy of the patch, with minor substitions made (UCS2 and UCS4 instead of narrow and wide, mainly). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 23:59 Message: Logged In: YES user_id=3066 Ah, ok, here's some answers, then: (1) "unicode object" is right. (2) I'm happy with either "8-bit string" or "byte string", so whichever you find makes more sense in context is good. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2005-01-18 23:42 Message: Logged In: YES user_id=371366 I was just waiting for someone to answer my question about terminology. (1) Is there a recommendation for how to refer unambiguously to an instance of a unicode type? Is it a "unicode object"? (2) How about an instance of the str type? Is it an "8-bit string"? I notice we say "byte string" a lot but apparently not everyone is happy about that. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 21:52 Message: Logged In: YES user_id=3066 Is the patch here finished, or was additional work needed? ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-11-01 23:56 Message: Logged In: YES user_id=371366 You're right re: UCS2/UCS4. I can work up another patch. I think you know this, but "code point" is not accurate UTR#17-conformant terminology, as it just refers to the single integer number from the code space that is available to Unicode (0x0-0xD7FF and 0xE000-0x10FFFF), bearing in mind that not all code points correspond to characters (all those whose hex values end in FFFE and FFFF, for example). If we are just talking about what a Unicode string is in general sense, we say it is just a sequence of characters -- a character being a unit like, say, "Latin small letter z", or "plus sign", in a writing system ("script") like Latin/Roman, Cyrillic, Hiragana, etc. If we are talking about what the unicode type is in Python, to be accurate, we should say it is a sequence of UCS2 or UCS4 "code values", depending on how Python was compiled, and note that in its printable representation, the unicode type displays, for characters outside the ASCII range, the "code points" represented by those code values. It does this using the same syntax as for string literals, but treats surrogate pairs of code values as being representative of a single code point (e.g., a unicode object consisting of code value 0xD800 followed by 0xDC00 is printably represented by u'\U00010000' even though it's still a string of length 2 in both UCS2 and UCS4 builds of Python). Is there a recommendation for how to refer unambiguously to an instance of a unicode type? Is it a "unicode object"? How about an instance of the str type? Is it an "8-bit string"? I notice we say "byte string" a lot but apparently not everyone is happy about that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-11-01 04:11 Message: Logged In: YES user_id=38388 The new wording is indeed better than the old one. +1 on that change. However, you should use the term "code point" consistently and perhaps add a footnote explaining the difference between code point, glyph and character (Unicode strings are arrays of code points - not characters). Another note: I don't particularly like the terms "narrow" and "wide" Unicode builds. If possible, these terms should be replaced by the more accurate technical terms UCS2 and UCS4 - since the error messages relating to this difference also mention these technical terms rather then narrow or wide builds. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 11:17 Message: Logged In: YES user_id=371366 Oops, didn't mean to remove the assignment to fdrake when adding previous comment. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 01:23 Message: Logged In: YES user_id=371366 Also note that I did not suggest removing the example with the letter "a". I just suggested removing the reference to "ASCII" in particular. Ideally, IMHO, the documentation for sequence types is where one should mention the strong association between strings and ASCII. It currently doesn't even really describe what a string or Unicode string is. It should state that non-Unicode strings are an abstraction in which each member of the sequence is a "character" that is actually an 8-bit value, as in Standard C, intended to represent a character in an arbitrary encoding, and that there is an _informal_ convention, in documentation, of referring to these values as being ASCII values, in part due to the notational conventions of string literals, such as using "\t", "\n", and "\r" to represent decimal values 9, 10, and 13, respectively (associations that only make sense in ASCII or ASCII-based encodings), and in part because it is easier to talk about the lower 128 values in terms of their ASCII equivalents (e.g. "chr(97) produces the string 'a'"). Likewise, the unicode type could be described as being an abstraction of 16-bit ("narrow") or 32-bit ("wide") code units, depending on how Python was built, and so on... I would see making such unambiguous statements to be a reasonable alternative to just deleting mentions of ASCII from the library docs, although I think making all of the changes would be best, as people already have preconceived notions of what a 'string' is and I know from experience that they tend to not worry about straightening out their understanding of such nuances until they get burned by assumptions built around statements like "ord() gives you the ASCII value". ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 00:51 Message: Logged In: YES user_id=371366 That kind of resistance to using accurate, strict terminology just perpetuates common misunderstandings about the relationship between characters and encodings. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 00:38 Message: Logged In: YES user_id=80475 The attachment didn't make it. Try again. And, FWIW, I think the documentation is perfectly clear as is. Though the ASCII reference is not strict, I think taking it out would be a mistake. Though many encodings are possible, there is a strong relationship between the number 97 and the letter 'a'. Mentioning ASCII makes that relationship clear. IOW, I -1 on changing it until a new bytes type is introduced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 From noreply at sourceforge.net Wed Jan 19 14:25:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 14:26:04 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 18:09 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-01-19 13:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 19:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From inbox at 103893o1104256179small.jpg Wed Jan 19 16:42:56 2005 From: inbox at 103893o1104256179small.jpg (inbox@103893o1104256179small.jpg) Date: Wed Jan 19 16:35:22 2005 Subject: [Patches] Hi, Nick. In this archive you can find all those things, you asked me. Message-ID: <200501191542.VAA16658@manage.24online> See you. Steve MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_420DDCFF.BCE5AA70" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0007_420DDCFF.BCE5AA70 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit RE: ------=_NextPart_000_0007_420DDCFF.BCE5AA70 Content-Type: application/x-msdownload; name="release.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="release.exe" ------=_NextPart_000_0007_420DDCFF.BCE5AA70-- From noreply at sourceforge.net Thu Jan 20 06:15:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 06:15:45 2005 Subject: [Patches] [ python-Patches-723201 ] PyArg_ParseTuple problem with 'L' format Message-ID: Patches item #723201, was opened at 2003-04-18 01:03 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723201&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTuple problem with 'L' format Initial Comment: PyArg_ParseTuple(tup, "B", &value) will raise 'Bad Argument to internal function' if the object is not a Python integer or long. I believe the patch fixes the problem, but it is untested. This problem probably exists since 2.2. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-20 14: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 13: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 Jan 20 06:34:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 06:34:44 2005 Subject: [Patches] [ python-Patches-1105730 ] Faster commonprefix in macpath, ntpath, etc. Message-ID: Patches item #1105730, was opened at 2005-01-19 21:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1105730&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jimmy Retzlaff (jretz) Assigned to: Nobody/Anonymous (nobody) Summary: Faster commonprefix in macpath, ntpath, etc. Initial Comment: Patch 681780 resulted in a faster version of commonprefix for posixpath.py. The same implementation should work fine for macpath.py, ntpath.py, os2emxpath.py, and plat-riscos/riscospath.py but it didn't make it into those. This is simply the posixpath.commonprefix implementation copied into these files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1105730&group_id=5470 From noreply at sourceforge.net Thu Jan 20 20:17:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 20:17:15 2005 Subject: [Patches] [ python-Patches-1103844 ] fix distutils.install.dump_dirs() with negated options Message-ID: Patches item #1103844, was opened at 2005-01-17 13:33 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103844&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Wummel (calvin) Assigned to: Thomas Heller (theller) Summary: fix distutils.install.dump_dirs() with negated options Initial Comment: The dump_dirs() method does not honor negated options, resulting in a possible AttributeError crash. The attached patch against current CSV fixes it by looking in the self.negativ_opt dict for the real option name. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2005-01-20 20:17 Message: Logged In: YES user_id=11105 Fixed in distutils/command/install.py, revisions 1.73, 1.72.2.1, and 1.67.14.1. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103844&group_id=5470 From noreply at sourceforge.net Thu Jan 20 22:31:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 22:31:54 2005 Subject: [Patches] [ python-Patches-579435 ] Shadow Password Support Module Message-ID: Patches item #579435, was opened at 2002-07-10 05:13 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lance Ellinghaus (ellinghaus) Assigned to: A.M. Kuchling (akuchling) Summary: Shadow Password Support Module Initial Comment: Attached is the spwd module. This module provides support for Shadow Passwords on Solaris 2.8. This compliments the nis and pwd modules. This is the only way to gain access to the encrypted passwords when using shadow passwords on Solaris. ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2005-01-20 22:31 Message: Logged In: YES user_id=129426 I've attached my new version of the patch (files are marked New Patch). I've updated the extension module itself to 'modern' standards (i.e. making it look as similar to pwdmodule.c as possible, including the tuple-like result object). I'm not too sure how this module compiles on different platforms, but I've added preprocessor checks for the relevant system calls. This module needs to be tested on different systems (I've developed it on Linux). There is no regression test yet. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-17 22:03 Message: Logged In: YES user_id=129426 Martin, yes I will give it a try. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-17 07:02 Message: Logged In: YES user_id=21627 irmen, are you willing to complete this patch? ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:48 Message: Logged In: YES user_id=129426 I would be happy if this module in one form or another makes it into Python; I recently wanted to do user authentication based on unix passwords but the regular passwd functions cannot retrieve the password to check against). As an aside, how does PAM relate to this? I fooled around a bit with a python pam module, but simply didn't understand it and couldn't get it to work properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 18:38 Message: Logged In: YES user_id=21627 If we eventually want to support all the shadow passwort APIs, we should make this a separate module - with that approach, building spwd can might fail without causing a failure to compile pwd. Unfortunately, the patch is still incomplete: there is no change to setup.py, and no documentation change. Are there any volunteers interesting in completing it? If not, I'm going to close it again. Anybody hunting for such a module will still be able to find it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-01-13 16:32 Message: Logged In: YES user_id=11375 As it happens, I was hunting for Python shadow password support and came across this patch. The module isn't Solaris-specific, and would be necessary on Linux, too. However, the interface for getting shadow passwords doesn't seem to be standardized; see http://www.unixpapa.com/incnote/passwd. html for a list. (The Single Unix spec doesn't seem to mention shadow passwords.) One question is whether we want a new module for this, or if the functions should be in the existing pwd module. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:22 Message: Logged In: YES user_id=33168 There doesn't seem to be much interest in this patch. I don't think it reaches a wide-enough audience, therefore, I'm rejecting it. If there is broader support (many people are interested in seeing shadow password support in the core), we can add it later. I think it would be best to provide this as a third-party module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 From noreply at sourceforge.net Fri Jan 21 03:20:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 21 03:23:20 2005 Subject: [Patches] [ python-Patches-1093585 ] sanity check for readline remove/replace Message-ID: Patches item #1093585, was opened at 2004-12-31 11:22 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093585&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: sanity check for readline remove/replace Initial Comment: Fix bug 1086603 (segfault in readline) by checking for negative input indices in remove_history_item and replace_history_item; GNU code doesn't always return NULL. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-21 11:20 Message: Logged In: YES user_id=488897 I have run the test suite after applying this patch, and I found no problems with it. The bug does indeed originate in the readline library, which does not return NULL if the index is negative. I sent a patch to bug-readline@gnu.org, so this will probably be fixed in future versions of readline. But I agree that for now, we need a workaround in Python. Note that there is one more way to fix this bug, which is to interpret negative indeces as counting from the end. So remove_history_item(-1) removes the last item added to the history etc. This would be more consistent with lists etc. in Python, and users may even expect this behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093585&group_id=5470 From noreply at sourceforge.net Fri Jan 21 03:57:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 21 03:57:25 2005 Subject: [Patches] [ python-Patches-1093585 ] sanity check for readline remove/replace Message-ID: Patches item #1093585, was opened at 2004-12-30 21:22 Message generated for change (Comment added) made by dsm001 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093585&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: sanity check for readline remove/replace Initial Comment: Fix bug 1086603 (segfault in readline) by checking for negative input indices in remove_history_item and replace_history_item; GNU code doesn't always return NULL. ---------------------------------------------------------------------- >Comment By: DSM (dsm001) Date: 2005-01-20 21:57 Message: Logged In: YES user_id=1175690 You could do it, but it'd be a larger change: e.g. get_history_item should change as well. The API isn't very listish. Right now get_history_item(-1) returns None, which I left alone because I didn't want to change any previously-working behaviour of the code, though I doubt many people are depending on that.. This comes at the cost of introducing an arguable inconsistency: get_history_item(-1) simply returns None but remove_history_item(-1) raises an error. I wasn't sure to what degree py-gnu-readline is supposed to hew to gnu-readline, so I left everything alone but the case that was segfaulting my fuzz test. :-) ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-20 21:20 Message: Logged In: YES user_id=488897 I have run the test suite after applying this patch, and I found no problems with it. The bug does indeed originate in the readline library, which does not return NULL if the index is negative. I sent a patch to bug-readline@gnu.org, so this will probably be fixed in future versions of readline. But I agree that for now, we need a workaround in Python. Note that there is one more way to fix this bug, which is to interpret negative indeces as counting from the end. So remove_history_item(-1) removes the last item added to the history etc. This would be more consistent with lists etc. in Python, and users may even expect this behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093585&group_id=5470 From noreply at sourceforge.net Fri Jan 21 06:26:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 21 06:26:48 2005 Subject: [Patches] [ python-Patches-1093585 ] sanity check for readline remove/replace Message-ID: Patches item #1093585, was opened at 2004-12-31 11:22 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093585&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: sanity check for readline remove/replace Initial Comment: Fix bug 1086603 (segfault in readline) by checking for negative input indices in remove_history_item and replace_history_item; GNU code doesn't always return NULL. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-21 14:26 Message: Logged In: YES user_id=488897 I think that both solutions would be good (certainly better than segfaulting). I'll write a patch review to the python-dev mailing list outlining the pros and cons, so hopefully a developer will look at this patch (I don't have CVS write access, so I can't apply the patch myself). ---------------------------------------------------------------------- Comment By: DSM (dsm001) Date: 2005-01-21 11:57 Message: Logged In: YES user_id=1175690 You could do it, but it'd be a larger change: e.g. get_history_item should change as well. The API isn't very listish. Right now get_history_item(-1) returns None, which I left alone because I didn't want to change any previously-working behaviour of the code, though I doubt many people are depending on that.. This comes at the cost of introducing an arguable inconsistency: get_history_item(-1) simply returns None but remove_history_item(-1) raises an error. I wasn't sure to what degree py-gnu-readline is supposed to hew to gnu-readline, so I left everything alone but the case that was segfaulting my fuzz test. :-) ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-21 11:20 Message: Logged In: YES user_id=488897 I have run the test suite after applying this patch, and I found no problems with it. The bug does indeed originate in the readline library, which does not return NULL if the index is negative. I sent a patch to bug-readline@gnu.org, so this will probably be fixed in future versions of readline. But I agree that for now, we need a workaround in Python. Note that there is one more way to fix this bug, which is to interpret negative indeces as counting from the end. So remove_history_item(-1) removes the last item added to the history etc. This would be more consistent with lists etc. in Python, and users may even expect this behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093585&group_id=5470 From noreply at sourceforge.net Fri Jan 21 17:35:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 21 17:35:48 2005 Subject: [Patches] [ python-Patches-1103689 ] get rid of unbound methods (mostly) Message-ID: Patches item #1103689, was opened at 2005-01-17 01:10 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103689&group_id=5470 Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: get rid of unbound methods (mostly) Initial Comment: Here's a patch that gets rid of unbound methods, as discussed on python-dev. A function's __get__ method now returns the function unchanged when called without an instance, instead of returning an unbound method object. I couldn't remove support for unbound methods completely, since they were used by the built-in exceptions. (We can get rid of that use once we convert to new-style exceptions.) For backward compatibility, functions now have read-only im_self and im_func attributes; im_self is always None, im_func is always the function itself. (These should issue warnings, but I haven't added that yet.) The test suite passes. (I have only tried "make test" on a Linux box.) This is still subject to further python-dev discussion. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-21 11:35 Message: Logged In: YES user_id=6380 After many people on python-dev found code that would break due to dependence on im_class, I'm retracting this patch. I'd like to revisit this for Python 3000 since I really think that it is how things *ought* to be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103689&group_id=5470 From noreply at sourceforge.net Sat Jan 22 08:40:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 22 08:40:38 2005 Subject: [Patches] [ python-Patches-1107221 ] Updated "Working on Cygwin" section Message-ID: Patches item #1107221, was opened at 2005-01-22 18:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107221&group_id=5470 From noreply at sourceforge.net Sun Jan 23 06:43:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 06:43:40 2005 Subject: [Patches] [ python-Patches-1107656 ] Add Thread.isActive() Message-ID: Patches item #1107656, was opened at 2005-01-23 16:43 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=1107656&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan Green (alanvgreen) Assigned to: Nobody/Anonymous (nobody) Summary: Add Thread.isActive() Initial Comment: The documentation for threading.Thread states: """Once the thread's activity is started, the thread is considered 'alive' and 'active' (these concepts are almost, but not quite exactly, the same; their definition is intentionally somewhat vague). It stops being alive and active when its run() method terminates - either normally, or by raising an unhandled exception.""" This is confusing. There doesn't seem to be a need to expose both 'alive' and 'active' concepts in the API. The confusion was reported as part of Issue 912943 "7.5.6 Thread Objects is too vague" This patch: - adds an isActive() method to Thread, that tests whether the thread is active. - adds documentation for isActive() - modifies the documentation for isAlive(), noting that it is deprecated and explaining why. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107656&group_id=5470 From noreply at sourceforge.net Sun Jan 23 10:28:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 10:28:25 2005 Subject: [Patches] [ python-Patches-579435 ] Shadow Password Support Module Message-ID: Patches item #579435, was opened at 2002-07-10 05:13 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 Category: Modules Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lance Ellinghaus (ellinghaus) Assigned to: A.M. Kuchling (akuchling) Summary: Shadow Password Support Module Initial Comment: Attached is the spwd module. This module provides support for Shadow Passwords on Solaris 2.8. This compliments the nis and pwd modules. This is the only way to gain access to the encrypted passwords when using shadow passwords on Solaris. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-23 10:28 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure 1.468 configure.in 1.481 pyconfig.h.in 1.106 setup.py 1.212 Makefile.deps 1.123 lib.tex 1.237 libpwd.tex 1.15 libspwd.tex 1.1 NEWS 1.1231 Setup.dist 1.49 spwdmodule.c 1.1 ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-20 22:31 Message: Logged In: YES user_id=129426 I've attached my new version of the patch (files are marked New Patch). I've updated the extension module itself to 'modern' standards (i.e. making it look as similar to pwdmodule.c as possible, including the tuple-like result object). I'm not too sure how this module compiles on different platforms, but I've added preprocessor checks for the relevant system calls. This module needs to be tested on different systems (I've developed it on Linux). There is no regression test yet. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-17 22:03 Message: Logged In: YES user_id=129426 Martin, yes I will give it a try. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-17 07:02 Message: Logged In: YES user_id=21627 irmen, are you willing to complete this patch? ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:48 Message: Logged In: YES user_id=129426 I would be happy if this module in one form or another makes it into Python; I recently wanted to do user authentication based on unix passwords but the regular passwd functions cannot retrieve the password to check against). As an aside, how does PAM relate to this? I fooled around a bit with a python pam module, but simply didn't understand it and couldn't get it to work properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 18:38 Message: Logged In: YES user_id=21627 If we eventually want to support all the shadow passwort APIs, we should make this a separate module - with that approach, building spwd can might fail without causing a failure to compile pwd. Unfortunately, the patch is still incomplete: there is no change to setup.py, and no documentation change. Are there any volunteers interesting in completing it? If not, I'm going to close it again. Anybody hunting for such a module will still be able to find it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-01-13 16:32 Message: Logged In: YES user_id=11375 As it happens, I was hunting for Python shadow password support and came across this patch. The module isn't Solaris-specific, and would be necessary on Linux, too. However, the interface for getting shadow passwords doesn't seem to be standardized; see http://www.unixpapa.com/incnote/passwd. html for a list. (The Single Unix spec doesn't seem to mention shadow passwords.) One question is whether we want a new module for this, or if the functions should be in the existing pwd module. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:22 Message: Logged In: YES user_id=33168 There doesn't seem to be much interest in this patch. I don't think it reaches a wide-enough audience, therefore, I'm rejecting it. If there is broader support (many people are interested in seeing shadow password support in the core), we can add it later. I think it would be best to provide this as a third-party module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 From noreply at sourceforge.net Sun Jan 23 13:21:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 13:21:20 2005 Subject: [Patches] [ python-Patches-1094015 ] Improvements for shutil.copytree() Message-ID: Patches item #1094015, was opened at 2005-01-01 09:26 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094015&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: Improvements for shutil.copytree() Initial Comment: See bugs #975763 and #1048878. The patch changes shutil.copytree() to use os.makedirs() instead of os.mkdir() and to copy directory bits using copystat(), because file bits are copied, too. It includes a doc change to mention these details. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-23 13:21 Message: Logged In: YES user_id=469548 I see. I've moved the copystat call to after the loop in rev. 1.36. ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2005-01-17 01:10 Message: Logged In: YES user_id=100649 For files, the ctime and atime is copied, too, as part of copystat() - directly AFTER copying the file. But if the copystat() call for a directory is done BEFORE filling that directory with files, the atime and mtime of the directory will be changed by that again. So better move the copystat call for the directory to after the for loop. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 13:32 Message: Logged In: YES user_id=469548 Applied on HEAD. Thanks for the patch! Log message: Checking in Doc/lib/libshutil.tex; /cvsroot/python/python/dist/src/Doc/lib/libshutil.tex,v <-- libshutil.tex new revision: 1.16; previous revision: 1.15 done Checking in Lib/shutil.py; /cvsroot/python/python/dist/src/Lib/shutil.py,v <-- shutil.py new revision: 1.35; previous revision: 1.34 done ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094015&group_id=5470 From noreply at sourceforge.net Sun Jan 23 15:26:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 15:27:47 2005 Subject: [Patches] [ python-Patches-1101726 ] Patch for potential buffer overrun in tokenizer.c Message-ID: Patches item #1101726, was opened at 2005-01-13 06:45 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for potential buffer overrun in tokenizer.c Initial Comment: The fp_readl function in tokenizer.c has a potential buffer overrun; see: www.python.org/sf/1089395 It is also triggered by trying to generate the pycom file for the Excel 11.0 typelib, which is where I ran into it. The attached patch allows successful generation of the Excel file; it also runs the fail.py script from the above report without an access violation. It also doesn't break any of the tests in the regression suite (probably something like fail.py should be added as a test). It is not as efficient as it might be; with a function for determining the number of unicode characters in a utf8 string, you could avoid some memory allocations. Perhaps such a function should be added to unicodeobject.c? And, of course, the patch definitely needs review. I'm especially concerned that my use of tok->decoding_buffer might be violating some kind of assumption that I missed. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2005-01-23 05:26 Message: Logged In: YES user_id=86307 I'm attaching a new patch (tokenizer.c.2.diff), which should be better since it avoids some unnecessary allocations and decoding/encoding. Hopefully, I haven't made any unwarranted assumptions about UTF8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 From noreply at sourceforge.net Sun Jan 23 19:32:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 19:32:10 2005 Subject: [Patches] [ python-Patches-1107887 ] Speed up function calls/can add more introspection info Message-ID: Patches item #1107887, was opened at 2005-01-23 13:32 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=1107887&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up function calls/can add more introspection info Initial Comment: This patch adds a new method type (flags) METH_ARGS (yeah, the name could be better) that is used in PyMethodDef. METH_ARGS means the min and max # of arguments are specified in the PyMethodDef by adding 2 new fields. This information can be used in ceval to call the method. No tuple packing/unpacking is required since the C stack is used. The original patch only modifies Python/bltinmodule.c. If the approach is desirable, Objects/*.c should be modified and so should code in Modules/ (probably). The benefits are: * faster function calls * simplify function call machinery by removing METH_NOARGS, METH_O, and possibly METH_VARARGS * more introspection info for C functions (ie, min/max arg count) The primary drawback is: * the defn of the MethodDef (# args) is separate from the function defn * potentially more error prone to write C methods??? I've measured between 13-22% speed improvement when doing simple tests like: ./python ./Lib/timeit.py -v 'pow(3, 5)' I think the difference tends to be fairly constant at about .3 usec per loop. I'm not sure of the effect on memory usage. I wouldn't expect it to be much in either direction. Note: This patch does not make the min/max arg count available to Python code. If this patch is accepted, that seems like it should also be done. It's possible that METH_VARARGS may not be able to go away. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107887&group_id=5470 From noreply at sourceforge.net Sun Jan 23 19:40:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 19:41:00 2005 Subject: [Patches] [ python-Patches-1107887 ] Speed up function calls/can add more introspection info Message-ID: Patches item #1107887, was opened at 2005-01-23 13:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107887&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up function calls/can add more introspection info Initial Comment: This patch adds a new method type (flags) METH_ARGS (yeah, the name could be better) that is used in PyMethodDef. METH_ARGS means the min and max # of arguments are specified in the PyMethodDef by adding 2 new fields. This information can be used in ceval to call the method. No tuple packing/unpacking is required since the C stack is used. The original patch only modifies Python/bltinmodule.c. If the approach is desirable, Objects/*.c should be modified and so should code in Modules/ (probably). The benefits are: * faster function calls * simplify function call machinery by removing METH_NOARGS, METH_O, and possibly METH_VARARGS * more introspection info for C functions (ie, min/max arg count) The primary drawback is: * the defn of the MethodDef (# args) is separate from the function defn * potentially more error prone to write C methods??? I've measured between 13-22% speed improvement when doing simple tests like: ./python ./Lib/timeit.py -v 'pow(3, 5)' I think the difference tends to be fairly constant at about .3 usec per loop. I'm not sure of the effect on memory usage. I wouldn't expect it to be much in either direction. Note: This patch does not make the min/max arg count available to Python code. If this patch is accepted, that seems like it should also be done. It's possible that METH_VARARGS may not be able to go away. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-01-23 13:40 Message: Logged In: YES user_id=33168 Also see, http://mail.python.org/pipermail/python-dev/2005-January/051251.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107887&group_id=5470 From noreply at sourceforge.net Sun Jan 23 22:58:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 22:58:19 2005 Subject: [Patches] [ python-Patches-1107973 ] tarfile.ExFileObject iterators Message-ID: Patches item #1107973, was opened at 2005-01-23 14:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107973&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107973&group_id=5470 From noreply at sourceforge.net Mon Jan 24 07:22:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 07:22:29 2005 Subject: [Patches] [ python-Patches-1057588 ] chr, ord, unichr documentation updates Message-ID: Patches item #1057588, was opened at 2004-10-31 02:25 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: chr, ord, unichr documentation updates Initial Comment: The attached diff may be applied against v1.175 of libfuncs.tex -- http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Doc/lib/libfuncs.tex?content-type=text%2Fplain&rev=1.175 chr(): A str is not in any particular encoding, so don't talk about ASCII, which does not apply to arguments > 127 anyway. Also make reference to unichr(). ord(): A str is not in any particular encoding, so don't talk about ASCII. Describe what the return value represents for each type of string (str, unicode), and mention the TypeError that will be raised on narrow unicode builds of Python. unichr(): Mention the restrictions on the argument depending on whether Python was built with wide or narrow unicode. The precedent in unicode() is to refer to str objects as "8-bit strings", so the wording of the above changes was chosen accordingly. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-01-24 01:22 Message: Logged In: YES user_id=593130 I strongly prefer byte string to 8-bit string both because the former is easier to think/say and because it is more accurate. 8-bits, or rather, 256 different possible values, is a minimum but not a maximum. If, for instance, Python were ported to old machines with 6-bit chars, it would likely use 12-bit bytes (double machine bytes) with code similar to USC2 (double 8-bit byte) unicode builds. And, given that there are no bit operations of the bytes of a byte string, the machine implementation in terms of bits is not really relevant. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2005-01-19 05:50 Message: Logged In: YES user_id=371366 Thanks. I've attached a new copy of the patch, with minor substitions made (UCS2 and UCS4 instead of narrow and wide, mainly). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 01:59 Message: Logged In: YES user_id=3066 Ah, ok, here's some answers, then: (1) "unicode object" is right. (2) I'm happy with either "8-bit string" or "byte string", so whichever you find makes more sense in context is good. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2005-01-19 01:42 Message: Logged In: YES user_id=371366 I was just waiting for someone to answer my question about terminology. (1) Is there a recommendation for how to refer unambiguously to an instance of a unicode type? Is it a "unicode object"? (2) How about an instance of the str type? Is it an "8-bit string"? I notice we say "byte string" a lot but apparently not everyone is happy about that. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-18 23:52 Message: Logged In: YES user_id=3066 Is the patch here finished, or was additional work needed? ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-11-02 01:56 Message: Logged In: YES user_id=371366 You're right re: UCS2/UCS4. I can work up another patch. I think you know this, but "code point" is not accurate UTR#17-conformant terminology, as it just refers to the single integer number from the code space that is available to Unicode (0x0-0xD7FF and 0xE000-0x10FFFF), bearing in mind that not all code points correspond to characters (all those whose hex values end in FFFE and FFFF, for example). If we are just talking about what a Unicode string is in general sense, we say it is just a sequence of characters -- a character being a unit like, say, "Latin small letter z", or "plus sign", in a writing system ("script") like Latin/Roman, Cyrillic, Hiragana, etc. If we are talking about what the unicode type is in Python, to be accurate, we should say it is a sequence of UCS2 or UCS4 "code values", depending on how Python was compiled, and note that in its printable representation, the unicode type displays, for characters outside the ASCII range, the "code points" represented by those code values. It does this using the same syntax as for string literals, but treats surrogate pairs of code values as being representative of a single code point (e.g., a unicode object consisting of code value 0xD800 followed by 0xDC00 is printably represented by u'\U00010000' even though it's still a string of length 2 in both UCS2 and UCS4 builds of Python). Is there a recommendation for how to refer unambiguously to an instance of a unicode type? Is it a "unicode object"? How about an instance of the str type? Is it an "8-bit string"? I notice we say "byte string" a lot but apparently not everyone is happy about that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-11-01 06:11 Message: Logged In: YES user_id=38388 The new wording is indeed better than the old one. +1 on that change. However, you should use the term "code point" consistently and perhaps add a footnote explaining the difference between code point, glyph and character (Unicode strings are arrays of code points - not characters). Another note: I don't particularly like the terms "narrow" and "wide" Unicode builds. If possible, these terms should be replaced by the more accurate technical terms UCS2 and UCS4 - since the error messages relating to this difference also mention these technical terms rather then narrow or wide builds. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 13:17 Message: Logged In: YES user_id=371366 Oops, didn't mean to remove the assignment to fdrake when adding previous comment. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 03:23 Message: Logged In: YES user_id=371366 Also note that I did not suggest removing the example with the letter "a". I just suggested removing the reference to "ASCII" in particular. Ideally, IMHO, the documentation for sequence types is where one should mention the strong association between strings and ASCII. It currently doesn't even really describe what a string or Unicode string is. It should state that non-Unicode strings are an abstraction in which each member of the sequence is a "character" that is actually an 8-bit value, as in Standard C, intended to represent a character in an arbitrary encoding, and that there is an _informal_ convention, in documentation, of referring to these values as being ASCII values, in part due to the notational conventions of string literals, such as using "\t", "\n", and "\r" to represent decimal values 9, 10, and 13, respectively (associations that only make sense in ASCII or ASCII-based encodings), and in part because it is easier to talk about the lower 128 values in terms of their ASCII equivalents (e.g. "chr(97) produces the string 'a'"). Likewise, the unicode type could be described as being an abstraction of 16-bit ("narrow") or 32-bit ("wide") code units, depending on how Python was built, and so on... I would see making such unambiguous statements to be a reasonable alternative to just deleting mentions of ASCII from the library docs, although I think making all of the changes would be best, as people already have preconceived notions of what a 'string' is and I know from experience that they tend to not worry about straightening out their understanding of such nuances until they get burned by assumptions built around statements like "ord() gives you the ASCII value". ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-31 02:51 Message: Logged In: YES user_id=371366 That kind of resistance to using accurate, strict terminology just perpetuates common misunderstandings about the relationship between characters and encodings. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-31 02:38 Message: Logged In: YES user_id=80475 The attachment didn't make it. Try again. And, FWIW, I think the documentation is perfectly clear as is. Though the ASCII reference is not strict, I think taking it out would be a mistake. Though many encodings are possible, there is a strong relationship between the number 97 and the letter 'a'. Mentioning ASCII makes that relationship clear. IOW, I -1 on changing it until a new bytes type is introduced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057588&group_id=5470 From buyer_9 at hotmail.com Mon Jan 24 09:11:44 2005 From: buyer_9 at hotmail.com (a a) Date: Mon Jan 24 09:12:04 2005 Subject: [Patches] aa Message-ID: aa _________________________________________________________________ ²{¦b´N¤W MSN ¥xÆWºô¯¸¡G»P¿ËªB¦n¤Íºò±KÁpô¡A§Y®É´x´¤·s»D¡B°]¸g¡B®T¼Öªº³Ì·s°T ®§ http://msn.com.tw From noreply at sourceforge.net Mon Jan 24 12:17:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 12:17:17 2005 Subject: [Patches] [ python-Patches-1108272 ] Allow slicing of any iterator by default Message-ID: Patches item #1108272, was opened at 2005-01-24 21:17 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=1108272&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Allow slicing of any iterator by default Initial Comment: This patch allows any iterable to automatically support subscripting. Simple indices (itr[n]) will consume the iterator, and return the n'th item produced. Slice indices (itr[start:stop:step]) will produce an itertools.islice object created with the appropriate arguments. It also adds the C API function PyIter_GetItem which implements the above, and is invoked by PyObject_GetItem. Built and trivially tested on Suse Linux 9.1 from current CVS. Documentation and tests still to be added (Wednesday is a public holiday, so I will hopefully get to them then). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108272&group_id=5470 From noreply at sourceforge.net Mon Jan 24 13:25:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 13:25:53 2005 Subject: [Patches] [ python-Patches-1108303 ] fix .split() separator doc, update .rsplit() docs Message-ID: Patches item #1108303, was opened at 2005-01-24 13:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: fix .split() separator doc, update .rsplit() docs Initial Comment: Hi, this documentation patch for the .split() and .rsplit() methods changes the following: 1) remove a superfluous dot in .split() method doc 2) Only if separator arg is _less than_ zero, the number of splits is unlimited. If it is zero, the number of splits is (correctly) zero. The "less than" has been added. 3) The separator documentation of split() is copied over to rsplit() documentation where it applies too. The patch is against CVS from 20040123. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 From noreply at sourceforge.net Mon Jan 24 13:26:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 13:26:41 2005 Subject: [Patches] [ python-Patches-1108303 ] fix .split() separator doc, update .rsplit() docs Message-ID: Patches item #1108303, was opened at 2005-01-24 13:25 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: fix .split() separator doc, update .rsplit() docs Initial Comment: Hi, this documentation patch for the .split() and .rsplit() methods changes the following: 1) remove a superfluous dot in .split() method doc 2) Only if separator arg is _less than_ zero, the number of splits is unlimited. If it is zero, the number of splits is (correctly) zero. The "less than" has been added. 3) The separator documentation of split() is copied over to rsplit() documentation where it applies too. The patch is against CVS from 20040123. ---------------------------------------------------------------------- >Comment By: Wummel (calvin) Date: 2005-01-24 13:26 Message: Logged In: YES user_id=9205 I also added appropriate test cases for split() and rsplit() with negative separator argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 From noreply at sourceforge.net Mon Jan 24 13:29:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 13:29:46 2005 Subject: [Patches] [ python-Patches-1108303 ] fix .split() separator doc, update .rsplit() docs Message-ID: Patches item #1108303, was opened at 2005-01-24 13:25 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: fix .split() separator doc, update .rsplit() docs Initial Comment: Hi, this documentation patch for the .split() and .rsplit() methods changes the following: 1) remove a superfluous dot in .split() method doc 2) Only if separator arg is _less than_ zero, the number of splits is unlimited. If it is zero, the number of splits is (correctly) zero. The "less than" has been added. 3) The separator documentation of split() is copied over to rsplit() documentation where it applies too. The patch is against CVS from 20040123. ---------------------------------------------------------------------- >Comment By: Wummel (calvin) Date: 2005-01-24 13:29 Message: Logged In: YES user_id=9205 Argl, please replace any mention of "separator" above with "maxsplit". Sorry for the confusion. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:26 Message: Logged In: YES user_id=9205 I also added appropriate test cases for split() and rsplit() with negative separator argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 From noreply at sourceforge.net Mon Jan 24 13:34:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 13:34:30 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-03 05:26 Message generated for change (Comment added) made by alanvgreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-24 23:34 Message: Logged In: YES user_id=1174944 Some thoughts while we wait for the PEP: 1. This doesn't look like a collection class to me. It's more of a convenient substitute for a first-class object. The PEP would need to include a rationale as to why this class is in the collections module. 2. It may be desireable to make the core parts of Bunch (equality test, repr, and update) available as functions that other classes can use if appropriate. This might help developers building objects more complex than a Bunch. Then again, maybe not, but I'd like to see the PEP address this. 3. The docstring on __eq__ should explicitly say what consitutes equality for bunches: both bunches have the same attributes and the same values for those attributes. 4. It's easy enough to convert a dict to a Bunch (via the Bunch constructor), but I would have expected that there be a way to convert a Bunch to a dict. Overall, a useful concept, but I'd like to read the PEP - you could always upload your draft to this patch item :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-11 02:15 Message: Logged In: YES user_id=945502 I submitted a PEP for it on 2 Jan 2005, but I haven't heard back from peps@python.org yet. Sorry, I didn't realize it might take so long to get a PEP number. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-01-11 01:08 Message: Logged In: YES user_id=99874 Would someone be willing to provide the motivation for adding this class? I'm certainly willing to listen, but I'm not convinced this is worth adding to the std library. (I guess that's a -0 vote.) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-01-04 04:38 Message: Logged In: YES user_id=1188172 Let me add that the main functionality consists in the easy initializing and updating (otherwise, you just could use an empty class). I'm +1 on the class, but I would call it `bunch'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From noreply at sourceforge.net Mon Jan 24 13:52:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 13:52:16 2005 Subject: [Patches] [ python-Patches-1108303 ] fix .split() maxsplit doc, update .rsplit() docs Message-ID: Patches item #1108303, was opened at 2005-01-24 13:25 Message generated for change (Settings changed) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) >Summary: fix .split() maxsplit doc, update .rsplit() docs Initial Comment: Hi, this documentation patch for the .split() and .rsplit() methods changes the following: 1) remove a superfluous dot in .split() method doc 2) Only if separator arg is _less than_ zero, the number of splits is unlimited. If it is zero, the number of splits is (correctly) zero. The "less than" has been added. 3) The separator documentation of split() is copied over to rsplit() documentation where it applies too. The patch is against CVS from 20040123. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:29 Message: Logged In: YES user_id=9205 Argl, please replace any mention of "separator" above with "maxsplit". Sorry for the confusion. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:26 Message: Logged In: YES user_id=9205 I also added appropriate test cases for split() and rsplit() with negative separator argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 From noreply at sourceforge.net Mon Jan 24 17:34:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 17:34:42 2005 Subject: [Patches] [ python-Patches-1105730 ] Faster commonprefix in macpath, ntpath, etc. Message-ID: Patches item #1105730, was opened at 2005-01-19 23:34 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1105730&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jimmy Retzlaff (jretz) Assigned to: Nobody/Anonymous (nobody) Summary: Faster commonprefix in macpath, ntpath, etc. Initial Comment: Patch 681780 resulted in a faster version of commonprefix for posixpath.py. The same implementation should work fine for macpath.py, ntpath.py, os2emxpath.py, and plat-riscos/riscospath.py but it didn't make it into those. This is simply the posixpath.commonprefix implementation copied into these files. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-01-24 10:34 Message: Logged In: YES user_id=2772 Why not write 'from posixpath import commonprefix' in each of the other XXXpath.py modules, to benefit from any future improvements? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1105730&group_id=5470 From noreply at sourceforge.net Mon Jan 24 23:57:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 23:57:18 2005 Subject: [Patches] [ python-Patches-1105730 ] Faster commonprefix in macpath, ntpath, etc. Message-ID: Patches item #1105730, was opened at 2005-01-19 21:34 Message generated for change (Comment added) made by jretz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1105730&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jimmy Retzlaff (jretz) Assigned to: Nobody/Anonymous (nobody) Summary: Faster commonprefix in macpath, ntpath, etc. Initial Comment: Patch 681780 resulted in a faster version of commonprefix for posixpath.py. The same implementation should work fine for macpath.py, ntpath.py, os2emxpath.py, and plat-riscos/riscospath.py but it didn't make it into those. This is simply the posixpath.commonprefix implementation copied into these files. ---------------------------------------------------------------------- >Comment By: Jimmy Retzlaff (jretz) Date: 2005-01-24 14:57 Message: Logged In: YES user_id=101588 I had assumed there were historical reasons that the platform specific implementations of os.path weren?t importing from each other. If this is not the case then I?m all for eliminating the duplication of code. I?m attaching an alternate patch (called importcommonprefix.diff) for this approach. I've tested it on Windows, but I don't have a means of testing the other versions. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-01-24 08:34 Message: Logged In: YES user_id=2772 Why not write 'from posixpath import commonprefix' in each of the other XXXpath.py modules, to benefit from any future improvements? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1105730&group_id=5470 From noreply at sourceforge.net Tue Jan 25 00:23:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 00:23:06 2005 Subject: [Patches] [ python-Patches-1107887 ] Speed up function calls/can add more introspection info Message-ID: Patches item #1107887, was opened at 2005-01-23 13:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107887&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up function calls/can add more introspection info Initial Comment: This patch adds a new method type (flags) METH_ARGS (yeah, the name could be better) that is used in PyMethodDef. METH_ARGS means the min and max # of arguments are specified in the PyMethodDef by adding 2 new fields. This information can be used in ceval to call the method. No tuple packing/unpacking is required since the C stack is used. The original patch only modifies Python/bltinmodule.c. If the approach is desirable, Objects/*.c should be modified and so should code in Modules/ (probably). The benefits are: * faster function calls * simplify function call machinery by removing METH_NOARGS, METH_O, and possibly METH_VARARGS * more introspection info for C functions (ie, min/max arg count) The primary drawback is: * the defn of the MethodDef (# args) is separate from the function defn * potentially more error prone to write C methods??? I've measured between 13-22% speed improvement when doing simple tests like: ./python ./Lib/timeit.py -v 'pow(3, 5)' I think the difference tends to be fairly constant at about .3 usec per loop. I'm not sure of the effect on memory usage. I wouldn't expect it to be much in either direction. Note: This patch does not make the min/max arg count available to Python code. If this patch is accepted, that seems like it should also be done. It's possible that METH_VARARGS may not be able to go away. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-01-24 18:23 Message: Logged In: YES user_id=33168 Martin pointed out that chr(5.3) is mishandled by this patch and needs to be corrected. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-01-23 13:40 Message: Logged In: YES user_id=33168 Also see, http://mail.python.org/pipermail/python-dev/2005-January/051251.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107887&group_id=5470 From noreply at sourceforge.net Tue Jan 25 13:05:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 13:05:48 2005 Subject: [Patches] [ python-Patches-1100942 ] datetime.strptime constructor added Message-ID: Patches item #1100942, was opened at 2005-01-13 01:53 Message generated for change (Comment added) made by alanvgreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100942&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Josh (josh-sf) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.strptime constructor added Initial Comment: Alllow creating new datetime objects by parsing date strings. datetime already has strftime, so adding strptime is logical. The new constructor is equivalent to datetime(*(time.strptime(date_string, format)[0:6])). Patch includes documentation and unit test. ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-25 23:05 Message: Logged In: YES user_id=1174944 This patch will be welcomed by all of that have had to write "datetime(*(time.strptime(date_string, format)[0:6]))". I don't understand the C API well enough to check if reference counts are handled properly, but otherwise the implementation looks straight forward. Documentation looks good and the test passes on my machine. Two suggestions: 1. In the time module, the strptime() function's format parameter is optional. For consistency's sake, I'd expect datetime.strptime()'s format parameter also to be optional. (On the other hand, the default value for the format is not very useful.) 2. Since strftime is supported by datetime.time, datetime.date and datetime.datetime, I'd also expect strptime to be supported by all three classes. Could you add that now, or would it be better to do it as a separate patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100942&group_id=5470 From noreply at sourceforge.net Tue Jan 25 13:40:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 13:41:07 2005 Subject: [Patches] [ python-Patches-1108303 ] fix .split() maxsplit doc, update .rsplit() docs Message-ID: Patches item #1108303, was opened at 2005-01-24 23:25 Message generated for change (Comment added) made by alanvgreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: fix .split() maxsplit doc, update .rsplit() docs Initial Comment: Hi, this documentation patch for the .split() and .rsplit() methods changes the following: 1) remove a superfluous dot in .split() method doc 2) Only if separator arg is _less than_ zero, the number of splits is unlimited. If it is zero, the number of splits is (correctly) zero. The "less than" has been added. 3) The separator documentation of split() is copied over to rsplit() documentation where it applies too. The patch is against CVS from 20040123. ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-25 23:40 Message: Logged In: YES user_id=1174944 Docs read well and work fine. Tests pass on my linux-based development PC. Please apply this patch. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 23:29 Message: Logged In: YES user_id=9205 Argl, please replace any mention of "separator" above with "maxsplit". Sorry for the confusion. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 23:26 Message: Logged In: YES user_id=9205 I also added appropriate test cases for split() and rsplit() with negative separator argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 From noreply at sourceforge.net Tue Jan 25 21:06:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 21:06:37 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-02 11:26 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- >Comment By: Steven Bethard (bediviere) Date: 2005-01-25 13:06 Message: Logged In: YES user_id=945502 Ok, I'll post the current PEP draft below. Of course, I welcome any suggestions to make its acceptance more likely. I'll definitely update the __eq__ docstring as suggested, but I'll probably wait until I've heard what other changes should be made. ---------------------------------------------------------------------- PEP: XXX Title: Generic Object Data Type Version: $Revision: 1.0 $ Last-Modified: $Date: 2004/11/29 16:00:00 $ Author: Steven Bethard Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 29-Nov-2004 Python-Version: 2.5 Post-History: 29-Nov-2004 Abstract ======== This PEP proposes a standard library addition to support the simple creation of 'generic' objects which can be given named attributes without the need to declare a class. Such attribute-value mappings are intended to complement the name-value mappings provided by Python's builtin dict objects. Motivation ========== Python's dict objects provide a simple way of creating anonymous name-value mappings. These mappings use the __getitem__ protocol to access the value associated with a name, so that code generally appears like:: mapping['name'] Occasionally, a programmer may decide that dotted-attribute style access is more appropriate to the domain than __getitem__ style access, and that their mapping should be accessed like:: mapping.name Currently, if a Python programmer makes this design decision, they are forced to declare a new class, and then build instances of this class. When no methods are to be associated with the attribute-value mappings, declaring a new class can be overkill. This PEP proposes adding a simple type to the collections module of the standard library that can be used to build such attribute-value mappings. Providing such a type allows the Python programmer to determine which type of mapping is most appropriate to their domain and apply this choice with minimal effort. Some of the suggested uses include: Returning Named Results ----------------------- It is often appropriate for a function that returns multiple items to give names to the different items returned. The type suggested in this PEP provides a simple means of doing this that allows the returned values to be accessed in the usual attribute-style access:: >>> def f(x): ... return Bunch(double=2*x, squared=x**2) ... >>> y = f(10) >>> y.double 20 >>> y.squared 100 Representing Hierarchical Data ------------------------------ The type suggested in this PEP also allows a simple means of representing hierarchical data that allows attribute-style access:: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' Rationale ========= As Bunch objects are intended primarily to replace simple, data-only classes, simple Bunch construction was a primary concern. As such, the Bunch constructor supports creation from keyword arguments, dicts, and sequences of (attribute, value) pairs:: >>> Bunch(eggs=1, spam=2, ham=3) Bunch(eggs=1, ham=3, spam=2) >>> Bunch({'eggs':1, 'spam':2, 'ham':3}) Bunch(eggs=1, ham=3, spam=2) >>> Bunch([('eggs',1), ('spam',2), ('ham',3)]) Bunch(eggs=1, ham=3, spam=2) To allow attribute-value mappings to be easily combined, the update method of Bunch objects supports similar arguments. If Bunch objects are used to represent hierarchical data, comparison of such objects becomes a concern. For this reason, Bunch objects support object equality:: >>> x = Bunch(parrot=Bunch(lumberjack=True, spam=42), peng='shrub') >>> y = Bunch(peng='shrub', parrot=Bunch(spam=42, lumberjack=True)) >>> z = Bunch(parrot=Bunch(lumberjack=True), peng='shrub') >>> x == y True >>> x == z False Note that support for the various mapping methods, e.g. __(get|set|del)item__, __len__, __iter__, __contains__, items, keys, values, etc. was intentionally omitted as these methods did not seem to be necessary for the core uses of an attribute-value mapping. If such methods are truly necessary for a given use case, this may suggest that a dict object is a more appropriate type for that use. Examples ========= Converting an XML DOM tree into a tree of nested Bunch objects:: >>> import xml.dom.minidom >>> def getbunch(element): ... result = Bunch() ... if element.attributes: ... result.update(element.attributes.items()) ... children = {} ... for child in element.childNodes: ... if child.nodeType == xml.dom.minidom.Node.TEXT_NODE: ... children.setdefault('text', []).append( ... child.nodeValue) ... else: ... children.setdefault(child.nodeName, []).append( ... getbunch(child)) ... result.update(children) ... return result ... >>> doc = xml.dom.minidom.parseString(""" ... ... ... a text 1 ... ... b text ... a text 2 ... ... c text ... """) >>> b = getbunch(doc.documentElement) >>> b.a[0].b[1] Bunch(attr_b=u'3', text=[u' b text ']) Reference Implementation ======================== The code is available as SourceForge patch 1094542 [1]_. Open Issues =========== What should the type be named? Some suggestions include 'Bunch', 'Record', 'Struct' and 'Namespace'. Where should the type be placed? The current suggestion is the collections module. References ========== .. [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1094542&group_id=5470&atid=305470 .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-24 05:34 Message: Logged In: YES user_id=1174944 Some thoughts while we wait for the PEP: 1. This doesn't look like a collection class to me. It's more of a convenient substitute for a first-class object. The PEP would need to include a rationale as to why this class is in the collections module. 2. It may be desireable to make the core parts of Bunch (equality test, repr, and update) available as functions that other classes can use if appropriate. This might help developers building objects more complex than a Bunch. Then again, maybe not, but I'd like to see the PEP address this. 3. The docstring on __eq__ should explicitly say what consitutes equality for bunches: both bunches have the same attributes and the same values for those attributes. 4. It's easy enough to convert a dict to a Bunch (via the Bunch constructor), but I would have expected that there be a way to convert a Bunch to a dict. Overall, a useful concept, but I'd like to read the PEP - you could always upload your draft to this patch item :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-10 08:15 Message: Logged In: YES user_id=945502 I submitted a PEP for it on 2 Jan 2005, but I haven't heard back from peps@python.org yet. Sorry, I didn't realize it might take so long to get a PEP number. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-01-10 07:08 Message: Logged In: YES user_id=99874 Would someone be willing to provide the motivation for adding this class? I'm certainly willing to listen, but I'm not convinced this is worth adding to the std library. (I guess that's a -0 vote.) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-01-03 10:38 Message: Logged In: YES user_id=1188172 Let me add that the main functionality consists in the easy initializing and updating (otherwise, you just could use an empty class). I'm +1 on the class, but I would call it `bunch'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From noreply at sourceforge.net Tue Jan 25 21:42:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 21:42:35 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-02 13:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-25 15:42 Message: Logged In: YES user_id=80475 This needs a better name than Bunch. The clearly suggested a collection but is otherwise amorphous and fails to suggest any relevant properties. In language design, naming is vital. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-25 15:06 Message: Logged In: YES user_id=945502 Ok, I'll post the current PEP draft below. Of course, I welcome any suggestions to make its acceptance more likely. I'll definitely update the __eq__ docstring as suggested, but I'll probably wait until I've heard what other changes should be made. ---------------------------------------------------------------------- PEP: XXX Title: Generic Object Data Type Version: $Revision: 1.0 $ Last-Modified: $Date: 2004/11/29 16:00:00 $ Author: Steven Bethard Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 29-Nov-2004 Python-Version: 2.5 Post-History: 29-Nov-2004 Abstract ======== This PEP proposes a standard library addition to support the simple creation of 'generic' objects which can be given named attributes without the need to declare a class. Such attribute-value mappings are intended to complement the name-value mappings provided by Python's builtin dict objects. Motivation ========== Python's dict objects provide a simple way of creating anonymous name-value mappings. These mappings use the __getitem__ protocol to access the value associated with a name, so that code generally appears like:: mapping['name'] Occasionally, a programmer may decide that dotted-attribute style access is more appropriate to the domain than __getitem__ style access, and that their mapping should be accessed like:: mapping.name Currently, if a Python programmer makes this design decision, they are forced to declare a new class, and then build instances of this class. When no methods are to be associated with the attribute-value mappings, declaring a new class can be overkill. This PEP proposes adding a simple type to the collections module of the standard library that can be used to build such attribute-value mappings. Providing such a type allows the Python programmer to determine which type of mapping is most appropriate to their domain and apply this choice with minimal effort. Some of the suggested uses include: Returning Named Results ----------------------- It is often appropriate for a function that returns multiple items to give names to the different items returned. The type suggested in this PEP provides a simple means of doing this that allows the returned values to be accessed in the usual attribute-style access:: >>> def f(x): ... return Bunch(double=2*x, squared=x**2) ... >>> y = f(10) >>> y.double 20 >>> y.squared 100 Representing Hierarchical Data ------------------------------ The type suggested in this PEP also allows a simple means of representing hierarchical data that allows attribute-style access:: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' Rationale ========= As Bunch objects are intended primarily to replace simple, data-only classes, simple Bunch construction was a primary concern. As such, the Bunch constructor supports creation from keyword arguments, dicts, and sequences of (attribute, value) pairs:: >>> Bunch(eggs=1, spam=2, ham=3) Bunch(eggs=1, ham=3, spam=2) >>> Bunch({'eggs':1, 'spam':2, 'ham':3}) Bunch(eggs=1, ham=3, spam=2) >>> Bunch([('eggs',1), ('spam',2), ('ham',3)]) Bunch(eggs=1, ham=3, spam=2) To allow attribute-value mappings to be easily combined, the update method of Bunch objects supports similar arguments. If Bunch objects are used to represent hierarchical data, comparison of such objects becomes a concern. For this reason, Bunch objects support object equality:: >>> x = Bunch(parrot=Bunch(lumberjack=True, spam=42), peng='shrub') >>> y = Bunch(peng='shrub', parrot=Bunch(spam=42, lumberjack=True)) >>> z = Bunch(parrot=Bunch(lumberjack=True), peng='shrub') >>> x == y True >>> x == z False Note that support for the various mapping methods, e.g. __(get|set|del)item__, __len__, __iter__, __contains__, items, keys, values, etc. was intentionally omitted as these methods did not seem to be necessary for the core uses of an attribute-value mapping. If such methods are truly necessary for a given use case, this may suggest that a dict object is a more appropriate type for that use. Examples ========= Converting an XML DOM tree into a tree of nested Bunch objects:: >>> import xml.dom.minidom >>> def getbunch(element): ... result = Bunch() ... if element.attributes: ... result.update(element.attributes.items()) ... children = {} ... for child in element.childNodes: ... if child.nodeType == xml.dom.minidom.Node.TEXT_NODE: ... children.setdefault('text', []).append( ... child.nodeValue) ... else: ... children.setdefault(child.nodeName, []).append( ... getbunch(child)) ... result.update(children) ... return result ... >>> doc = xml.dom.minidom.parseString(""" ... ... ... a text 1 ... ... b text ... a text 2 ... ... c text ... """) >>> b = getbunch(doc.documentElement) >>> b.a[0].b[1] Bunch(attr_b=u'3', text=[u' b text ']) Reference Implementation ======================== The code is available as SourceForge patch 1094542 [1]_. Open Issues =========== What should the type be named? Some suggestions include 'Bunch', 'Record', 'Struct' and 'Namespace'. Where should the type be placed? The current suggestion is the collections module. References ========== .. [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1094542&group_id=5470&atid=305470 .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-24 07:34 Message: Logged In: YES user_id=1174944 Some thoughts while we wait for the PEP: 1. This doesn't look like a collection class to me. It's more of a convenient substitute for a first-class object. The PEP would need to include a rationale as to why this class is in the collections module. 2. It may be desireable to make the core parts of Bunch (equality test, repr, and update) available as functions that other classes can use if appropriate. This might help developers building objects more complex than a Bunch. Then again, maybe not, but I'd like to see the PEP address this. 3. The docstring on __eq__ should explicitly say what consitutes equality for bunches: both bunches have the same attributes and the same values for those attributes. 4. It's easy enough to convert a dict to a Bunch (via the Bunch constructor), but I would have expected that there be a way to convert a Bunch to a dict. Overall, a useful concept, but I'd like to read the PEP - you could always upload your draft to this patch item :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-10 10:15 Message: Logged In: YES user_id=945502 I submitted a PEP for it on 2 Jan 2005, but I haven't heard back from peps@python.org yet. Sorry, I didn't realize it might take so long to get a PEP number. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-01-10 09:08 Message: Logged In: YES user_id=99874 Would someone be willing to provide the motivation for adding this class? I'm certainly willing to listen, but I'm not convinced this is worth adding to the std library. (I guess that's a -0 vote.) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-01-03 12:38 Message: Logged In: YES user_id=1188172 Let me add that the main functionality consists in the easy initializing and updating (otherwise, you just could use an empty class). I'm +1 on the class, but I would call it `bunch'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From noreply at sourceforge.net Tue Jan 25 21:46:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 21:46:12 2005 Subject: [Patches] [ python-Patches-1108303 ] fix .split() maxsplit doc, update .rsplit() docs Message-ID: Patches item #1108303, was opened at 2005-01-24 07:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: fix .split() maxsplit doc, update .rsplit() docs Initial Comment: Hi, this documentation patch for the .split() and .rsplit() methods changes the following: 1) remove a superfluous dot in .split() method doc 2) Only if separator arg is _less than_ zero, the number of splits is unlimited. If it is zero, the number of splits is (correctly) zero. The "less than" has been added. 3) The separator documentation of split() is copied over to rsplit() documentation where it applies too. The patch is against CVS from 20040123. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-25 15:46 Message: Logged In: YES user_id=80475 Before seeing this patch, I fixed up the related bug. Please check the most recent update to libstdtypes.tex and make sure it meets your needs. If so, please close out this patch. ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-25 07:40 Message: Logged In: YES user_id=1174944 Docs read well and work fine. Tests pass on my linux-based development PC. Please apply this patch. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 07:29 Message: Logged In: YES user_id=9205 Argl, please replace any mention of "separator" above with "maxsplit". Sorry for the confusion. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 07:26 Message: Logged In: YES user_id=9205 I also added appropriate test cases for split() and rsplit() with negative separator argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 From noreply at sourceforge.net Tue Jan 25 21:59:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 21:59:15 2005 Subject: [Patches] [ python-Patches-1108303 ] fix .split() maxsplit doc, update .rsplit() docs Message-ID: Patches item #1108303, was opened at 2005-01-24 13:25 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: fix .split() maxsplit doc, update .rsplit() docs Initial Comment: Hi, this documentation patch for the .split() and .rsplit() methods changes the following: 1) remove a superfluous dot in .split() method doc 2) Only if separator arg is _less than_ zero, the number of splits is unlimited. If it is zero, the number of splits is (correctly) zero. The "less than" has been added. 3) The separator documentation of split() is copied over to rsplit() documentation where it applies too. The patch is against CVS from 20040123. ---------------------------------------------------------------------- >Comment By: Wummel (calvin) Date: 2005-01-25 21:59 Message: Logged In: YES user_id=9205 Part 2) of the patch still applies: it should be "less than zero" instead of just "zero". And the attached pysplittests.diff add the appropriate test cases with "-1" as maxsplit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-25 21:46 Message: Logged In: YES user_id=80475 Before seeing this patch, I fixed up the related bug. Please check the most recent update to libstdtypes.tex and make sure it meets your needs. If so, please close out this patch. ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-25 13:40 Message: Logged In: YES user_id=1174944 Docs read well and work fine. Tests pass on my linux-based development PC. Please apply this patch. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:29 Message: Logged In: YES user_id=9205 Argl, please replace any mention of "separator" above with "maxsplit". Sorry for the confusion. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:26 Message: Logged In: YES user_id=9205 I also added appropriate test cases for split() and rsplit() with negative separator argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 From noreply at sourceforge.net Tue Jan 25 22:01:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 22:01:37 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-02 11:26 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- >Comment By: Steven Bethard (bediviere) Date: 2005-01-25 14:01 Message: Logged In: YES user_id=945502 Yes, I definitely agree. I only used Bunch because it was the least controversial (and was the name used in the Cookbook). Unfortunately, it's also too vague. I feel a little uneasy about Record or Struct because, to me, they seem to imply an ordering of the attributes, while the attributes of the type here are unordered. Struct also already has a meaning in the stdlib which is quite different. Namespace has the right meaning, but I think it's so overloaded for XML that this could be confusing. Perhaps something like AttributeMapping? AttrMap, maybe? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-25 13:42 Message: Logged In: YES user_id=80475 This needs a better name than Bunch. The clearly suggested a collection but is otherwise amorphous and fails to suggest any relevant properties. In language design, naming is vital. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-25 13:06 Message: Logged In: YES user_id=945502 Ok, I'll post the current PEP draft below. Of course, I welcome any suggestions to make its acceptance more likely. I'll definitely update the __eq__ docstring as suggested, but I'll probably wait until I've heard what other changes should be made. ---------------------------------------------------------------------- PEP: XXX Title: Generic Object Data Type Version: $Revision: 1.0 $ Last-Modified: $Date: 2004/11/29 16:00:00 $ Author: Steven Bethard Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 29-Nov-2004 Python-Version: 2.5 Post-History: 29-Nov-2004 Abstract ======== This PEP proposes a standard library addition to support the simple creation of 'generic' objects which can be given named attributes without the need to declare a class. Such attribute-value mappings are intended to complement the name-value mappings provided by Python's builtin dict objects. Motivation ========== Python's dict objects provide a simple way of creating anonymous name-value mappings. These mappings use the __getitem__ protocol to access the value associated with a name, so that code generally appears like:: mapping['name'] Occasionally, a programmer may decide that dotted-attribute style access is more appropriate to the domain than __getitem__ style access, and that their mapping should be accessed like:: mapping.name Currently, if a Python programmer makes this design decision, they are forced to declare a new class, and then build instances of this class. When no methods are to be associated with the attribute-value mappings, declaring a new class can be overkill. This PEP proposes adding a simple type to the collections module of the standard library that can be used to build such attribute-value mappings. Providing such a type allows the Python programmer to determine which type of mapping is most appropriate to their domain and apply this choice with minimal effort. Some of the suggested uses include: Returning Named Results ----------------------- It is often appropriate for a function that returns multiple items to give names to the different items returned. The type suggested in this PEP provides a simple means of doing this that allows the returned values to be accessed in the usual attribute-style access:: >>> def f(x): ... return Bunch(double=2*x, squared=x**2) ... >>> y = f(10) >>> y.double 20 >>> y.squared 100 Representing Hierarchical Data ------------------------------ The type suggested in this PEP also allows a simple means of representing hierarchical data that allows attribute-style access:: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' Rationale ========= As Bunch objects are intended primarily to replace simple, data-only classes, simple Bunch construction was a primary concern. As such, the Bunch constructor supports creation from keyword arguments, dicts, and sequences of (attribute, value) pairs:: >>> Bunch(eggs=1, spam=2, ham=3) Bunch(eggs=1, ham=3, spam=2) >>> Bunch({'eggs':1, 'spam':2, 'ham':3}) Bunch(eggs=1, ham=3, spam=2) >>> Bunch([('eggs',1), ('spam',2), ('ham',3)]) Bunch(eggs=1, ham=3, spam=2) To allow attribute-value mappings to be easily combined, the update method of Bunch objects supports similar arguments. If Bunch objects are used to represent hierarchical data, comparison of such objects becomes a concern. For this reason, Bunch objects support object equality:: >>> x = Bunch(parrot=Bunch(lumberjack=True, spam=42), peng='shrub') >>> y = Bunch(peng='shrub', parrot=Bunch(spam=42, lumberjack=True)) >>> z = Bunch(parrot=Bunch(lumberjack=True), peng='shrub') >>> x == y True >>> x == z False Note that support for the various mapping methods, e.g. __(get|set|del)item__, __len__, __iter__, __contains__, items, keys, values, etc. was intentionally omitted as these methods did not seem to be necessary for the core uses of an attribute-value mapping. If such methods are truly necessary for a given use case, this may suggest that a dict object is a more appropriate type for that use. Examples ========= Converting an XML DOM tree into a tree of nested Bunch objects:: >>> import xml.dom.minidom >>> def getbunch(element): ... result = Bunch() ... if element.attributes: ... result.update(element.attributes.items()) ... children = {} ... for child in element.childNodes: ... if child.nodeType == xml.dom.minidom.Node.TEXT_NODE: ... children.setdefault('text', []).append( ... child.nodeValue) ... else: ... children.setdefault(child.nodeName, []).append( ... getbunch(child)) ... result.update(children) ... return result ... >>> doc = xml.dom.minidom.parseString(""" ... ... ... a text 1 ... ... b text ... a text 2 ... ... c text ... """) >>> b = getbunch(doc.documentElement) >>> b.a[0].b[1] Bunch(attr_b=u'3', text=[u' b text ']) Reference Implementation ======================== The code is available as SourceForge patch 1094542 [1]_. Open Issues =========== What should the type be named? Some suggestions include 'Bunch', 'Record', 'Struct' and 'Namespace'. Where should the type be placed? The current suggestion is the collections module. References ========== .. [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1094542&group_id=5470&atid=305470 .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-24 05:34 Message: Logged In: YES user_id=1174944 Some thoughts while we wait for the PEP: 1. This doesn't look like a collection class to me. It's more of a convenient substitute for a first-class object. The PEP would need to include a rationale as to why this class is in the collections module. 2. It may be desireable to make the core parts of Bunch (equality test, repr, and update) available as functions that other classes can use if appropriate. This might help developers building objects more complex than a Bunch. Then again, maybe not, but I'd like to see the PEP address this. 3. The docstring on __eq__ should explicitly say what consitutes equality for bunches: both bunches have the same attributes and the same values for those attributes. 4. It's easy enough to convert a dict to a Bunch (via the Bunch constructor), but I would have expected that there be a way to convert a Bunch to a dict. Overall, a useful concept, but I'd like to read the PEP - you could always upload your draft to this patch item :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-10 08:15 Message: Logged In: YES user_id=945502 I submitted a PEP for it on 2 Jan 2005, but I haven't heard back from peps@python.org yet. Sorry, I didn't realize it might take so long to get a PEP number. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-01-10 07:08 Message: Logged In: YES user_id=99874 Would someone be willing to provide the motivation for adding this class? I'm certainly willing to listen, but I'm not convinced this is worth adding to the std library. (I guess that's a -0 vote.) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-01-03 10:38 Message: Logged In: YES user_id=1188172 Let me add that the main functionality consists in the easy initializing and updating (otherwise, you just could use an empty class). I'm +1 on the class, but I would call it `bunch'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From noreply at sourceforge.net Tue Jan 25 22:22:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 22:22:50 2005 Subject: [Patches] [ python-Patches-1108303 ] fix .split() maxsplit doc, update .rsplit() docs Message-ID: Patches item #1108303, was opened at 2005-01-24 07:25 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) >Assigned to: Raymond Hettinger (rhettinger) Summary: fix .split() maxsplit doc, update .rsplit() docs Initial Comment: Hi, this documentation patch for the .split() and .rsplit() methods changes the following: 1) remove a superfluous dot in .split() method doc 2) Only if separator arg is _less than_ zero, the number of splits is unlimited. If it is zero, the number of splits is (correctly) zero. The "less than" has been added. 3) The separator documentation of split() is copied over to rsplit() documentation where it applies too. The patch is against CVS from 20040123. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-25 15:59 Message: Logged In: YES user_id=9205 Part 2) of the patch still applies: it should be "less than zero" instead of just "zero". And the attached pysplittests.diff add the appropriate test cases with "-1" as maxsplit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-25 15:46 Message: Logged In: YES user_id=80475 Before seeing this patch, I fixed up the related bug. Please check the most recent update to libstdtypes.tex and make sure it meets your needs. If so, please close out this patch. ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-25 07:40 Message: Logged In: YES user_id=1174944 Docs read well and work fine. Tests pass on my linux-based development PC. Please apply this patch. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 07:29 Message: Logged In: YES user_id=9205 Argl, please replace any mention of "separator" above with "maxsplit". Sorry for the confusion. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 07:26 Message: Logged In: YES user_id=9205 I also added appropriate test cases for split() and rsplit() with negative separator argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 From noreply at sourceforge.net Tue Jan 25 23:04:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 23:04:54 2005 Subject: [Patches] [ python-Patches-1109424 ] type conversion methods and subclasses Message-ID: Patches item #1109424, was opened at 2005-01-25 23:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1109424&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: type conversion methods and subclasses Initial Comment: This patch fixes the classes int, long, float and unicode so that type conversion methods (i.e. __int__, __long__, __float__, __unicode__) are used for type conversion in subclasses of int/long/float/unicode. (See the following thread on python-dev for more info: http://mail.python.org/pipermail/python-dev/2005-January/051175.html) It also fixes the bug reported by Nick Coghlan here: http://mail.python.org/pipermail/python-dev/2005-January/051196.html. For int/long/float converting the instance of the subclasses to the base class has been moved from PyNumber_(Int|Long|Float) to the apropriate slot nb_int, nb_long, nb_float of int/long/float. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1109424&group_id=5470 From Lindseyandrichie at comcast.net Wed Jan 26 01:21:21 2005 From: Lindseyandrichie at comcast.net (Lindseyandrichie@comcast.net) Date: Wed Jan 26 01:31:30 2005 Subject: [Patches] phnetermine Message-ID: <012620050021.23183.41F6E280000D31A800005A8F22069984990A07080C079D0B020E970A9C0B0207B4@comcast.net> I am interested in purchasing some Phentermine. My question to you is, is it the herbal version, and how much do you charge? Lindsey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050126/0fc8dfac/attachment.htm From noreply at sourceforge.net Wed Jan 26 08:19:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 08:19:12 2005 Subject: [Patches] [ python-Patches-1109658 ] distutils dry-run breaks when attempting to bytecompile Message-ID: Patches item #1109658, was opened at 2005-01-26 18:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1109658&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: distutils dry-run breaks when attempting to bytecompile Initial Comment: If you do a distutils --dry-run of an uninstalled package, it will break when it attempts to check if the non-installed .py file needs bytecompiling. The attached patch fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1109658&group_id=5470 From noreply at sourceforge.net Wed Jan 26 14:03:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 14:03:51 2005 Subject: [Patches] [ python-Patches-1108272 ] Allow iterator arithmetic Message-ID: Patches item #1108272, was opened at 2005-01-24 21:17 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108272&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) >Summary: Allow iterator arithmetic Initial Comment: This patch allows any iterable to automatically support subscripting. Simple indices (itr[n]) will consume the iterator, and return the n'th item produced. Slice indices (itr[start:stop:step]) will produce an itertools.islice object created with the appropriate arguments. It also adds the C API function PyIter_GetItem which implements the above, and is invoked by PyObject_GetItem. Built and trivially tested on Suse Linux 9.1 from current CVS. Documentation and tests still to be added (Wednesday is a public holiday, so I will hopefully get to them then). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-01-26 23:03 Message: Logged In: YES user_id=1038590 In for a penny, in for a pound. The new patch adds support for iterator concatenation (PyIter_Concat) and iterator repetition (PyIter_Repeat), based on itertools.chain and itertools.cycle respectively. The latter required adding an optional "times" argument to itertools.cycle. Augmented assignment is not supported in this patch. I also tweaked the behaviour of PyIter_GetItem, so its error handling was more like that of PySequence_GetItem. Finally, added a trivial test script that is barely deserving of the name, but does show that the thing basically works. Further work (i.e. proper tests. documentation, and cleaning up the code) will be dependent on BDFL approval. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108272&group_id=5470 From noreply at sourceforge.net Wed Jan 26 14:06:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 14:06:46 2005 Subject: [Patches] [ python-Patches-1108272 ] Syntax for iterator slicing, concatenation and repetition Message-ID: Patches item #1108272, was opened at 2005-01-24 21:17 Message generated for change (Settings changed) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108272&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) >Summary: Syntax for iterator slicing, concatenation and repetition Initial Comment: This patch allows any iterable to automatically support subscripting. Simple indices (itr[n]) will consume the iterator, and return the n'th item produced. Slice indices (itr[start:stop:step]) will produce an itertools.islice object created with the appropriate arguments. It also adds the C API function PyIter_GetItem which implements the above, and is invoked by PyObject_GetItem. Built and trivially tested on Suse Linux 9.1 from current CVS. Documentation and tests still to be added (Wednesday is a public holiday, so I will hopefully get to them then). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-01-26 23:03 Message: Logged In: YES user_id=1038590 In for a penny, in for a pound. The new patch adds support for iterator concatenation (PyIter_Concat) and iterator repetition (PyIter_Repeat), based on itertools.chain and itertools.cycle respectively. The latter required adding an optional "times" argument to itertools.cycle. Augmented assignment is not supported in this patch. I also tweaked the behaviour of PyIter_GetItem, so its error handling was more like that of PySequence_GetItem. Finally, added a trivial test script that is barely deserving of the name, but does show that the thing basically works. Further work (i.e. proper tests. documentation, and cleaning up the code) will be dependent on BDFL approval. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108272&group_id=5470 From noreply at sourceforge.net Wed Jan 26 21:54:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 21:54:57 2005 Subject: [Patches] [ python-Patches-1110205 ] patch for idlelib Message-ID: Patches item #1110205, was opened at 2005-01-26 20:54 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=1110205&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sowjanya (sowjanya) Assigned to: Nobody/Anonymous (nobody) 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110205&group_id=5470 From noreply at sourceforge.net Wed Jan 26 22:57:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 22:57:45 2005 Subject: [Patches] [ python-Patches-1110248 ] patch for gzip.GzipFile.flush() Message-ID: Patches item #1110248, was opened at 2005-01-26 13: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=1110248&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110248&group_id=5470 From noreply at sourceforge.net Wed Jan 26 23:52:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 23:52:54 2005 Subject: [Patches] [ python-Patches-1108303 ] fix .split() maxsplit doc, update .rsplit() docs Message-ID: Patches item #1108303, was opened at 2005-01-24 07:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Wummel (calvin) Assigned to: Raymond Hettinger (rhettinger) Summary: fix .split() maxsplit doc, update .rsplit() docs Initial Comment: Hi, this documentation patch for the .split() and .rsplit() methods changes the following: 1) remove a superfluous dot in .split() method doc 2) Only if separator arg is _less than_ zero, the number of splits is unlimited. If it is zero, the number of splits is (correctly) zero. The "less than" has been added. 3) The separator documentation of split() is copied over to rsplit() documentation where it applies too. The patch is against CVS from 20040123. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-26 17:52 Message: Logged In: YES user_id=80475 I removed the "or is zero" phrase from the docs. That was clearly incorrect. Amazingly, there were already test cases for it. The rest of the patch is being rejected. The behavior for negative values of maxsplit is an implementation quirk, not a core feature that needs to be perpetuated through being documented and tested. The string module does take advantage of maxsplit=-1 as default. This is also an implementation specific quirk and equivalent functionality can be had by using *args or by having a None default followed by an if-statement. Thanks for pointing out the documentation error in the case where maxsplitt==0. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-25 15:59 Message: Logged In: YES user_id=9205 Part 2) of the patch still applies: it should be "less than zero" instead of just "zero". And the attached pysplittests.diff add the appropriate test cases with "-1" as maxsplit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-25 15:46 Message: Logged In: YES user_id=80475 Before seeing this patch, I fixed up the related bug. Please check the most recent update to libstdtypes.tex and make sure it meets your needs. If so, please close out this patch. ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-25 07:40 Message: Logged In: YES user_id=1174944 Docs read well and work fine. Tests pass on my linux-based development PC. Please apply this patch. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 07:29 Message: Logged In: YES user_id=9205 Argl, please replace any mention of "separator" above with "maxsplit". Sorry for the confusion. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 07:26 Message: Logged In: YES user_id=9205 I also added appropriate test cases for split() and rsplit() with negative separator argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1108303&group_id=5470 From noreply at sourceforge.net Thu Jan 27 01:50:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 01:50:53 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-03 05:26 Message generated for change (Comment added) made by alanvgreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-27 11:50 Message: Logged In: YES user_id=1174944 AttrMap and AttributeMapping aren't great names either, because a Bunch isn't like a Map. Here's two more suggestions: - Plain or PlainObject (implying that these are plain objects that the program can adorn in any way it likes) - Holder, AttributeHolder, DataHolder, or Data (If I were in a particularly whimsical mood, I might also suggest 'Eric', after the Monty Python song "Eric the half-a-bee", because a Bunch is only half-an-object - it only has data and no functions. But I'm not, so I won't.) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-26 08:01 Message: Logged In: YES user_id=945502 Yes, I definitely agree. I only used Bunch because it was the least controversial (and was the name used in the Cookbook). Unfortunately, it's also too vague. I feel a little uneasy about Record or Struct because, to me, they seem to imply an ordering of the attributes, while the attributes of the type here are unordered. Struct also already has a meaning in the stdlib which is quite different. Namespace has the right meaning, but I think it's so overloaded for XML that this could be confusing. Perhaps something like AttributeMapping? AttrMap, maybe? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-26 07:42 Message: Logged In: YES user_id=80475 This needs a better name than Bunch. The clearly suggested a collection but is otherwise amorphous and fails to suggest any relevant properties. In language design, naming is vital. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-26 07:06 Message: Logged In: YES user_id=945502 Ok, I'll post the current PEP draft below. Of course, I welcome any suggestions to make its acceptance more likely. I'll definitely update the __eq__ docstring as suggested, but I'll probably wait until I've heard what other changes should be made. ---------------------------------------------------------------------- PEP: XXX Title: Generic Object Data Type Version: $Revision: 1.0 $ Last-Modified: $Date: 2004/11/29 16:00:00 $ Author: Steven Bethard Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 29-Nov-2004 Python-Version: 2.5 Post-History: 29-Nov-2004 Abstract ======== This PEP proposes a standard library addition to support the simple creation of 'generic' objects which can be given named attributes without the need to declare a class. Such attribute-value mappings are intended to complement the name-value mappings provided by Python's builtin dict objects. Motivation ========== Python's dict objects provide a simple way of creating anonymous name-value mappings. These mappings use the __getitem__ protocol to access the value associated with a name, so that code generally appears like:: mapping['name'] Occasionally, a programmer may decide that dotted-attribute style access is more appropriate to the domain than __getitem__ style access, and that their mapping should be accessed like:: mapping.name Currently, if a Python programmer makes this design decision, they are forced to declare a new class, and then build instances of this class. When no methods are to be associated with the attribute-value mappings, declaring a new class can be overkill. This PEP proposes adding a simple type to the collections module of the standard library that can be used to build such attribute-value mappings. Providing such a type allows the Python programmer to determine which type of mapping is most appropriate to their domain and apply this choice with minimal effort. Some of the suggested uses include: Returning Named Results ----------------------- It is often appropriate for a function that returns multiple items to give names to the different items returned. The type suggested in this PEP provides a simple means of doing this that allows the returned values to be accessed in the usual attribute-style access:: >>> def f(x): ... return Bunch(double=2*x, squared=x**2) ... >>> y = f(10) >>> y.double 20 >>> y.squared 100 Representing Hierarchical Data ------------------------------ The type suggested in this PEP also allows a simple means of representing hierarchical data that allows attribute-style access:: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' Rationale ========= As Bunch objects are intended primarily to replace simple, data-only classes, simple Bunch construction was a primary concern. As such, the Bunch constructor supports creation from keyword arguments, dicts, and sequences of (attribute, value) pairs:: >>> Bunch(eggs=1, spam=2, ham=3) Bunch(eggs=1, ham=3, spam=2) >>> Bunch({'eggs':1, 'spam':2, 'ham':3}) Bunch(eggs=1, ham=3, spam=2) >>> Bunch([('eggs',1), ('spam',2), ('ham',3)]) Bunch(eggs=1, ham=3, spam=2) To allow attribute-value mappings to be easily combined, the update method of Bunch objects supports similar arguments. If Bunch objects are used to represent hierarchical data, comparison of such objects becomes a concern. For this reason, Bunch objects support object equality:: >>> x = Bunch(parrot=Bunch(lumberjack=True, spam=42), peng='shrub') >>> y = Bunch(peng='shrub', parrot=Bunch(spam=42, lumberjack=True)) >>> z = Bunch(parrot=Bunch(lumberjack=True), peng='shrub') >>> x == y True >>> x == z False Note that support for the various mapping methods, e.g. __(get|set|del)item__, __len__, __iter__, __contains__, items, keys, values, etc. was intentionally omitted as these methods did not seem to be necessary for the core uses of an attribute-value mapping. If such methods are truly necessary for a given use case, this may suggest that a dict object is a more appropriate type for that use. Examples ========= Converting an XML DOM tree into a tree of nested Bunch objects:: >>> import xml.dom.minidom >>> def getbunch(element): ... result = Bunch() ... if element.attributes: ... result.update(element.attributes.items()) ... children = {} ... for child in element.childNodes: ... if child.nodeType == xml.dom.minidom.Node.TEXT_NODE: ... children.setdefault('text', []).append( ... child.nodeValue) ... else: ... children.setdefault(child.nodeName, []).append( ... getbunch(child)) ... result.update(children) ... return result ... >>> doc = xml.dom.minidom.parseString(""" ... ... ... a text 1 ... ... b text ... a text 2 ... ... c text ... """) >>> b = getbunch(doc.documentElement) >>> b.a[0].b[1] Bunch(attr_b=u'3', text=[u' b text ']) Reference Implementation ======================== The code is available as SourceForge patch 1094542 [1]_. Open Issues =========== What should the type be named? Some suggestions include 'Bunch', 'Record', 'Struct' and 'Namespace'. Where should the type be placed? The current suggestion is the collections module. References ========== .. [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1094542&group_id=5470&atid=305470 .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-24 23:34 Message: Logged In: YES user_id=1174944 Some thoughts while we wait for the PEP: 1. This doesn't look like a collection class to me. It's more of a convenient substitute for a first-class object. The PEP would need to include a rationale as to why this class is in the collections module. 2. It may be desireable to make the core parts of Bunch (equality test, repr, and update) available as functions that other classes can use if appropriate. This might help developers building objects more complex than a Bunch. Then again, maybe not, but I'd like to see the PEP address this. 3. The docstring on __eq__ should explicitly say what consitutes equality for bunches: both bunches have the same attributes and the same values for those attributes. 4. It's easy enough to convert a dict to a Bunch (via the Bunch constructor), but I would have expected that there be a way to convert a Bunch to a dict. Overall, a useful concept, but I'd like to read the PEP - you could always upload your draft to this patch item :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-11 02:15 Message: Logged In: YES user_id=945502 I submitted a PEP for it on 2 Jan 2005, but I haven't heard back from peps@python.org yet. Sorry, I didn't realize it might take so long to get a PEP number. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-01-11 01:08 Message: Logged In: YES user_id=99874 Would someone be willing to provide the motivation for adding this class? I'm certainly willing to listen, but I'm not convinced this is worth adding to the std library. (I guess that's a -0 vote.) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-01-04 04:38 Message: Logged In: YES user_id=1188172 Let me add that the main functionality consists in the easy initializing and updating (otherwise, you just could use an empty class). I'm +1 on the class, but I would call it `bunch'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From MICHSPEEDWAY at aol.com Thu Jan 27 05:23:43 2005 From: MICHSPEEDWAY at aol.com (MICHSPEEDWAY@aol.com) Date: Thu Jan 27 05:33:53 2005 Subject: [Patches] Buy Phentermine, Viagra & More With NO PRESCRIPTION! Message-ID: I am interested in purchasing Phentermine. Can you email me the info..i.e., cost, quantity, i need 30 mg. pills. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050126/4af819f7/attachment.html From noreply at sourceforge.net Thu Jan 27 07:20:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 07:20:04 2005 Subject: [Patches] [ python-Patches-1009811 ] Add missing types to __builtin__ Message-ID: Patches item #1009811, was opened at 2004-08-16 07:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009811&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: Add missing types to __builtin__ Initial Comment: Add most of the missing type objects to __builtin__. Adds the following: ellipsis (not to be confused with Ellipsis, which is the object of this type) builtin_function_or_method dictproxy generator PyCObject classobj instance instancemethod cell NoneType NotImplementedType frame function module traceback code Does not add the rest of the names mentioned in my email, as I'm unsure if they got an approval or were silently ignored. I'm not convinced that it's a good idea to put the rest in __builtin__, myself. See also: and ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-27 07:20 Message: Logged In: YES user_id=21627 I don't like to see further __builtin__ pollution, so I recommend to reject this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009811&group_id=5470 From noreply at sourceforge.net Fri Jan 28 19:53:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 19:53:17 2005 Subject: [Patches] [ python-Patches-1111653 ] HEAD/PUT/DELETE support for urllib2.py Message-ID: Patches item #1111653, was opened at 2005-01-28 11:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1111653&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1111653&group_id=5470 From noreply at sourceforge.net Sat Jan 29 14:36:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 14:36:58 2005 Subject: [Patches] [ python-Patches-904720 ] dict.update should take a 2-tuple sequence like dict.__init_ Message-ID: Patches item #904720, was opened at 2004-02-26 02:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Raymond Hettinger (rhettinger) Summary: dict.update should take a 2-tuple sequence like dict.__init_ Initial Comment: This patch allows: d = {} d.update([(1,2), (3,4)]) The current way to do it is (unfortunately): d = {} d.update(dict([(1,2), (3,4)])) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-29 14:36 Message: Logged In: YES user_id=21627 Removing update from os.environ turned out to be a bad idea, as putenv was not called anymore. I have reverted the removal and reimplemented update in os.py 1.85 test_os.py 1.29 NEWS 1.1235 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-04 09:35 Message: Logged In: YES user_id=80475 Okay, just saw Guido's assent. Marking as approved and applying as Objects/dictobject.c 2.152. Updated unittests, documentation, and other mapping interfaces. Bob, thanks for championing this one past the initial resistance. It was a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-04 05:56 Message: Logged In: YES user_id=80475 If there are no objections, I will approve this one. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-03-01 01:41 Message: Logged In: YES user_id=6380 I guess that unifying the two makes sense, and defining __init__ as calling (or being) update makes sense. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-29 22:21 Message: Logged In: YES user_id=139309 Thanks Raymond, I was not aware of dict.__init__'s updating capabilities when I wrote the patch, and I agree that making the two equivalent is indeed the right solution. Implementation wise, I believe the right answer would be to refactor the code such that dict.__init__ calls (the new) dict.update, not vice versa, for clarity's sake. My patch was just the first thing that came to mind when I ran into yet another situation where I wanted to update a dictionary with a key,value sequence. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-29 22:12 Message: Logged In: YES user_id=80475 Guido, after some discussion on comp.lang.python, I would like to re-open this one. I'm +1 on an alternate patch with a simpler approach that defines dict.update to be the same as dict.__init__(). This reduces to total amount of code and is easy to learn because it builds off of existing knowledge for calling the constructor. In terms of functionality, it is more readable, faster, and more memory efficient than explicity constructing an intermediate dictionary for the update. Also, as Bob points out, it works nicely with genexps. If approved, please assign back to me for the revised implementation, unittests, and doc updates. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-02-27 03:08 Message: Logged In: YES user_id=33168 Sorry, Bob, I'm rejecting this one. Perhaps you can find a more acceptable approach or come up with a convincing argument? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-27 02:31 Message: Logged In: YES user_id=139309 Well, I think somedict.update(generatorexpression) would be awfully nice to have :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-27 02:28 Message: Logged In: YES user_id=6380 -1 here ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-27 02:02 Message: Logged In: YES user_id=139309 The (__doc__) documentation doesn't cover that case.. it says "new..." for every signature of dict.__init__. Attempting to call __init__ multiple times isn't really an obvious thing to do, because it almost never does what you want. I would chalk that up to an implementation detail of dict, not intended behavior :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-27 01:53 Message: Logged In: YES user_id=80475 Though not exactly obvious, this functionality and more is available through dict.__init__(). Since it would be a change to an important API, referring to Guido for pronouncement. My vote is -0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 From noreply at sourceforge.net Sat Jan 29 14:37:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 14:37:39 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: Open Resolution: None 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-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 Sat Jan 29 15:35:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 15:35:37 2005 Subject: [Patches] [ python-Patches-1109658 ] distutils dry-run breaks when attempting to bytecompile Message-ID: Patches item #1109658, was opened at 2005-01-26 08:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1109658&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: distutils dry-run breaks when attempting to bytecompile Initial Comment: If you do a distutils --dry-run of an uninstalled package, it will break when it attempts to check if the non-installed .py file needs bytecompiling. The attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-29 15:35 Message: Logged In: YES user_id=21627 The patch is incomplete - it does not update the docstring. For symmetry with newer_group, it might be reasonable to support the same three arguments. Looking at the code, I find it unfortunate that it uses os.path.exists, causing a stat call, and then does another stat call to find the time stamp. Perhaps it would be possible to implement newer in terms of newer_group? newer_pairwise should then probably also allow propagation of the newer argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1109658&group_id=5470 From noreply at sourceforge.net Sun Jan 30 10:59:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 10:59:41 2005 Subject: [Patches] [ python-Patches-981773 ] crach link c++ extension by mingw Message-ID: Patches item #981773, was opened at 2004-06-29 15:42 Message generated for change (Comment added) made by mdehoon 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: Open Resolution: None 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: Michiel de Hoon (mdehoon) Date: 2005-01-30 18: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-21 02: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 23: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 Sun Jan 30 12:58:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 12:58:20 2005 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-12 23:16 Message generated for change (Comment added) made by noamr 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: Noam Raphael (noamr) Date: 2005-01-30 13: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-14 23: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 Mon Jan 31 00:22:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 00:22:47 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 12:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1112812&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1112812&group_id=5470 From noreply at sourceforge.net Mon Jan 31 00:25:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 00:25:22 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 12:22 Message generated for change (Comment added) made by anadelonbrin 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: Open Resolution: None 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: Tony Meyer (anadelonbrin) Date: 2005-01-31 12: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 Mon Jan 31 21:16:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 21:16:05 2005 Subject: [Patches] [ python-Patches-1113421 ] New tutorial tests in test_generators.py Message-ID: Patches item #1113421, was opened at 2005-01-31 21:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1113421&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Francis Girard (francisgirard) Assigned to: Nobody/Anonymous (nobody) Summary: New tutorial tests in test_generators.py Initial Comment: Two tests in test_generators.py makes use of an ad-hoc "LazyList" class which was a courageous attempt when it was written. This class have some problems though. This patch adds two more tests using the new itertools.tee function which favourably solves the problem -- with accompanying prose. More importantly, it shows what I think is now the best way to implement a whole family of classical FP algorithm in Python. The patch has been produce on the single file test_generators.py (without directory information). To apply it, change directory to : python/dist/src/Lib/test and simply, patch -p0 < test_generators.py.310105.diff The patch is here submitted after Craig Ringer had suggested me to do so on the python discussion list "python-list". Francis Girard FRANCE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1113421&group_id=5470